IgnorantGuru's Blog

Linux software, news, and tips

Happy Birthday SpaceFM (0.9.3 released)

SpaceFM 0.9.3 has been released (see notes). This minor maintenance release stabilizes adjustment of the task manager columns and corrects a few issues.

Happy new year! And happy birthday to SpaceFM, which is now two years old (first pre-alpha release was on Jan 13, 2012). I see this blog had about 100,000 visits this past year, which while a little slower than some years (no doubt due to my fewer posts), it’s still great to see the level of interest, and from around the world too. I’ve made the 2013 and 2012 annual reports public if you’d like to see a bit about your fellow readers and some stats.

Update on SpaceFM Development

SpaceFM development hasn’t been too active the last few months aside from basic maintenance of the 0.9 series, and a few feature adjustments. While this may not be as exciting, it is good news to see that SpaceFM has reached a great level of stability, both in terms of its feature set and in terms of bugs. There are very few active bug reports, and reproducible bugs are usually addressed promptly.

This is a nice place to be in terms of development, because there isn’t much that needs to be done. SpaceFM is generally a complete and capable basic file manager (and DM) that doesn’t change quickly, which I feel is an asset in the current world of Linux. So as a minimum I aim to do the basic maintenance to keep it current, and since SpaceFM is also the file manager I use, I’m easily motivated to do so. SpaceFM also runs in a wide variety of environments and systems, dating back to HAL, etc., as well as the most current GTK3 and udev. As your extensible file manager, you can take it and all your custom tools with you.

Of course no software is ever done, and there are many ways that SpaceFM can develop further. If you find yourself bored with the pace of development, I strongly encourage you to get to know SpaceFM’s Design Mode and Dialog features better. SpaceFM probably does more than you realize, and you can extend it in many ways.

That said, there have been a few things going on here at Ignorant Software. I put quite a bit of work into a new design for SpaceFM’s side panes, particularly a new Bookmarks pane that is more tightly integrated with Design Mode, making SpaceFM’s bookmarks very powerful and context aware. This also involves some redesign of the panel behavior in SpaceFM, making placement more flexible. And it includes some unique new features. The design is mostly complete and looks inviting, yet it’s just a design – a long, long road from seeing reality. I was a bit discouraged by the amount of work it looks to be to implement, especially in light of poor upstream support lately in GTK. It’s a gamble to invest work based on an API whose future is uncertain. So for now this next stage of SpaceFM is pending, mostly waiting for more extensive development time.

SpaceFM contributor OmegaPhil has been working on newly designed archive handling in SpaceFM, which includes a configuration dialog that allows one to set custom handlers to create and extract any kinds of archives in any way, rather than the current hard-coded commands. This work is largely completed and we’re finalizing some of the design choices and behavior before it enters early testing. No precise timing on this but plans are to make a testing branch available for this relatively soon.

In a slightly longer term plan, OmegaPhil’s handler configuration dialog will see double duty in SpaceFM, as I extend it slightly as a dialog to configure handlers for network types as well, and perhaps filesystem types. This will allow separate handlers to be set for each protocol or filesystem being mounted/unmounted, and will enable SpaceFM to make better use of unlimited fuse filesystems and diverging mount solutions ootb. It can currently do this with a custom protocol handler, but the new dialog will make this more user-friendly and capable.

One final thought on completion and development… SpaceFM is ad hoc by design in its handling of devices, networks, and filesystems. This flexibility can be misinterpreted as dysfunction or poor design when it’s not fully configured. Many distros simply package and ship SpaceFM without providing a default session file, for example. This gives you the vanilla configuration. Yet because SpaceFM is designed to work across such a broad array of environments, these defaults are minimal at best, and may not work well with your system without some adjustment. This is especially true of SpaceFM for several reasons. It’s not associated with a DE or other fixed set of system tools (yet can use any). It uses minimal dependencies (basically just HAL or udev, and gtk), and uses only stock GTK icons (it doesn’t have dependency on any icon themes). This gives it a very plain and unassuming look ootb, but rest assured you can give it very different looks and behavior in many regards.

So overall I’m pleased that SpaceFM has reached a mature level of stability and ability. While it’s not my primary project now and gets less attention just because it works well, I think it’s in a very good place for its users and developers. Thanks for your continuing interest!

January 17, 2014 - Posted by | Software


  1. Hello!

    “It’s a gamble to invest work based on an API whose future is uncertain.”

    -> Do you plain to port Space FM from GTK+ to QT like PCManFM… ?

    Comment by DDZ | January 20, 2014

  2. Overall SpaceFM’s code isn’t in good condition for a port – it’s a prototype. What I see as valuable in SpaceFM isn’t the code as much as some of the design ideas that were tried out and evolved through feedback and use – and that was the idea all along. I think I would take all that we have learned from the SpaceFM prototype and do a rewrite from the ground up if I wanted to move the basic design to another toolkit. This would give the added benefit of allowing some of the design to grow as it wants to. But that’s also a major undertaking to consider.

    SpaceFM is very solid and reliable at this point, and the dual GTK2/GTK3 support is working very well (with a few minor glitches). So my thinking is to get all I can get out of this prototype and its current toolkits. I didn’t develop and stabilize it just to rewrite it a couple of years later. (It’s that kind of garbage development – rewriting everything every year to keep up with toolkits – that is stopping Linux from evolving.) I wrote it to get real mileage out of it. That’s why its dependencies are minimal – no gvfs to keep up with, etc.

    For now, GTK works. What more concerns me is symptoms upstream, part of a larger pattern of decay in Linux, and movement to corporate control of the whole system. With systemd racing toward inclusion in Debian, Red Hat (with strong Google influences) will basically own Linux and control it’s direction (demise). That is clearly happening NOW, not in some imaginary future. In my view Linux is being killed, and I have an eye toward moving to some BSD or other system in a few years. I don’t view mainstream Linux as viable in the medium term. Otherwise it will be like using and developing in Windows, which it already has become in many ways. Nor am I a big fan of Qt and its deep corporate connections, so that certainly doesn’t excite or motivate me.

    Yet capable internationalized GUI toolkits are very limited in Linux, and this isn’t the best time to shop for one or make decisions – lots of sea change happening. Basically the corporate world is killing off Linux as we’ve known it, or doing their best to morph it into something very unfree and useless. You or others may not see this yet, but I have a better view, and once their chess pieces are in place it will get uglier. Red Hat developers are EVERYWHERE these days, tearing it apart. Linus sees it too, and he won’t be in command forever.

    So I will wait. I doubt I would invest in writing a Linux app at this time – it’s not just GTK that is in trouble. GTK was supposed to be the non-corporate alternative, but it has been taken over. Qt always was corporate, so its not a solution. Linux developers are being driven to it, but you have to be careful what train you get on. Many of them are also Windows developers, so they have a less pure attitude wrt libre, etc.

    So my current thinking is that the GTK SpaceFM will go on for awhile, especially since it can fallback to GTK2-only if GTK3 gets too insane or unreliable to support. Probably no huge development, but some features and maintenance. And by then maybe some other forks or toolkit development will come online, although thus far there doesn’t seem to be much non-corporate organization or motivation in this area. Like most things, big money is in control, and not to our benefit.

    My GTK doubts aren’t really what’s making me hesitate about the new bookmarks design, just an excuse really. It’s just a lot of work, and new code to support, document, etc. These things are never as simple as they appear in a design. I don’t want to get into it unless I am motivated to do it well. SpaceFM is in such good shape in many ways, anything I add needs to be done well, or not done at all. So that more depends on my schedule and how much I want to devote to SpaceFM. But there are some smaller improvements coming, as I noted in the post.

    Comment by IgnorantGuru | January 20, 2014

  3. Hey, just wanted to say I finally got around to installing SpaceFM and udevil (from the Debian repository). Quite nice! The automount via udevil “just works”. (Why did I procrastinate so long? Inertia… Well, better late than never.)

    Thanks very much.

    Comment by russ | February 18, 2014

Sorry, the comment form is closed at this time.