Some development notes on SpaceFM for those who are interested…
My blog has been littered with a lot of GNOME and GTK complaints, rants about corporate development, and other problems affecting Linux lately. The simple reason for this is that I’ve been bringing myself up to speed on these issues and sharing the results in the process. This blog is my workspace as well as a place to network and publish, so thanks for all the comments and input.
SpaceFM has a certain momentum now, based on the number of users and the amount of work that has gone into it. It’s a bit like piloting a large boat – fast changes are discouraged and impractical in terms of stability and the work such changes create, so one tends to look and plan ahead a bit. And SpaceFM is intended to be an ark in the storm – something which allows me or you to distro hop and change DEs and WMs while still having the file manager and its customizable tools be consistent and functional. It’s designed to survive and work in a variety of environments meeting its minimum, and fairly light requirements. It doesn’t get too involved in or dependent on the ecosystem around it, sticking to core compatibility via CLI programs and direct kernel access.
GUI programming is particularly time consuming, which is why app developers are particularly sensitive to toolkit evoluton, changes and breakage. As I’ve made clear, I don’t trust who is controlling GTK development or the directions it’s taking, so SpaceFM’s use of GTK has become a liability, less so now, but potentially greatly in the future. So I’m pondering what direction to take through this sea of Linux icebergs, which have sunk other lightweight apps already, or destined them to bugs and crashes.
SpaceFM was forked from PCManFM, rather than written from scratch, to give GTK a good test without commiting a complete rewrite to it. So in that sense the growing sense of failure in GTK represents a success of that strategy. I knew that I didn’t know any GUI toolkit well enough to make a long-term decision on it.
No decision on this yet – this is why I’ve been examining Red Hat’s and others’ motives and agendas so carefully, and trying to understand what is happening in lower levels of Linux like udev, udisks, and systemd as well. I want to take a path with SpaceFM that basically doesn’t waste a huge amount of work, and doesn’t create an app that performs badly.
I’m not sure what SpaceFM’s future is, but there are a few key positions I take. Backwards and forwards compatibility are a very high priority. How often has your SpaceFM config been borked? Hopefully not once. In developing and testing it I crash it hundreds of times, run assorted old and new versions using the same config file, and my config has survived all of this, and I’m still using the same config file that I started several months before SpaceFM’s initial alpha test release! While problems can always occur, the configuration is built to keep things working between crashes, upgrades, and downgrades.
SpaceFM depends directly on bash, rather than just a general shell, so that custom commands and plugins are running in a well-defined, consistent environment. You can always use other kinds of script in SpaceFM, but the initial data integration is done with true bash.
SpaceFM Dialog, a built-in feature of SpaceFM which allows custom commands to integrate dialogs into it (along the lines of zenity or yad), is also designed to have a predictable usage. Same for the socket commands which allow you to tap into and alter the GUI as its running.
So overall, while SpaceFM may grow, or even its GUI toolkit or other key components may someday change, the goal is to provide a continuity to the user experience, and to honor the customizations the user has added. One big reason for this is that I am one of those users, and I don’t like having my stuff broken!
I have become something of a distro hopper lately. Just as I’m not particularly happy with some of the limitations in the Linux tools available for stable, flexible development, I’m also not entirely happy with any distro I’ve tried thus far, from a user perspective. So I want to be flexible and surf on the changing waves of Linux, rather than nesting in a particular distro, DE, or set of libraries. During these days of Linux ‘climate change’, it seems wise to stay mobile, with a somewhat independent and self-sufficient set of tools which are resistant to breakage and which don’t constantly change your way of working.
Having a file manager with a configuration which is largely independent of the larger system configuration is valuable in this mobility. Having custom tools to maintain the system and perform other tasks, and having those tools available and working consistently as I change other components is also key. For me the file manager/desktop manager is a central point of access to the system and its functionality. Most of everything else is an app being spawned to do a particular job such as edit a file, watch a video, etc., or an app which adds a panel or other workspace tool or ornament.
Beneath this, these are the days of changing udev and udisks, consolekit, and all the incumbant problems they are creating with careless, lazy migration. Being able to alter the mount solution used in SpaceFM, and being able to use command line programs for that functionality, makes SpaceFM very adaptable. Users are beginning to ask that other file managers provide similar flexibility, although this will be tough to implement for those that depend on APIs and monolithic libraries for this.
Many DEs encourage you to use their file manager and desktop manager. Yet this means if you change DEs or distros, even to just try others, you may lose your ‘home base’ and associated tools, or they may change in various ways (differing incompatible versions, etc). Whenever I install a new distro I always feel lost until I have my file manager up and running as I want, along with my file type associations. bash – the old-fashioned ‘shell’ – is always there in a similar manner. I know how to get some stuff done in bash even if the distro or DE or available tools have changed.
So in that sense I think of SpaceFM as a spacecraft – out there exploring the Linux galaxy, while providing some of the comforts of the familiar and highly functional. A space oddessy (let’s just be glad HAL is no longer with us! Then again, udev…)
Although not having a lot of free dev time lately, I’ve also been taking a little break from SpaceFM development proper to work on a burning plugin. This will present a quick and dirty dialog for burning data discs initially. It interfaces with the GUI a bit to make composing the disc contents easy, and it runs cdrecord, cdrskin, or other CLI burning programs directly, allowing you to edit the command easily if the graphical interface doesn’t suffice. So far it’s going very well, and its developmemt gave me a chance to try some of SpaceFM’s new dialog and socket features – nothing like using an API in a real situation. It also revealed a few problems in SpaceFM in the process.
The biggest challenge there was getting the burning programs to cooperate with the shell and pipes in any reasonable manner. After some very helpful consultation with Thomas Schmitt, author of the libburn-based cdrskin and xorriso, and OmegaPhil, a long-time contributor to SpaceFM in various capacities ‘behind the scenes’, we came up with some solutions and most of those issues are resolved. Still some work to go on finishing up the intended functionality and getting it polished, but I hope to include an initial version within the next release or two. This won’t make SpaceFM a do-everything burning app ootb, but it will provide a handy tool for burning a disc quickly which can be extended in unlimited ways.