GTK 3.10 Drops Menu Icons and Mnemonics
At the risk of turning this into the ‘bad news blog’, I have discouraging news regarding the release of GTK 3.10, which has now reached Debian Testing.
While working on SpaceFM recently, I noticed that all of the menu icons are gone.
No menu icons, meaning no app icons in the Open menu. This is the new GTK3 default, unannounced as far as I can tell, and not publicly discussed. I see from an Ubuntu thread back in 2009 that GNOME made this their default back then. That thread indicated that GNOME (which I don’t use) has a configuration editor to turn menu icons back on, and there was rumor of the option being removed eventually. The developers deemed it “less cluttered”.
In GTK 3.10, you can still add the line ‘gtk-menu-images = true‘ to ~/.config/gtk-3.0/settings.ini to turn them back on. Yet if this was already the GNOME default, why make it a new GTK default five years later, breaking current behavior? Are they planning to disable them entirely soon? A quick search reveals no discussion or documentation on this change.
As an app developer, I can tell you that most GTK and GNOME users won’t change that setting, or even be aware that it exists. Thus my app will be icon-less, and the settings for customizing menu icons in SpaceFM won’t have any effect. I thought GNOME was always the icon-driven UI compared to KDE, so this seems very strange.
No Mnemonics Either – At All
In addition, as you can see in the above shot, mnemonics have been removed entirely. These are where eg “Copy” in the menu has an underlined ‘C’, allowing you to press Alt+C to activate it. SpaceFM allows you to customize these too. Mnemonics have also been removed from dialog labels, meaning, for example, you can no longer press Alt+N in SpaceFM’s rename dialog to put the cursor in the Name box, and you can’t click an OK button by pressing Alt+O.
Unlike the missing menu icons, it appears that mnemonics have been permanently disabled. Per the GTK 3.10 docs: “gtk-enable-mnemonics has been deprecated since version 3.10 and should not be used in newly-written code. This setting is ignored.” IOW, it’s also impossible to turn them back on with gtk-enable-mnemonics = true in settings.ini, and themes can’t override this either. I say this appears to be the case, because I can find no further documentation or discussion of this change. [UPDATE: It seems you can press the Alt key once to make the mnemonics appear while the mouse is over an item. Anyone know how to disable this feature and make them always shown? Please leave a comment.]
Good luck to disabled persons with limited or no mouse use. And based on feedback, many people use these mnemonics, myself included. Key shortcuts provide a much faster UI than clicking a mouse, especially for commonly repeated tasks.
Fortunately, SpaceFM users can choose a GTK2 build of SpaceFM (most distros offer packages for both for compatibility with MATE, etc), and I personally plan to drop use of GTK3 due to this change, as well as their breaking existing defaults and behavior. I don’t want to deal with lost and broken functionality everytime I update my system – it interrupts my workflow. Plus I use mnemonics at times, especially with annoyingly slow touchpads. Yet for apps that have ‘moved forward’ to GTK3, such as Roxterm, we’re stuck with mnemonic-less menus and dialogs.
What is the vision and motivation behind permanently removing such core UI functionality, not just changing the toolkit default, which is bad enough, but killing it entirely? All that GTK and app code, debugged and working well, now in the trash bin. Whatever their vision is, I don’t like it. Their rampage of removing functionality is clearly just getting started.
At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet. This change doesn’t require me to re-code anything, it just diminishes the user experience when GTK3 is used. I had planned to make the GTK3 build the default soon, but I believe I will stick with GTK2 as a default, and for stability I recommend that to users. If it comes to a point where I can’t support both, I will drop GTK3. I’m not chasing after all their time-wasting breakage. And many projects have been resisting the move to GTK3, which I think is wise. I guess it’s telling that the GIMP project, the original developer of GTK (GIMP Toolkit), is sticking to GTK2, and they’ve been told not to expect to be able to use GTK3 for such a robust app.
This still presents problems, because using a mixture of GTK2 and GTK3 apps on your system is wildly inefficient. This means that library components of both versions must be resident in memory, as well as all the components related to GTK, such as icon caches, etc. You’re basically doubling the system requirements and slowing it down. For this reason, I strongly advise app developers to support a hybrid GTK2/GTK3 build. While it requires a few ifdefs, it’s reasonable. See SpaceFM’s gtk2-compat.h for some ideas.
Further, developing an app on a toolkit that is no longer actively developed or supported presents obvious problems. Yet GTK3 is supported so poorly, and the developers of it respond to app developers and users so arrogantly and dismissively, that it’s effectively the same. Yet how long will GTK2 remain compatible with changes in X, glib, and other components? Lets hope some forks get going strong.
This solidifies my conspiratorial opinions that GTK is deliberately being driven into the ground by Red Hat, alienating users and developers, both to turn the corporate-developed Qt into THE monolithic Linux UI toolkit, and perhaps to convert GTK into some kind of tablet-only nightmare. “Linux is a government, military product, right down to its core” – the core engineering is controlled almost exclusively by Red Hat, regardless of what distro or DE you use. I guess the military isn’t keen on recruiting disabled persons, so why bother with mnemonics? And who needs icons in a colorless corporate world? I can understand why app developers, even in Xfce and LXDE, are being slowly driven to Qt, yet once everyone is in that corporate boat, where will the captain take it?
29 Comments
Sorry, the comment form is closed at this time.
IgnorantGuru's Blog 
Small nit: gtk and qt are not just for Linux: they work on other Unix likes as well
True. When I say Qt will be THE monolithic UI toolkit, I don’t mean it will be limited to Linux, but that Linux apps will effectively be limited to Qt (if they want internationalization, themeing, and other modern features). One UI for all, like Windows. No choice.
As for GTK, development is controlled tightly by Red Hat – they make all the decisions. Obviously their focus is on Linux, and they have already demonstrated little concern for other OSes. For example, they were pushing hard to make systemd a required dependency of GTK, despite the fact that it made GTK unusable on OSes without systemd. They are holding off on this for now, but given their track record of ignoring screaming complaints, it won’t surprise me if they dis and dump others down the road. Likewise, I think if people complain about the mnemonics loss, they’ll just ignore them and proceed.
I just noticed that my older screenshots of SpaceFM also show no mnemonics, yet I only lost them with my upgrade to GTK 3.10. I make the screenshots with Adwaita theme even though I don’t use it normally. So apparently this removal of mnemonics has also been a GNOME default for some time via their theme. Same for the menu icons – a GNOME default now being pushed on all of GTK. It shows how GTK is being developed exclusively for GNOME, and any features they don’t use are simply being cast away (as my ‘rotting in threes’ article discusses in detail). They don’t use mnemonics in GNOME, so they simply discarded that feature and the code. The routine breakage of third-party themes is another example – Adwaita (and the Windows and Mac themes) are all they really support.
I could be wrong but I think older Adwaita versions might just be using the same “only show mnemonic underlines while Alt is being held” behaviour that appeared in various GTK+ 2.x themes.
It seems you’re correct. Not sure about Adwaita, but in my 3rd party theme if I press Alt key once, then the mnemonics appear, but only while the mouse is over particular menu items. Next time I open the menu they’re gone again. Obnoxious behavior imo. Does anyone know if there’s an option to make them always appear?
I’ve gone back to spacefm-gtk2 and I think I’ll be happier here. I’m actually noticing that there really isn’t anything about GTK3 I miss, and as Paul mentioned below there are so many more GTK2 themes (since they made GTK3 theme development near-impossible.) I’m not impressed by the minor bells & whiles they’ve added in GTK3. More loss than gain.
I don’t know about 3.10 yet but as I upgraded my gentoo on 3.8 lately all my gtk3 apps went broken: scroll with a mouse wheel doesn’t work anymore. I changed the SpaceFM ebuild to use GTK2 but I’ve few apps that are gtk3-only… And not being a developer, I’ve no faguest idea how to fix the damned thing!
From recent reading (past 6mos) I’ve gained a sense that GTK is increasingly losing whatever relevance it held. The younger crowd lacks tolerance for the sort of bullshit (breakage) we fogeys have tolerated. Hello node.js + json + html; goodbye Xorg and the rest of your stack.
I’m running Arch and have a few packages on ignore with Pacman – SpaceFM, Roxterm and Cairo-Dock (& plugins). I rebuild as GTK2 when updates are available.
I have yet to find a GTK3 theme anywhere near as good as my GTK2 theme (or even bearable) and they are also painfully slower in GTK3 form. I’m not running a DE and have cobbled together as best I can a GTK3 version of my theme to cover the cracks.
Here’s hoping someone will pick up and run with a fork of GTK2 (I cannot code unfortunately).
“Fixing” the GNOME 3.10 upgrade
Apparently button icons also affected, although contrary to what it says there, gtk-menu-images does work. It seems it’s default value merely changed. But nice rant. :)
Yeah the option works again, because a few people complained and eventually commits were reverted ( see https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-10&id=8ee2c87acbccadf9d300b9891ce4aa9e02fda7eb and https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-10&id=8ee2c87acbccadf9d300b9891ce4aa9e02fda7eb ) and with 3.10.3 the options work again, having indeed only their default values changed. But until then, and by the time of the post, they were just completely ignored.
So they did initially remove all icons from menus and buttons with no way to show them.
And they seem to have relented only on removing the option at the same time that it was deprecated. So presumably they’re going to permanently remove the ability to show icons in the future.
Yes, at first GtkImageMenuItem would not show images, and they said they didn’t see how that was breakage/a problem… The only solution to show images was for devs (of every app) to force a call to gtk_image_menu_item_set_always_show_image() on every menu item (users had no choice anymore). Because why should a widget called GtkImageMenuItem show an image?…
Anyway, I believe the idea is for GTK4 not to include GtkImageMenuItem (or a replacement), so then, or if you want to use some now in a non-deprecated way, you need to e.g. pack a GtkImage & GtkLabel yourself in a GtkMenuItem. Personally I’ve made my own image menuitem w/ a few added features (https://github.com/jjk-jacky/donnatella/blob/master/src/imagemenuitem.c)
IgnorantGuru, will you ever port SpaceFM to qt? I used to be a GTK-app guy, but with GTK3 I’m trying to ditch gtk-apps in favor of qt-apps.
Depending on how attached you are to SpaceFM specifically, the Qt port of PCManFM might satisfy your needs.
http://blog.lxde.org/?p=1090
My advice here is: don’t get too attached to one UI, especially in the current climate. Why limit your apps to one UI?
I also suggest avoiding desktop environments completely. Choose a simple distro you like, choose a window manager, and if you want, a desktop manager. Then add whatever apps, servers and daemons you want, preferably ones that are independent of particular DEs. Debian makes this pretty easy (at least for now, systemd on it may not be so nice). Unless you have fairly limited system specs, you should be able to comfortably run a mixture of Qt, GTK2, GTK3, and other apps. Granted, not all apps will look and work the same, but the human brain is a marvelous preprocessor, and variation makes for a creative environment.
At the risk of sounding like a commercial, SpaceFM, while not for everyone of course, offers a lot in such a context. It’s very flexible in terms of the environments it can work in, and the system tools it can use – virtually anything you want. And you can add powerful custom commands, even mini-apps. While it is GTK, it is very flexible in appearance and operation.
What this means for a file and desktop manager is that you can bring it with you into almost any system environment, including all the custom tools you’ve added to it, and it will work the same. It has also reached a high level of stability, and development is slow and careful. I find these are good qualities in a file manager – leave the rapid, exciting development to other apps, but use some file manager that gives you a stable home.
And I think spacefm-gtk2 is the way to go if you want less breakage and change there.
And there are other file managers that are quite stable too – take your pick. Though SpaceFM is probably the most flexible, which creates stability as you choose to change underlying components and tools. Where it may be weaker than some, such as built-in network support (it’s mostly ad hoc there), you can always use another file manager for that, and PCManFM is a good choice because it looks similar and has gvfs network support.
I’m the guy who asked the question. Thanks for the answer.
I’ve tried many file browser and there’s no way I’m moving away from SpaceFM, so if you won’t port it to Qt, gtk is gonna stay on my system.
I actually use Arch + Openbox. My concern is that I have to keep gtk2, gtk3, qt4 and now even qt5 already with some apps like cmplayer. It really doesn’t make much sense to me. I’ve had no problem so far but given the path gtk has taken with gtk3 (many developers recommend to stick with gtk2) I was thinking about switching to qt.
A technical question regarding the toolkits. Wayland is just around the corner. Gtk2 will not support it, so what do you have in mind? stick with gtk3, hope that gtk4 arrives in time and brings a good change?
> My concern is that I have to keep gtk2, gtk3, qt4 and now even qt5 already with some apps like cmplayer. It really doesn’t make much sense to me.
The real problem here is that the UI toolkits are becoming mammoth, getting mixed up with DEs and other stuff (eg GTK wanting to require systemd), rather than sticking to just UI. It’s understandable that apps will use a variety of toolkits choice is what makes (made?) Linux great. I also support the concept of not requiring all older software to be rewritten everytime a new version of a library comes out. This is one serious problem I find in Linux (not just re spacefm) – loss of older apps which are broken by newer system changes, or it takes a lot of manual system config to get them to work. Most development lately is about devs trying to keep their stuff running, rather than much real innovation. But this is how it is in Linux, and I think the simplest solution for now as a user is to just buy more memory. I personally also stick to lighter, more independent apps, as opposed to apps that pull in a whole DE when you install them.
> I’ve had no problem so far but given the path gtk has taken with gtk3 (many developers recommend to stick with gtk2) I was thinking about switching to qt.
As a user, I run a few Qt apps – don’t really care. As a developer, there aren’t great choices, and it’s hard to know what to invest your time in. Toolkits should excel at backwards compat (and traditionally have), because people base a lot of work on them. The GtkImageMenuItem is a good example. Red Hat could have just left that all as-is (minimal maintenance required), and created a new widget for what they want to do in GNOME. Instead they’re breaking everyone’s work, attempting to force everyone to rewrite code and abandon stable, tested code. This is true of GTK3 in general – it should be thought of as a fork, not a new version, and really that’s what it is in everything but name. Red Hat has really screwed it up – if they had done it reasonably, no one would need to be running GTK2 now, because GTK3 could run GTK2 apps just as well. And it’s not that hard to do – that’s what the API layer should provide. Maybe they should have created a new (stable) theme API, but there was simply no need for all the code breakage they created – it’s deliberate.
> A technical question regarding the toolkits. Wayland is just around the corner. Gtk2 will not support it, so what do you have in mind? stick with gtk3, hope that gtk4 arrives in time and brings a good change?
Some initial work on spacefm-wayland has been started by a third party here with my cooperation, and there is a spacefm-wayland repo that does now build, but isn’t fully functional, apparently due to some remaining deficiencies in GTK3’s Wayland support, not because of SpaceFM’s code (except for the desktop code, which is based more closely on X). Others are welcome to contribute and I’ll be happy to add others as contributors to that repo – just ask.
As you say, that does require GTK3. Most of the work porting SpaceFM to GTK3 was done by BwackNinja, with me mostly pestering him endlessly to bring it all up to SpaceFM quality, which he did a great job with, and I’ve maintained the code in a hybrid way since. Yet now building SpaceFM you would normally see a whole bunch of deprecated warnings (which are normally filtered out by the build system). Eventually, probably with GTK4, this will create outright breakage. Maybe BwackNinja or others can help keep SpaceFM running on newer GTK versions – it’s usually doable. But that will depend on what Red Hat does with it. As discussed in this article, it doesn’t sound like they’re aiming to support robust apps – they’re removing much functionality.
Wayland has a long way to go before it will be mainstream. And many Linux users worldwide tend to be slow to change, partly due to older hardware requirements. There are still avid users of HAL, for example, even though udev has allegedly replaced it for years (SpaceFM supports both). Personally, I prefer to lag behind, both as a developer and a user, especially with the newer trends in rapid, careless development.
So overall I will let the dust settle, just keeping an eye on things for now. Right now I’m finishing up some new handlers in SpaceFM that are really cool and add some great functionality, nothing much to do with GTK (although OmegaPhil may differ since he did most of the GTK work on this part). Just a few last minute things to do there (including the next SpaceFM release which is overdue), and then that will be announced for early testing.
So despite all the noise I make about it (which is mostly long range thnking and planning), I’m not actually spending much time dealing with GTK issues, which is how I like it. I do have some more ideas, and those would require more UI work, so there I am a bit hesitant to invest. When I get there I’ll have to decide how to proceed. I’ll probably just continue in a GTK2/3 hybrid way for some time. I’d say GTK2 has at least a decade of mainstream usability.
“I also suggest avoiding desktop environments completely”
This is precisely what I did when Gnome 3 came out. I ditched the bloat and got stuck in! It’s actually very liberating to ‘roll your own’ and you learn more about the inner workings as a (big) bonus. I’m no expert but ‘getting your hands dirty’ makes you competent at least.
SpaceFM is my dream file manager. I couldn’t have imagined anything better! I was struggling with a fork of Nautilus with Nautilus-Actions until you came along to save the day. I find it staggering the amount of work you’ve put in to this (the documentation alone!) and udevil and I’ll be eternally grateful to you for making my desktop experience so wonderful :)
Wasn’t Gtk+ meant to be a free Motif replacement? Since 2012 Open Motif is free, too. Would be abandoning the GNOME stuff and porting the application to a proven with a stable API a viable option for the future?
I think it would be a mighty cold day in hell before I would use Qt, for reasons I’ve outlined in various posts. Too corporate controlled and subject to their whims, like Red Hat’s GTK3, and too influenced by the Windows side – I wouldn’t trust investing my time in that future. I’m also not a fan of spending my time keeping up with toolkit changes/breakage that provide no tangible gains. I would rather work on creative aspects of actual functionality rather than obsessing over what a button looks like. That’s not real software evolution and doesn’t hold my interest.
For now I plan to stick with GTK2 as a primary, and I’m willing to keep SpaceFM running on GTK3 as long as it doesn’t get too out of control. Eventually I suspect they’ll break so much stuff, and demand that deprecated things be removed outright, that I will drop it, but we’ll see. Given the number of projects sticking with GTK2, I think it has a reasonably long future. Hopefully development of it can be taken out of Red Hat’s greedy hands and moved back to ‘the community’ – if such a thing still exists. I’m hoping for a major, nicely slow-moving fork of it, perhaps as part of the MATE project (not sure if they forked GTK2 or simply use it at present, but they’ll want to keep it running).
If I did port or rewrite SpaceFM to another toolkit (it’s a prototype, though stable and useful, so a rewrite would be more feasible), I would probably shop for something less corporate, maybe even Tk/Tcl. I’m becoming less concerned with the retro look – I’d rather have that than have my time wasted on nonsense.
Yet beyond GTK and Qt, there are really no viable toolkits for a project like SpaceFM (that I’ve found). Lots of toolkits, but most have deficiencies. As for Open Motif, it’s worth a look, though I did review all the major toolkits awhile back. Yet for now I’d rather focus on my functionality. Porting and porting and porting is boring and wastes dev time. GTK2 works, lots of themes to choose from, stable and slow changes, and I have a lot invested in it. I’d need a very good reason to drop it and begin again.
Currently, FLTK is more viable than Open Motif… but that ain’t saying much. Hell, even wxWidgets is more viable than OM.
Just look at this cancer – see where Open/Cancel is: http://blogs.gnome.org/mclasen/files/2014/03/gedit-filechooser.png
Dear god, that’s atrocious.
At least with the Windows/KDE “OK on the left” button order, it’s not as obvious why it’s wrong. ( http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/ )
Even an idiot should at least be able to FEEL that, since action buttons “end the paragraph” for a UI, they should be “at the bottom of the page” in a culture that writes left-to-right and top-to-bottom.
I hear ya… but, specific to this particular dialog window:
it is probably reasonable to expect that a user who has navigated his way to a FileOpen dialog will seldom have reason to cancel. Similarly, clicking OK is probably optional/redundant here — typical workflow will be to double-click on the desired file. By breaking from convention here, the design underscores the _optional_ nature of the buttons. With buttons at bottom, too many users, too often, would wind up believing “aw, need to select AND click OK button” (Grrr… like the superfluous presence of an Apply button when, in fact, just OK will suffice)(but the dev is building the dialog with a stock toolkit widget, and the widget contains an Apply button, so users get that button whether they need it or not)
Why oh why do the GTK people think they need to break the file selector every once in a while?
I still can remember how furious I was when they removed the TAB navigation in the path entry textfield somewhere in the early GTK2 versions. In the old selector you could navigate through the filesystem without having to click somewhere.
And now this.
Desktop Linux used to be more fun back then — I still use IceWM and have always launched applications from a heap of xterms rather than a menu but I always sort of liked GTK and put up with the “features” in every new version… I think I’ll be back to tty1 if the DE Linux trends continue.
The GTK file selector was one of the reasons, why I use Windows 7 now (after 20 years of Linux). Windows has system-wide file sector, with
– a back / forward button, a path entry box with folder auto-completion and a search box on the top
– an embedded explorer window with all file management functions available
– a sidebar with bookmarks and a hierarchical directory tree available, including “Recent Places” which contains recently opened folders instead of files (that makes a lot more sense)
– a preview pane (always available, not only if the application requests it)
– a filename entry box on the bottom, which accepts custom filters and supports auto-completion
– a dropdown box for selecting predefined filters
– on the bottom right open/save and cancel buttons in the wrong order
– everything visible without hacks and completely usable by keyboard including Alt-Accelerators
In comparison the GTK file selector resembles Windows 2.0, even the Windows 3.0 one was more functional. The Linux desktop is unbearable in 2014, it is dead for a reason.
True creativity doesn’t come from the mind, it merely comes through the mind (creative vision), the mind being a tool to realize (make real, code, engineer) that vision. When the mind alone creates, it tends to create monstrosities, even horrors. In fact most of the insanity we see in our world is a result of this level of mind-only activity. Cancer is an apt word for it.
What’s funny to me about this example is that I think of a dialog like a contract – you read it from top to bottom and accept or decline. In this case it’s like he’s asking you to sign the contract before you’ve read it. How prophetic! When was the last time you signed a contract at the top? Eventually perhaps they’ll remove the Cancel buttons entirely from all their dialogs. What good are choices?
Off-Topic, but a good example of how we’re descending into mindless idiocracy:
Publishers withdraw more than 120 gibberish papers
Conference proceedings removed from subscription databases after scientist reveals that they were computer-generated.
I wonder how many people read those articles and tried to make sense of them. lol! I notice no one reported them as fakes from reading them. I also find it amusing that their solution to this peer-review problem is to use a computer program to detect the fakes. Seems they aren’t quite getting the point.
And in The Guardian version of the article, I liked this past example:
“In 1964, critics of modern art were wowed by the work of Pierre Brassau, who turned out to be a four-year-old chimpanzee.”
So has anyone seen an actual picture of this “Matthias Clasen”, just to be sure? ;)
Hi, I’m pcman, the man behind pcmanfm(-qt).
Just FYI, I wrote some docs for gtk+ to Qt migration.
http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt
http://wiki.lxde.org/en/GUI_Toolkit_Comparison
If someday you want to switch to Qt, I hope you’ll find them useful.
In the current PCManFM, we split UI and core program logic into different libs carefully.
So, it’s relatively easy to port to other toolkits. That’s why I did a Qt port in months.
I’d recommend a similar approach to you.
Qt is very good, making me much more productive, but its future is uncertain, too.
The classic desktop widgets are not very actively developed.
They now focus on QML, javascript, and all the mobile things and it’s also controlled by a single company.
There is one thing for sure. Qt has a very expansive close-source commercial version and it’s used by many software companies. So, backward-compatibility is important for them. Otherwise they’ll lose their important customers. This is not the case of Red Hat. I expect Qt to have better backward compatibility.
For now, it’s safer to split UI and non-UI code so you can have most parts toolkit-independent.
No matter which toolkit becomes better in the future, switching to it can be less painful then.
Using C++ in the non-UI parts might save some time.
C++ object works as well with gtk+ so it won’t affect the gtk+ port.
However, using GObject in a C++-based UI toolkit can be painful.
Cheers!