SpaceFM 0.8.6 is available. This release includes new Path Bar functionality and other changes as detailed in SpaceFM News.
Feedback is welcome on how the new Path Bar is working for you.
Users of my PPA please note that the following SpaceFM packages are now available: spacefm (GTK2), spacefm-gtk3, and spacefm-hal, plus udevil. At least two Debian packagers are working on getting official Debian packages available – hopefully that will materialize soon.
udevil 0.4.0 is available. This release adds support for WebDAV via davfs2, so you can mount http:// and https:// URLs to edit WebDAV-enabled websites (these URLs will also now work in SpaceFM’s path bar when used with udevil 0.4.0 or later). For details on using WebDAV and other minor changes in this release, please see udevil News.
Also, SpaceFM with udevil is now the default file manager in the latest release of ArchPup (13.2), the new Debian sid-based distro VSIDO, and will be the new default file manager in the upcoming release of SliTaz.
I’m pleased to announce that an article I wrote will be appearing in the upcoming print issue of Linux User & Developer™ magazine. The article, A Linux Conspiracy Theory, is originally based on my November blog article GNOME (et al): Rotting In Threes, trimming down some of the quoted materials there, and integrating some of the discussions and bug reports which followed. In addition, related issues affecting kernel development and other areas of Linux are analyzed in this context, bringing together a larger picture of what is happening in Linux.
Much thanks to their editor, Russell Barnes, for working with me on this and helping to bring these issues to greater attention.
Linux User & Developer magazine is available worldwide in printed, online and digital forms, including iPad, Android tablets, and PCs. This 6-page feature article will go live in Issue #122 on sale January 17th (in the US, look for it in stores 2-3 weeks later). Look for this cover:
Thanks for picking up a copy and checking it out! UPDATE: You can now read this article here.
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!
This release is mostly a maintenance release but includes a few additions as detailed in News.
Did I merely want to release a SpaceFM version on December 21, 2012? Maybe. :D
Also, for those using Kupfer, ShadowKyogre of Arch Linux has hacked the default
volumes.py plugin in order to accommodate udevil and spacefm rather than it relying exclusively on GIO to unmount the drives. See the current volumes.py
Enjoy the holidays and I’ll see y’all in 2013!
A routine review of security policies in udevil has been conducted, and several changes were made to harden udevil against known mount helper exploits. Although nothing terribly exciting turned up, upgrading is recommended for a few enhancements, and you can read the details.
Also, more eyes on udevil’s code and behavior are always welcome – help me to keep udevil as secure as possible. If you conduct a review and have any concerns or questions please contact me – thanks.
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.
Richard Stallman, creator of the GNU Project and author of several pivotal free software licenses (GPL, etc), yesterday published an article on the Free Software Foundation website exploring the fact that Ubuntu is adding really obnoxious spyware which sends your local file searches to advertisers, et al. For background, I covered this in my GNOME (et al): Rotting In Threes: Ubuntu Spyware article section, and the EFF published Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks.
One of the major advantages of free software is that the community protects users from malicious software. Now Ubuntu GNU/Linux has become a counterexample. What should we do?
Most free software developers would abandon such a plan given the prospect of a mass switch to someone else’s corrected version. But Canonical has not abandoned the Ubuntu spyware. Perhaps Canonical figures that the name “Ubuntu” has so much momentum and influence that it can avoid the usual consequences and get away with surveillance.
See his full article for details and how you can impact their decisions.
This is not exactly a new behavioral trend for Canonical, merely the latest growth. Several years ago when I dumped Ubuntu they were starting to modify Firefox in their repos so that the online search box redirected to their servers. Their escalation into sharing local search data is a gross betrayal of their users. I think anyone who supports Linux should seriously question why they’re using Ubuntu at this point. In free software, we don’t vote much with our dollars, but we do vote by using and giving attention to software and distros. Nothing says ‘I do not support this’ like users moving en masse away from their offerings. Addiction to any one distro or software solution allows these corporations to keep moving Linux in anti-user directions.
Kudos to a community leader such as Richard Stallman for taking a firm stance against these practices. Much of the valuable qualities we find today in Linux are there because of his work and the work of similar activists, as well as Linux users who stay aware of and involved in these issues. Also see Richard’s personal activist site where he gives excellent reasons for Don’t do business with Amazon, Don’t use Skype, and Don’t do business with Apple, among important others.
What this comes down to: Do you want Linux to survive and grow as a viable alternative to closed, user-limiting systems?
SpaceFM 0.8.3 and udevil 0.3.5 have been released. Reflecting the great results being obtained with GTK3, this release can be built for GTK2 (default) or GTK3 (beta test). However, please note the potential GTK3 theme issues (link below).
0.8.3 also adds the new socket commands which greatly extend what custom commands and plugins can do in SpaceFM. I had hoped to include a CD burning plugin to demonstrate some of these features but that’s not quite done yet – look for it soon.
SpaceFM is now included in Pibang Linux for the Raspberry Pi, and reportedly builds and runs very well on this armhf architecture. Thanks to Pibang’s Nathan for the packaging and for some updates to the standard debian packaging.
It would seem that Red Hat’s GNOME devs have had a meeting and a change of heart:
while we certainly hope that many users will find the new ways comfortable and refreshing after a short learning phase, we should not fault people who prefer the old way. After all, these features were a selling point of GNOME 2 for ten years!
Why, these people are just so darn heart-warming, aren’t they? I love it when they call alt-tab “the old way”. :) Not standard or even different or alternate, but “old”. Why do I feel that in his mind he’s making some minor concessions to senior citizens?
we’ve decided that we will compile a list of supported gnome-shell extensions. This will be a small list, focused on just bringing back some central ‘classic’ UX elements: classic alt tab, task bar, min/max buttons, main menu…
We haven’t made a final decision yet on how to let users turn on this ‘classic mode’ – it may be a switch in gnome-tweak-tool or something else.
As in, “oops, we forgot that we have users and they like to actually do stuff, so now we have to figure out how to hack flexibility into our rigidly designed system”. This is sure to be done well.
Yet the good news is they finally responded on this one issue in some form, at least in theory. Perhaps.
Earlier reading: GNOME (et al): Rotting In Threes