I have created a new github repo for my own SpaceFM plugins in an effort to make them reasonable to share and maintain. Note that this repo only contains plugins that I personally maintain. As always you can find a list of all plugins at the larger public SpaceFM Plugins Wiki.
Currently I have only one plugin there, my IG Burn Tools plugin, which I updated this morning. I’ve burned on a lot of discs with this plugin already and it works great for me. It’s simple so probably not everyone’s cup of tea, but it also demonstrates some more advanced uses of SpaceFM Dialog. I have also added more screenshots.
The github repo method is convenient for a number of reasons. You can watch the repo or subscribe to the feed to receive notifications of changes to any of my (currently one) plugins. You can also review the commits to see exactly what changes were made, and can access older versions of any plugin or file by going back into the git history.
From a maintenance perspective, github (which is free) provides a number of advantages. For example, it includes a wiki and a bug tracker, and it’s integrity checking helps avoid malicious activity. github can also host a homepage for the repo, or you can use the wiki (which can be publicly editable or locked). If you share SpaceFM plugins, you might want to consider this approach.
I setup a single “spacefm-plugins” repo for all my plugins, creating a subdirectory for each. Within each plugin’s subdirectory I added pkg and src directories. The pkg directory contains the current tar.gz plugin file (plus a signature file) for download. The src directory contains the extracted contents of the plugin file (so git can track changes within the plugin, and the contents can be browsed on github).
When I update a plugin, I export it as usual in SpaceFM, saving it directly to the pkg directory, replacing the older version. I then extract it to the src directory (I made a little custom command to do this), replacing the current contents. Then I review the ‘git diff’, commit the changes and push them. People watching the repo receive notification and can review the changes. For example, here are the changes I made this morning to the Burn Tools plugin for version 0.6.
All in all I think this is a very convenient approach, which should allow me to share lots of little plugins with a minimum of hassle as time goes on. But one is a start.
A beta version of my Burn Tools plugin is now available. This turns SpaceFM into a limited burning app, and can also be extended to include additional options, modified burn commands, etc. The idea is that I did the coding on the GUI part, so now it should be easier to use that as a base for customizing.
At present, it burns single session discs only. It makes the filesystem image first, and if all goes well, then burns it. This takes more time than the one step approach, but I find it less likely to create coasters. Maybe at some point some xorriso or growisofs support will be incorporated by me or someone else. So this isn’t the fastest burning app around – it takes its time to reduce coasters, adds checksums, etc.
I wrote this plugin mostly for my own use. Although I’m not aiming for all uses here, the flexibility comes from it being a plugin, so you can hack the script, etc. I will support the existing GUI functionality, but if you have burn problems within the burn commands, you’ll need to research and adjust those yourself. But for most cases it should work as is.
This plugin also demonstrates some of SpaceFM’s new dialog and socket abilities for plugins. Since I wanted to make it a nice little state machine, it’s not the simplest example, but nevertheless demonstrates some ways that plugins can interact deeply with the SpaceFM window.
For now I have added IgnorantGuru’s Burn Tools to the SpaceFM Wiki – details, screenshot, and download links are there. Thanks for testing and feedback is welcome on how this works for you.
Also, special thanks to Thomas Schmitt and OmegaPhil for helping me with some of the finer bash points and testing (I forgot to add you to this version of the README).
Also, are you a GUI developer? Thomas Schmitt, author of cdrskin, xorriso, and libburn is looking for a developer to create a GUI front-end compatible with his long running xorriso, one of the most comprehensive and well-supported burn programs in development. He has added a demonstration Tcl/Tk frontend to the source. How to test:
- Install Tcl/Tk if not present yet (old versions should be ok)
- Get freshly
- Build by:
tar xzf xorriso-1.2.5.tar.gz && cd xorriso-1.2.5 && ./configure && make
- Start xorriso and GUI script (with no need to install xorriso):
xorriso/xorriso -launch_frontend frontend/xorriso-tcltk --stdio --
- Read frontend/README-tcltk (and if curious enough: the code of frontend/xorriso-tcltk)
- There is also example code in C provided for the fundamental communication stuff: frontend/frontend_pipes_xorriso.c
- Other than the Tcl/Tk frontend, it starts an onw xorriso process instead of being started by xorriso. This gives the freedom to keep the own stdin and stdout alive, and to use a pair of pipe(2) for communication with xorriso.
If you’re interested, please contact Thomas – he’s a very helpful person to work with!
Sandfox 1.1.3 is available. This update simply adds one line to the default Firefox profile:
With recent Debian updates, due to changes in resolvconf, Firefox may require this bind for DNS lookups. Skype and other programs may also require this to be added to their profiles. I do not use Skype so feedback on this is requested.
If you’re already using Firefox, your profile will not be updated unless you delete /etc/sandfox/firefox.profile. Alternatively, you can add the above bindro line to that file manually.
Note that in some cases the actual location is /var/run/resolvconf. On recent Debian, /var/run is a link to /run, yet despite the fact that /var/run is already included, Firefox required this additional bind.
Sandfox 1.1.2 is available with the following changes:
- accomodate a recent change in mount’s usage for remounting bind mounts (affected Arch Linux)
- accomodate a recent change to how bind mounts type are listed in mtab – caused sandfox to report an error when creating a bind mount
- added /dev/nvidia0 & /dev/nvidiactl binds to default profiles
- added bindro=/opt/firefox to default firefox profile
- improved detection for ‘firefox already running’ warning
NOTE: If you use nvidia display driver, you may want to add the following lines to /etc/sandfox/default.profile:
Otherwise if you run sandfox with ––verbose you may see Firefox and Google Earth reporting errors about these missing files, which may affect video performance.
A very recent change to ps (addition of random spaces to the ends of lines in v3.3.0) broke Sandfox’s detection of sandfox daemons. Sandfox v1.1.1 corrects this problem.
The following packages in the PPA:
did not install the scripts to the correct location due to a change in one of the deb build programs I use. Please upgrade to these packages to the correct the problem:
mountiso v1.0.1 is available to correct a problem with relative paths on the command line (seems to be a theme), and also it adds a note on setup about setting max_loop to prevent loop devices disappearing on reboot.
xtract v1.1.0 is available. This update adds options for using xtract on the command line without zenity. Also, the ––inter and ––inter-name options have been renamed ––combine and ––ask. However, the old options will work even though they are not listed in the help, so there is no need to change existing setups.
Also, zenity is no longer required by the xtract deb package, but is required if you’re using xtract from within a file manager.
“Abandon all hope” was the title of a recent LWN security advisory on the Flash plugin, which has been my philosophy with regard to Adobe products for quite some time! It’s a good reminder to use something to isolate Flash from the rest of your system, be it a basic filesystem sandbox like Sandfox creates, or more comprehensive solutions.
It is a mistake to think these vulnerabilities are found and corrected in anything like a timely manner, and to assume that additional vulnerabilities aren’t created to replace them. As David Bowman might say, “The thing’s hollow – it goes on forever – and – oh my God – it’s full of holes!”