Burn Tools – SpaceFM Plugin

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!

SpaceFM 0.8.4 Available

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
modification.

Enjoy the holidays and I’ll see y’all in 2013!

udevil Upgrade Recommended

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.

SpaceFM Development Notes

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.

Ubuntu Spyware

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.

Stallman writes:

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

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.

There’s more – for full release info see SpaceFM News and udevil News.

A Crack In The Monolith

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

You’re fired, Red Hat

Nice to see the energy for this udev fork building – will be interesting to see the method that Red Hat uses to try to kill it and maintain unilateral control. Where do these mysterious political influences in Linux come from anyway? Have they drugged and kidnapped Linus and switched him with a (characteristically poorly developed) Red Hat robot imposter? (If he starts crashing and refusing to grant access to his own brain, we’ll know it’s Red Hat devs at work again.)
gmane discussion thread
slashdot coverage

And if you want to see complete debian stupidity in action…
debian mailing list discussion

They don’t have the sense to support this – they’d rather argue about how debian is better than gentoo. So once again another choice by debian to use broken tools for political reasons. See cdrtools vs cdrkit for another example of mindless debian inertia and witless maintainers making unilateral choices for their users. And lest you think that’s old news, a debian packager recently contacted Jorg on his mailing list with ideas of packaging cdrtools, but someone in the upper echelons (lowest muck) of debian killed it again for no given reason.

Anyway, in every way you can let Linus and distros know that it’s time to bring some quality back to udev by supporting this fork. This is a small window in which to make a significant change.

I think they should simply steal the name ‘udev’ just like Red Hat does. As in You’re fired!

GNOME (et al): Rotting In Threes

Since SpaceFM is entering the GTK3 realm (SpaceFM can now be built on anything from GTK 2.18 “I won’t give up my lenny!” thru GTK 3.6.x), I’m starting to hear more feedback about GTK3 and experiencing a few things for myself. While SpaceFM’s GTK3 port has been running very well with the few non-broken themes I could find, there are some intrinsic problems with any GTK3 app due to GTK’s poor maintenance, as well as a growing culture of enforced conformity from GNOME devs. Some of the things you’re about to read should make your hair curl and your blood boil.

On the surface of it, it seems that with every minor update to GTK3, themes get broken. I experienced this myself trying find a GTK3 theme that worked well with SpaceFM – most of the themes are broken in GTK 3.4 thru 3.6 (you can see the warnings when running SpaceFM in a terminal, and functions will be broken in the app). Thus the better-maintained themes (such as Clearlooks-Phenix and DarkMint) will have different versions for every minor version of GTK. The less well-maintained ones will simply remain broken.

Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your ‘brand’ is the best. Anytime I hear the word ‘brand’ being used in Linux, I know something valuable is being poisoned. Just as a sample of what is to come, GNOME dev Allan Day writes:

I’m particularly surprised by the inclusion of themes. It seems bizarre…

Oh it’s bizarre alright!

I have never gotten into the KDE vs GNOME debates, so this is not GNOME bashing, nor, as you’ll soon see, are these systemic development problems limited to GNOME. Yet what I’m hearing is that with GNOME v3 the goal is to promote their “brand” and make it dominant, in part by greatly limiting what users can change on their own systems, and partly by breaking or simply removing whatever support they’re no longer promoting as ‘The Way’. The reach of this selfish and narrow-sighted development goes beyond GNOME and affects GTK apps in general.

In the rush for Linux to become ‘popular’ and ‘make it into the desktop market’, maybe there is an unintended consequence. Not only are Windows users moving to Linux, but Windows devs seem to be arriving as well, bringing their diseases with them – corporate ‘kill off the competition’ mentalities that don’t serve Linux, merely exploit it.

What follows is a sampling of quotes from various places and assorted devs which paint a picture of a growing culture of anti-user, conformist philosophies. There’s a bit of text to review here, but I think it’s worth it to hear what GNOME devs have to say about their intentions and goals, in their own words, and what others are saying about that!

---

Editor’s Note: All emphases below are added.

To start us off, Clem, a member of the Linux Mint dev team, writes:

I’ll apologize in advance for the sarcasm here.. I need to take another cheap shot at the GTKGnome developers here. GTK3 isn’t a reliable API. Maybe it should be called libgnome instead. GTK3.4 came with Gnome3.4, and wasn’t compatible with previous GTK3 themes. This means all GTK3 applications looked really ugly not only with all the GTK2 themes which don’t support GTK3 (almost all of them), but also the few which did. With this in mind we had three options:

• Give you a desktop with poor integration and applications which look different based on the API they use (which is completely unacceptable)

• Ditch all GTK3 applications from Mint and replace them with earlier GTK2 versions, or GTK2 or QT applications (this includes Gnome apps, but also Gdebi, Transmission and a few others)
• Rant like mad, remove all themes, and waste countless hours in giving Mint-X and Mint-Z proper GTK “3.4″ support even though it’s likely to break again in 3.6…

We went for option 3 “this time”. I hope this little example was enough to convince 3rd party developers not to use GTK3. I couldn’t find any release notes or documentation explaining the regression or how to solve the issue.. I genuinely get the feeling that GTK 3.4 is developed for Gnome 3.4, that it doesn’t really matter if it breaks things and that we’re not supposed to use it outside of Gnome.

Received via my email, a long-time SpaceFM user and contributor writes:

SpaceFM Dialog features will allow me to get rid of zenity. I’m no longer interested in zenity because with Gnome 3 updates, it lost some features, and I had scripts not working as they should. I didn’t understand why. Even the zenity docs were not updated about removed features. I had to search in bug reports to find that developers removed some features that were no longer considered useful with the new Gnome Shell paradigms. Wow. So devs think that zenity is Gnome Shell only? It can’t be used in other environments? I was very frustrated.

This situation was very common during Gnome 3 updates. Lots of removed features, no dev communication, no consideration for users, etc. I was using Gnome for years, but with Gnome 3, devs have gone too far and I didn’t want to be treated this way as a user and an active bug reporter. It was clear to me that I would never use Gnome again.

I really don’t like the turn that takes the development of free software. When I discovered free software about 2004, GNU/Linux was a way to use our computers ethically, the way we wanted and on the hardware we wanted. Now, there’s clearly an adoption of a very closed-source way of functioning, more and more disconnected from users and obsessed with brand control.

Received via my email, the developer of a popular GTK3 theme writes:

I have a lot of messages from users saying that my [REDACTED] theme makes Gnome more usable again. But it’s such a pain to develop a GTK 3 theme. It’s always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6. I’m so tired of that. For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration. And almost no documentation. A lot of trial and error. Developing a GTK 3 theme is not fun at all, it’s just very frustrating. This morning, I received a message from a user that tested my theme with GTK 3.6.1 (I developed the GTK 3.6 branch of my theme on GTK 3.6.0) and I can see a lot of bug rendering in his screenshot. Is it really just because of a minor version difference (3.6.0/3.6.1)? Sometimes I wonder why I’m still using GTK.

There are many such comments. For example, GTK3 theme developer half-left writes:

I’m sorry to say this but I am abandoning any GTK3 theme making from now on. Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making. As if GNOME Shell isn’t bad enough sometimes with every version being broken, GTK3 is even worse. For those of you who wish to make GTK3 in the future, good luck, you’ll need it.

Honestly, Windows and OS X actually look more attractive to me right now.

I’m not leaving dA, just pondering what customisation to do next.

The developer of the popular Swar themes writes:

The problem therein is why should we as supporters of Gnome who gave our time for free get slapped in the face with new theme requirements and our work broken and failing to do more work at out own time to support something where the requirements could change again in another 6 months or less and again break our new work? It’s a real pickle no doubts there!

This would be a continuing ‘rat-race’ to keep up and for myself I am running my own business and am also a step-in manager of a business for the full-time managers so I can not devote months on months to develop themes.

 
How can anyone remain interested in a system developed by devs who don’t care about their users? Do you know what GNOME devs think about themes and extensions?

In the following discussion, someone suggested creating a website for Gnome Shell extensions and themes. Someone else said that he was already working on such a project. Below are some tasty answers from Gnome Shell devs, considering users only as walking billboards. From Gnome 3 Extensions/Themes Website?:

Allan Day wrote:

I knew this was on the cards but I have to say that I am surprised that it is actually being pursued in this form.

Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We’ve fought long and hard to give GNOME 3 a consistent visual appearance, to make it synonymous with a single user experience and to ensure that that experience is of a consistently high quality. A general purpose extensions and themes distribution system seems to threaten much of that.

I’m particularly surprised by the inclusion of themes. It seems bizarre that we specifically designed the GNOME 3 control center not to include theme installation/selection and then to reintroduce that very same functionality via extensions.

So, I would very much like to hear about how this web site will relate to our core design goals.

Allan Day wrote:

One particular issue is the ability for users to modify the top bar via extensions. This part of the UI is vital for giving GNOME 3 a distinctive visual appearance. If we do have extensions, I would very much like to see the top bar made out of bounds for extension writers, therefore. We have to have at least *something* that remains consistent.

Allan Day wrote:

> Milan Bouchet-Valat wrote:
> I think the main reference here is the way Firefox manages
> extensions. Many people use stock Firefox, and it works very well,
> but many others like to play with appearance (personas, equivalent to
> our themes), or need a specific feature (extensions, in both
> terminologies). This example is quite positive. The fact that people
> can easily extend their desktop encourages them to support it and
> hack on it. IMHO, the available stock of extensions is one of the
> reasons why many GNOME fans use Firefox rather than Epiphany.

Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn’t a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. The visual appearance of a desktop/OS might be far more important to its marketing than a browser might be, for example.

[...]
> At the end of the day, people who use them know that they aren’t
> stock GNOME, and how to disable them if they want to get the default
> experience.

The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?

> Finally, extensions makes it easier to enforce a common design that
> works for 95% of users, while allowing the remaining 5% to do what
> they like. This is a good way for designers to turn down complaints
> and keep hackers happy.

We’ve always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?

William Jon McCann wrote:

I agree with Allan. I am really concerned about this effort to encourage and sanction themes and extensions.

In addition to the things Allan mentioned in the preceding mails, I think there are a few other issues to consider.

1. We rely on enthusiasts for testing
2. We rely on enthusiasts for building our brand

I think it is clearly detrimental to both to have more fragmentation and reshaping, recoloring, and replacing the user experience – especially in this critically important group of early adopters.

The issue is not whether extensions may be useful. The issue is whether they will be harmful to our larger goals.

If we aren’t careful they will be. I agree with Allan that, if we insist on going through with this idea, we at least have a few places in the design that remain unchanged. I think that themes should notbe included, that the top bar should not be changed, and that the overview should not be fundamentally altered.

 
Nothing Like Competing With Yourself
Even some of GNOME’s own software is seen as a competitor, like Gnome fallback mode vs Gnome Shell:

“the presence of fallback mode is having a negative impact on the quality of the primary GNOME 3 user experience” – link

See also this report: (fallback) [meta] Remove fallback support code

We could also suppose that non-default options are seen as competitors (of default options), as suggested by the following report:

tekstr1der wrote on 2012-03-22 15:04:34 UTC:

Still experiencing this bug (7 years old now) of desktop icons stacking/overlapping on the latest daily build of Ubuntu Precise 12.04.

Is the nautilus desktop abandoned?

André Klapper [developer] wrote on 2012-03-22 15:29:14 UTC (In reply to
comment #25):

> Is the nautilus desktop abandoned?

Sure [it is], as gnome-shell has been the default GNOME desktop interface for a year now and having Nautilus render the desktop is disabled by default.

Getting in deeper, not only are GNOME devs content to break their own desktop, but they want features removed from apps simply because GNOME no longer supports them!

For example, Gnome Shell doesn’t support status icons, so GNOME dev ‘mccann’ filed a bug report to a Transmission (BitTorrent client) dev to say that this option should be removed. Why should it be removed? Because Gnome Shell doesn’t support it anymore! Apparently in GNOMEland there are no other desktop environments (remind anyone of Microsoft?) From Don’t use a notification area icon in GNOME 3:

mccann writes:

In the upcoming GNOME 3 we won’t be supporting notification area icons (status icons)…

Transmission has an option in the Desktop tab of the preferences to “Show Transmission icon in the notification area”. This should probably be removed.

charles (developer of Transmission) writes:

So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator, GtkStatusIcon, or nothing at all, over such a stupid feature?

Removing it altogether, as you suggest, will hurt XFCE users.

I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

In order for this ticket to move forward, I’d like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.

mccann replies:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I’m sorry that this is the case but it wasn’t GNOME’s fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

It is my hope that you are a GNOME app…

We must choose our side. Is this a war? And can we really and seriously believe that one of the main GNOME devs doesn’t know what XFCE is?

Also, we see an indication of how decisions are made on GNOME:

mccann writes:

FWIW, I don’t think Transmission is at all impaired by removing all of above – app indicator and status icon. I have never used it with the status icon myself.

Mr. GNOME Developer doesn’t use this feature, so it must be the case for all the world. So why keep it? It’s unneeded by GNOME!

 
As for those creative little panel applets…

William Jon McCann wrote:

I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see “Remove from panel” when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful.

Let’s say that we are trying to define either a product or a product platform. I don’t think it is possible to do this without some “brand” coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity.

Even those of us in the developer community would have a difficult time identifying a GNOME desktop in 3-5 steps. Let’s try this with Windows: “Start” or Windows symbol menu, (usually) bar at the bottom. This works from Windows Server products all the way to embedded Windows on smartphones.

With OS X: Apple logo menu, menu bar at the top, (usually) a dock. Even though the iPhone doesn’t have the same software identification experience it retains the platform design branding on the hardware and uses familiar themes in the software visual design. There is usually no doubt that it is an Apple platform.

With Android: who knows…

So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.

That’s what excites him, but likely not what excites users.

Apparently in the view of these devs, users are merely walking billboards for their ‘brand presence’, to hell with what the users actually want. You’re expected to change your way of working every 6 months just because these devs want to impose their way of working on all their users. Developers decide what is Good (with a big G), without any possible customization by the user.

The screensaver was removed from Gnome 3 “by design”: What is the status of the screensaver in GNOME3?

The request for the ability to customize the Nautilus menu bar was closed as WONTFIX, with this beautiful explanation:

Cosimo Cecchi wrote:

We decided to streamline the nautilus design for 3.0, and we finally decided there’s no use for an editable toolbar in Nautilus.

Meanwhile, a user request: please add a way to customize the toolbar

The report asking to reintroduce the location/path toggle button was closed as WONTFIX. The sacrosanct Nautilus interface is more important than users’ needs:

André Klapper wrote:

There are currently no plans to reintroduce the location bar by default or to provide a toggle button as the cluttered interface has been simplified for 3.0.

Meanwhile, a user request: Reintroduce location/path bar toggle button

 
Same for gnome-power-manager…

Richard Hughes wrote:

Sorry, but the whole point of gnome-power-manager is to save power without getting in the way of what the user wants to do. It’s not going to let you set the “performance” governor any more than it lets you increase the brightness on battery.

Meanwhile: brightness_dim_battery missing from gnome-power-preferences

The Power Off option was removed from the Gnome Shell menu. Devs know what users want to do, more than users themselves:

Owen Taylor wrote:

The Power Off option is hidden because we don’t believe it’s necessary in that menu [...]. The primary way that a user would shut down (if they, say, need to disconnect power) would be to log out and shut down through GDM.

Meanwhile: Removal of the power button is inconvenient for desktop use and wastes energy

 
Features you ask? Let’s remove some:

Remove “Create Launcher” entry from desktop nautilus

A really nice quote, Bastien Nocera writes:

we’re not designing a desktop for people who like to choose their own terminal emulators

And in the last version of Nautilus (3.6), features are really a has-been concept. From TechRepublic:

The latest bit of crazy to come from the GNOME camp is the list of features being removed from the Nautilus file manager (as of 3.6). This short list looks like:

- Compact View gone
- ‘Type Ahead Find’ gone
- ‘New file’ templates gone
- Application Menu gone
- ‘Go’ menu gone
- F3 split screen gone
- ‘Tree’ view gone
- Bookmark menu items gone
- Backspace shortcut to return to parent folder gone

 
Nor is this pattern limited to GNOME. With Ubuntu, it’s all the same. There is a request for the ability to move the Unity dashboard, which is to the left of the screen. Mark Shuttleworth himself came to close (WONTFIX) this report the next day with this beautiful explanation:

Mark Shuttleworth wrote:

I’m afraid that won’t work with our broader design goals, so we won’t implement that. We want the launcher always close to the Ubuntu button.

status wontfix

And notify configuration? Mark doesn’t want settings (and neither do you):

Mark Shuttleworth wrote:

The design of Notify-OSD is specifically not clickable, and we would NOT accept patches to change that.

Another prime example of this behavior in Ubuntu devs is the Launchpad example. After years of criticism because it was closed source, Ubuntu eventually released the code, but just for its own benefit. It’s so complicated that no other webforge uses it. It is coded only with the website Launchpad.net in mind. They really don’t want ‘competition’.

Even Launchpad icons are not free:

The images/icons are still copyrighted traditionally, to protect Launchpad’s visual identity. [...] From our point of view, we have open-sourced Launchpad to improve our hosted service.

And were you thinking of actually USING it?!

Building and running Launchpad requires a computer running Ubuntu.… Running a stable production instance would be much harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at Launchpad.net. Note: the changes introduced by the install script may break your current web development setup, so it is advisable to try Launchpad in a virtual machine or an LXC container, as described above.

The following bug report is instructive: Launchpad wiki contains zero information regarding running launchpad on your own domain

The reply? WONTFIX, with this explanation:

Launchpad’s code was opened to permit the Launchpad community to contributor [sic] to the project. The information provided is the same information used by Launchpad developers. Artwork in the project may only be used for development, so instructions to run a public instance of would put the contributor in violation of the license. The launchpad team dos [sic] not maintain the production configurations of Launchpad, they do not know exactly how to setup an other instance.

Does this sound like Linux to you? It’s surreal, like this FAQ entry, Can I run Launchpad on my own server:

Yes, you can, but keep the following things in mind:

As per https://dev.launchpad.net/LaunchpadLicense, please replace the images and icons with your own.

Also, Launchpad’s production configuration information and some configuration-specific admin scripts are not part of the Launchpad code base; you’d have to reinvent those in a way appropriate for your setup.

Finally, keep in mind that Launchpad’s code is under very active development, with hundreds of changes released each month. Syncing your private instance with the upstream code base may be risky because your private instance won’t necessarily get the same data migration treatment that the main instance gets. Essentially, there’s a risk of a private instance becoming an unintentional fork, where its code cannot be safely updated due to the data in the local instance being incompatible with the latest database schema or code assumptions.

[...]

So the answer is “Yes, you can run your own instance”… but please be aware of the risks and the lack of support before doing so. We don’t recommend it; we’d much rather have you using this Launchpad instance and contributing to its improvement.

Some comments from people trying to actually use Launchpad:

I wanted to have my own instance a while ago, mostly for the bugs and maybe the answers and blueprints parts, but in its current form, installing and maintaining up-to-date such a beast is a nightmare. The install guide is oriented toward lp.net developers and contributors, not toward sysadmins wanting their own instance. The code is nowhere near a packageable state (at least it wasn’t last time i looked). I guess the latter has been made on purpose – or should i say, no effort has been made in that direction… – link

You might be saddened to know that the guys working on launchpad in #launchpad on freenode officially suggested I _not_ setup another launchpad instance. Some of these people were Canonical employees.

I wanted to play with mirroring the gnome bugzilla in a dev launchpad instance just to see how the software worked. I was primarily told that launchpad (as software) is unable to sync with another launchpad instance and would be strongly discouraged from doing what I’d envisioned. I was also told that while they were very interested in any improvements that I might make, they did not want another big launchpad instance. They promote launchpad.net as a service vs launchpad as an open source bugtracker.

So… my official opinion on this is that Launchpad is dumped code that is not really a community effort. Canonical is against any competing big launchpad installs and is very uninterested in splitting parts of it off such as Malone so that someone can use it as a stand alone bugtracker… – link

I highly doubt it. I’ve been trying to set it up in a VM at work for a few weeks now, and it is very much impossible. The lack of / incomplete / incorrect documentation, bizarre deployment process, and hidden / unavailable components makes for way too high of a secret sauce to normalcy ratio for any human to figure out. We’d *like* to use it for a group of projects (both FLOSS and proprietary, both public and internal), but so far my attempts to give it a trial run have been an utter failure. – link

Brand, brand, and brand. Even such a simple and basic question like the following becomes “complex” and can’t be answered by Launchpad devs because of their brand obsession. From What license is used for bug icon in Launchpad?:

Asked by Andrey Cherepanov on 2009-04-20:

I like nice bugs icon in Launchpad. On what license I can use they in my project?

Karl Fogel (kfogel) said on 2009-04-28:

We’re discussing internally; more soon! It’s a complex question, because some images, like the logo, identify strongly with Launchpad.net, whereas other images might not identify so strongly (not sure if the bug icon is in that category, we have to figure that out). Because of the “recognizeability” issue, this is not just about copyright license but also about trademark policy. So, we’ll get back to you as soon as we can. Thanks for asking.

No answers followed – apparently the decision was made to traditionally copyright all icons and images.

A user writes in email:

I was very happy when I knew that [Launchpad] was open sourced in 2009, but I quickly disenchanted. And Launchpad is not even translated after almost 9 years of existence. Wow. You know that the community is not really involved when a software is not translated after 9 years, including last 3 years as open source software.

Look also at Ubuntu One: Server-side is closed source.

 
Then there are the Amazon-affiliated advertisements in the recent Ubuntu 12.10. Now, when you search something on your local computer (applications, files, etc.) with the Unity dash board, your search for local files is also sent online to display Amazon-affiliated advertisements. The Electronic Frontier Foundation wrote an article about this,
Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks:

Technically, when you search for something in Dash, your computer makes a secure HTTPS connection to productsearch.ubuntu.com, sending along your search query and your IP address. If it returns Amazon products to display, your computer then insecurely loads the product images from Amazon’s server over HTTP. This means that a passive eavesdropper, such as someone sharing a wireless network with you, will be able to get a good idea of what you’re searching for on your own computer based on Amazon product images.

[...]

It’s Not Just Amazon

The new version of Dash that comes with Ubuntu 12.10 introduces more than just Amazon ads. It includes a new legal notice that you can see by clicking the “i” in the corner of Dash that states that by using Dash, you automatically agree to send your search term and IP address to a number of third parties:

> Unless you have opted out, we will also send your keystrokes as a
> search term to productsearch.ubuntu.com and selected third parties so
> that we may complement your search results with online search results
> from such third parties including: Facebook, Twitter, BBC and Amazon.
> Canonical and these selected third parties will collect your search
> terms and use them to provide you with search results while using
> Ubuntu.

Ubuntu’s Third Party Privacy Policies page lists all of the third parties that they may send your search term and IP address to, and states: “For information on how our selected third parties may use your information, please see their privacy policies.” In other words, once they give your data away, it’s no longer their problem.

So Ubuntu doesn’t even care about what third-parties will do with their users’ data. Microsoft, anyone?

You feel that something is changing when your local searches are accompanied by corporate advertisements.

 
Time to use KDE 4? It has the same trends. A user writes:

When Gnome 3 was released, I tried KDE 4.x, but some easy and basic settings with KDE 3 were no longer possible, for example just changing the bottom panel color. Now it’s so complicated. You must create a theme with special SVG format files…

Also, the order of windows in the windows list was changed, without any possibility to customize it or to set it the way it was with previous versions. Now it’s so unergonomic, because when you open a new window, instead of putting it in the end of the list, it moves all already opened windows in the windows list of the panel, so the order is always changing. See this report: Task Manager setting “Force row settings” changes button sort order from row-major to column-major

It was opened in 2009 and closed as WONTFIX, even if there are proposed patches, a lot of user activity, 120 votes and even a user proposing a package rebuilt with patches.

KDE3 was an immense field of options, but I suppose that now, KDE 4 adopts this kind of reasoning. See rekonq: rekonq should show a menubar / make menubar switchable

This report asks to add in rekonq, the default KDE web browser, an option to have a real main menu bar (like most software) instead of an icon that we must click to display a drop-down list menu. Very good dev’s answer, Andrea Diamantini wrote “We decided this way, sorry. And we really like it. No plans to reintroduce it.”

OK, so devs don’t care anymore about users, even in KDE.

I could write about Firefox, removing features, like the “named separators” feature, just because devs don’t use it, and even if a lot of users complain about data loss because they were relying a lot on named separators to classify their bookmarks and they lost all that during Firefox updates.

What’s the problem? Is free software now just a market for devs working for very big tech enterprises and wanting to feel power and fame as if they were a big boss?

---

 

I think the lesson here is that as long as users put up with such nonsense, perhaps for the sake of the latest (non-configurable) bells and whistles, this is what they’ll get – dwindling options in Linux.

What is or isn’t done in GNOME is up to its devs, but nothing says you have to use it, or continue to use it as it devolves into Microsoft Windows.

And reading those dev comments, it’s so clear that most of their thought and energy is devoted to their marketing and ‘brand presence’, and so very little to making quality, innovative software. By some strange coincidence, that’s just what has been largely lacking in the field of Linux apps.

I hope you’ll pass this article along to help raise awareness of what these devs have planned for Linux and YOU.

Many thanks to additional unnamed (by request) contributors to this report!

UPDATE: A print article based on the above article and covering wider impacts in Linux will be appearing in Issue #122 on January 17, 2012 in Linux User & Developer magazine – be sure to pick up a copy:

Earlier reading:

• Gentoo On systemd, Torvalds On Bullshit, udev Forked
• Red Hat Flag (Or, What Is Red Hat Doing To Linux?)
• Udisks2: Another Loss For Linux

SpaceFM 0.8.2 and GTK3 Alpha Testing

SpaceFM 0.8.2, a maintenance release, is available. This fixes hal build issues (even though hal is no longer actively developed, please continue to report any problems building spacefm with hal) and a few other issues present in 0.8.1.

Also, a gtk3 branch of SpaceFM is now available for alpha testing. Much thanks to BwackNinja who has put a lot of work into bringing SpaceFM into GTK3. This branch can be built for either GTK2 or GTK3. While you may encounter some GUI issues (please report them so this branch can mature!), the file operations should be as stable as in 0.8.2. The more feedback we receive on GTK3, the faster it can evolve and move toward inclusion in the stable release version.

For the details on the 0.8.2 release, and also how to test the gtk3 branch, please see News.