IgnorantGuru's Blog

Linux software, news, and tips

My SpaceFM Plugins Repo

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.

February 15, 2013 - Posted by | Scripts


  1. Today, for the first time, I added a custom command to SpaceFM. I almost feel ashamed for looking at the documentation because it was so much easier than I was expecting. Especially with having a custom key combo, it’s really convenient to use. I now have play-to functionality working for my HTPC, and it makes perfect sense to do it from SpaceFM. I can’t imagine doing this with another file manager. Thanks!

    Comment by BwackNinja | February 23, 2013

    • Howdy, Yes, it’s very easy to add custom commands to SpaceFM, and they can be very capable or simple, but the customization menu is unobtrusive (to keep the UI clean and simple). This means it also remains hidden and many users never discover much of what SpaceFM can do – a cost of keeping the interface reasonable. I do recommend all SpaceFM users browse through the Design Mode docs just so they know the possibilities – you don’t need to be a programmer to use them. For more capable uses, keep socket commands in mind as well – lots of example provided there.

      Also note that in the upcoming 0.8.7, the desktop manager menu is fully design-mode capable. This also means you can add commands as style Custom to that menu which point to a desktop file to add a custom app menu, etc., among other new features in this version.

      And thank YOU for the nice job you did bringing SpaceFM into GTK3. Now that your code has finally reached master after months of various testing stages (my paranoia) and is the default package in major distros like Arch, it’s still holding up very well – very few problems. Although you did having me going for a bit here#253. ;) I hope you’ll consider contributing in the future as things come up. Movable icons is one thing missing from the desktop support, and given the way you handled cairo etc I think you’d be a good candidate for that if it interests you. Patrick has been very supportive of the SpaceFM project and he’s even offering a bounty on this one, which would be yours.

      Either way, thanks again for your contributions – nice work!

      Comment by IgnorantGuru | February 24, 2013

      • It’s funny to admit that I can’t even call myself a power user of SpaceFM. I don’t end up leveraging much more than its basic use.

        I can imagine the source of that bug was a pain to locate. I’ll try to get back to contributing sometime soon. I’ve been busy recently and I only just now had the time to deal with my HTPC properly even though I built it 2 months ago. Movable icons sounds like an interesting problem. I guess it would have to be done by pixel rather than by grid square because of the variable height of the filenames. Handling changes in screen resolution would be something I’d want to do right, but I would probably defer it until everything else was working correctly.

        From a quick look at the code, the change wouldn’t be too hard, but I think you’d be better equipped to solve the issue. To get movable icons, you just need to modify the layout_items function in desktop-window.c to load the previous position of an icon if in movable icons mode, and save it when you drag and drop an icon. Adding new icons can be done by just finding the first place where they wouldn’t intersect with an existing icon. The sorting functions would also need to reset the icon positions. I was expecting this to be a harder problem, but the because the desktop code draws all the icons itself, the codebase looks like its already well equipped for this change.

        Comment by BwackNinja | February 24, 2013

        • Thanks for looking it over – sounds promising. I haven’t had much occasion to work in that area. I’d also like the snap-to-grid, but I imagine that would just be a matter of rounding to the nearest whatever. Btw are there any docs on cairo-related stuff that you recommend beyond the API docs? Hard to get an overview of how it works with just function definitions.

          Comment by IgnorantGuru | February 24, 2013

          • The tutorial on the site is fairly straightforward and covers the drawing model well: http://cairographics.org/tutorial/

            After that, SpaceFM’s own desktop drawing code is probably a good place to look as an example and shows the interaction with gtk2&3 well with the gtk2’s expose-event vs gtk3’s draw-event.

            Comment by BwackNinja | February 24, 2013

Sorry, the comment form is closed at this time.