I wonder where this trend - fortunately a limited one - with putting confirm buttons at the top comes from? Humans naturally read from top to bottom. It naturally follows that the final action in any UI should be at the bottom.
I find these buttons at the top extremely confusing, as I often - from my experience with reading - after I've dealt with the subject at hand (in this case, picking a file), assume the natural place to confirm my choice would be after it (i.e. below it).
What are the UX arguments for placing the confirm buttons at the top of a dialog?
When Windows 95 came, (if I'm not wrong), it had an accompanying HIG book backed by actual research - I think their main inspiration was book pages, but I can't be 100% sure. OK (Confirmation) intentionally was on the left side, far away from accidental click, assuming this is a destructive, irreversible operation. "Cancel/Close" on the other hand, is closer for most users (right side), and it will just close the window.
Making Confirm/Cancel buttons this way makes no sense. I'll assume they added this just because it looks cool, as someone mentioned as well.
> Original small screen iPhone, where it's easier to reach the top than the bottom…
With phones, it's always been easier to reach the bottom. This is why tab bars have always been at the bottom. This is why soft keyboards have always been at the bottom. This is why Apple moved Safari's controls to the bottom by default.
The comment mentions original iPhone screens. They were 3.5" and we hold phones differently because of the sub 4" displays.
The idea back then was maybe to separate the confirm action from other actions located at the bottom bar.
Human Interface Guidelines changed a lot as Apple changed the iPhone form factor. But with a 3.5", most of the screen is "uniformly" reachable and the bottom is slight less reachable as you usually need to flex the thumb.
Not to mention the lack of top and bottom bevels that we only still find on the iPhone SE (3rd gen) now.
Maybe I’m an outlier, but it’s been over a year and I still don’t like how in accessible the top and bottom of the screen on my 13 mini are for one handed use. I swipe to text one handed, but pressing the numbers its emoji button requires serious contortion and dexterity. Maybe the fact that I tend to use my left hand (despite being a righty) contributes to this.
I don't have a problem reaching the bottom of the screen, and also generally use my left hand for one-handed use. The phone rests on my pinky, with the middle three fingers supporting the body.
How are you holding your phone? I'm typing this comment one-handed using a soft keyboard on the bottom of my phone. My thumb actually cannot reach the top of the screen without shifting the phone to a different grip.
GP is not saying that the top is easier to reach than the bottom. Reaching to the very bottom of the display one-handed is still straining, compared to the Home button iPhones.
> With phones, it's always been easier to reach the bottom.
The _original_ iPhone is tiny by today's standards. It's 15% shorter than a current iPhone SE, with a relatively huge chin. At that point the top corner is where the thumb is when it's straight up.
Read the second section, labeled "Thumbs vs Touchscreens", which shows the sweet spot for accessing content via left or right thumb or both. The lower corner closest to the base of the thumb is hard to reach. Unless the user was using both thumbs, placing target UI in one of those corners would hurt one-handed users.
Also note which areas are labeled as HARD to reach for either/both thumbs - the location where GTK4 has placed the main buttons in the File Chooser dialog.
I wish Gnome did not try so hard to be macOS. If I wanted to use macOS, I'd get me a Mac.
But I see that the other Unix machine most Gnome developers use is a Macbook, so they try to make things familiar, because they sort of like that UI. (Those who don't but still want a coherent desktop can pick KDE.)
It's not even macOS; it's iOS. It's a GUI for phablets and phones.
Fortunately, I think more projects are abandoning GTK than onboarding it thanks to GTK's horrible documentation, instability, opinionatedness, and simply how much better Qt is to develop for[0], which I can only hope will gradually de-throne GNOME as "the default DE".
Yep; as I’ve said before GNOME is what you’d get if you tried to clone iPadOS and turn it into desktop OS.
It still feels more polished and accessible overall than alternatives though, and so it will probably continue to be “the default DE” for the foreseeable future.
KDE has the most potential to replace it, but I think its configuration is still intimidating (to the point that you regularly see people ask which KDE distros have good defaults), as well as quirks you don’t see anywhere else, like turning file copy dialogs into notification toasts. It’s technically functional but comes off as weird.
The other GTK DEs (XFCE and Cinnamon) I think are in a better place in terms of their settings panes not being scary and generally feeling well designed, but lack resources.
> like turning file copy dialogs into notification toasts
That's a great thing that I'm surprised other DEs don't do. Works really well for file downloads too. It makes intuitive sense and the fact that finished state is retained in notification history is such a helpful thing that genuinely improves user experience for someone with such a poor working memory as mine that it's really weird to see someone calling it weird.
I don’t mind seeing completions in my notifications and having the option to show progress in notifications is fine, but I also want the option for a boring old dialog, preferably with the ability to expand and show a high level of detail (think Windows file copy dialogs) that isn’t practical in a notification bubble.
> preferably with the ability to expand and show a high level of detail (think Windows file copy dialogs) that isn’t practical in a notification bubble.
Why do you think it's not practical? That's what Plasma offers already and I'm using it often.
I really hope that’s not the case. GTK4 is highly polished and getting better.
Even if for the sake of argument we accept that Gnome/GTK’s UI choices are poor, the consistency across applications elevates the overall experience.
If, for example, you disagree with the placement of buttons, you know that all the GTK buttons will have the button in the same place which greatly reduces cognitive load.
The same is, unfortunately, not true of other Linux UI kits.
> you know that all the GTK buttons will have the button in the same place
This is vehemently untrue. You know that all GNOME applications will have the buttons in the same place (GNOME writes their own HID) but GTK doesn't have an HID. GTK is simply a GUI toolkit, I can put my topbar at the bottom of my window if I want. It's not 'correct' but I can still do it and ship my application.
As a developer of a couple GTK apps, I look at the deprecations in GTK4 and GTK5 with horror. At least one app I'm going to stop maintaining latest with GTK5.
GIMP still doesn't have stable release out with GTK3. Inkscape took a long time. I bet both will have great trouble in the future. It seems we're moving towards GTK apps being either core GNOME (maintained as paid work by Red Hat) or trivial little apps like on mobile (either simple to port or just short-lived). Everything else will slowly die out.
Sometimes I wish Mate would have also forked GTK2. GTK3 is just heavier in general and going forward, GTK4 seems to be even more Gnome focused, so a fork might become inevitable anyway.
From a developer standpoint, I actually really liked how composable GTK3 was. It's fair to complain about the stylesheets and the funky touch-centric interface, but it did still let you build GTK2-style apps. It was full of weird/nice features and felt like a decent iteration on GTK2. GTK4 has been a waking nightmare in comparison, and I'm not sure why they feel obligated to throw out so much of the previous toolkit.
Qt being a pain to bind (and thus having few high quality bindings) is definitely a big reason why I’ve avoided it. I don’t really want to be writing UI in C++.
You forgot to mention, that filename entry field is also in the middle of titlebar. While that might help to defend placing "Save" button next to it on the right, but now all primary save dialog functionality is contained in titlebar. Folder selection is clearly separated and made secondary action. It would be interesting to see usage statistics, how many users save files without selecting folder first.
Sadly there would be no stats for people screaming obscenities to authors of this... dialog, because they tried to move the dialog but instead got to the filename editbox.
I wonder how feasible would it be to support a fork that added that feature. It seems self-contained enough to not require any public API changes. Just building the GTK source with some flag would turn on that feature, and dynamically linking against that GTK lib.so would make the thumbnails view accessible to the user.
Did anybody care enough to try?
(I personally don't; I use the file manager for any views I want, and drag the files from it onto an app, or onto a file chooser dialog. That feature, which is also present in macOS, was very much worth reproducing.)
As a ux designer, putting the confirm button at the top right is madness. I can’t comprehend the thought process that led to it being put where the close action usually goes.
I’d love to watch an eye tracking study of it in use.
I loathe applications that put controls all over the title bar.
The title bar is supposed to be a mostly empty expanse that you can grab with a mouse. Now it's littered with controls, and I can hardly bring windows to focus or move them around without accidentally searching something or confirming something.
Agreed - especially if I'm remoted into a box and not necessarily running a full-resolution screen. Bad UI design is magnified when you're at 1024x768.
I find it somewhat ironic given current GNOME that when I was choosing between GNOME 2 or KDE 3 back in the day, GNOME 2 won as bits wouldn't float off my screen...
I used to agree, then I moved to Linux (KDE specifically) and found out I could set my DE up so Super+LMB anywhere on a window moves it, and Super+RMB resizes it, it's is way more convenient, I haven't found myself using the title bar any more.
Title bars also serve to more quickly recognize where windows are. If every application fills up the title bar with different stuff, it becomes harder to “parse” where windows are on the screen. There is an inherent benefit in windows having uniform “chrome”.
I have Alt-LMB for moving, but that all falls to pot when I remote into another machine -- alt-lmb moves my rdp/vnc/browser, not the one in the screen I'm connected to.
I'm not advocating for this to become the default functionality across the world for everyone, it's definitely very opt-in.
In that case you don't need discoverability for something you set up yourself.
It's also very fun to play with when using the Wobbly Windows effect, you can stretch them in different ways depending on where exactly you picked the window up from.
Ah yes. Instead it pollutes the title bar with multiple things with wildly different behaviours with no error margin
"less vertical space" so let's have a hamburger menu on a desktop screen. Right next to the window close button.
"less vertical space" so let's have a tiny search icon right next to the select button
"less vertical space" so let's have search consistently in the left corner, no in the middle, no to the right
"less vertical space", so let's have tabs, buttons, icons, and hamburger menu in one row. There's no space for the actual title or little space to drag the window? But THERE'S LESS VERTICAL SPACE ENJOY
The 16:9 screens. Once upon a time they were called widescreens because many people were used to small (in inches) CRTs or LCDs (even with square panels.) Basically they were 12:9 and those 4 extra units on the horizontal axis become real extra space. Unfortunately most people only got 768p screens on their laptops while all TV sets had 1080p and some of the old monitors were 1024p or 1200p. So "less vertical space". And then when you have a 13" laptop you don't have much vertical space no matter the resolution.
We're talking about things like dialog windows that don't take much vertical space even when putting all confirmation buttons in separate rows; this is a set of applications that often easily fit on half the screen. I know what you're talking about, I'm writing this on a laptop with 13" screen and I'm using a browser with vertical tab bar for a reason, but this isn't that case.
>Humans naturally read from top to bottom. It naturally follows that the final action in any UI should be at the bottom.
Pretty bold of you to assume such thought process occurred at any point during design. Someone just thought "this looks good", where good may mean "modern-looking", "trendy", or "looks great on a screenshot for a product page", and slapped the button there.
I wonder if this is designed by primarily laptop users. They may conceivably prefer buttons at the top because it’s closer to the center of their field of view.
Of course, laptops used with their builtin display and keyboard are a usability disaster already, so that shouldn’t be a criterion.
For what it worth, gnome is very good to use with a trackpad, swiping left-right to switch between desktops is very smooth, probably the best laptop experience out of any OS/DE.
I swear that my initial reading of the title was "74 Decades Later", and I smiled because it fitted the feeling of how late this addition is arriving. Then I realized it'd be a bit strange that they used this kind of snarky sarcasm on their own blog, and had to re-read again the title.
Also,
> This is the culmination of more than a decade of work, and was only made possible by GTK4’s complete rewrite ...
read to me as
> this (lack of an essential and basic UI feature) was only caused by the typical "let's rewrite everything" movement that started more than a decade ago
I know HNers are very sceptical of the technical merits (or their lack thereof) that ground-up rewrites usually have. I only hope in some years, GTK 5 or 6 doesn't decide to trash all this work and starts from scratch again.
Regardless, my congratulations to the people who pushed through and contributed their effort to make thumbnails back!
> this (lack of an essential and basic UI feature) was only caused by the typical "let's rewrite everything" movement that started more than a decade ago
The whole "we needed to rewrite everything" is complete nonsense anyway. There are THREE patches posted on the issue tracker over a period of more than 10 years. They work well, too; people have maintained out-of-tree patches for this (IIRC there's even an AUR package for it in Arch Linux).
GTK developers simply chose to ignore this. They explicitly solicited patches in that issue and then ignored those patches. Not "this patch needs work", just nothing. I get that reviewing patches is work too, but you can't solicit patches for an often-requested feature and then just ignore them. Well, you can, obviously, but it makes you an asshole. When a few years later someone pointed out the latest patch on GitLab it got shot down with a shitty snide "we're not going to look at random patches" comment and had the topic lock (it was on the old/now-deprecated BugZilla).
But hey, got to have some historical revisionism to justify your shitty toxic behaviour towards volunteers and users.
I had a patch rejected after being told "patches welcome", for lacking detailed user testing or not matching any official user stories or something (which is BS, the rationale was just as good as anything), only for the person who rejected it to later implement the same feature just because it "feels" better. Years later after they forgot of course, otherwise they would have kept the feature unimplemented out of stubborn spite.
I feel pretty salty about it. Don't say patches welcome if they're not, and don't apply selective burdens of evidence in favour of including a particular change.
Some of them have huge egos and are stubborn as anything. If something wasn't their idea originally it can be a real uphill battle regardless of how sensible it is. Convince them it was their idea and suddenly the gates are open.
I always feel like I must be crazy because Gnome / GTK threads are always filled with comments about how terrible it is. Personally, I find it to be the most aesthetically pleasing and usable desktop environment I’ve used (having spent many years on Mac and Windows). I’m not sure what the disconnect is.
Anyway, good thing we all have a wealth of choices. If you don’t like Gnome, there’s a huge universe of choices available to you! Long live OSS.
I'm fine with Gnome, but what bothers me is when really basic features are missing.
For example replacing a desktop wallpaper with a solid color required manual config changes. Even Windows 95 let me do this from the GUI. Removing the wallpaper is useful for VNC connections for example.
I wonder if the frequent dropping of features (the primary reason Ive seen people give for their gnome hatred) is part of why it currently looks so amazing.
Less features means less to maintain (which is important for an open source, free product).
Until AlphaCode can maintain a codebase as large as gnome, we should probably keeping the workload of open source devs as small as possible.
I like GNOME too. It's the most usable Linux GUI I've tried to far, with Cinnamon a close second.
I like the fat title bar with controls. It's like the Windows 7/macOS aesthetic without wasting space for a title bar above it.
To me, the people complaining that the save button should be on the bottom instead of the top have the same limited view as the people who complain that macOS has the window controls on the top left instead of the top right. It's an arbitrary difference that they claim goes against human intuition but I have seen no proof of any of that, only assumptions based on what direction they read in.
I don't use the save button, I hit enter after typing a name. I don't hit the open button, I double click. Maybe that makes me weird, but I think the "problem" is grossly overstated.
Seems to me like some people just want to go back to the GNOME2 days and that's fine. I may think it looks janky and outdated, but that's what some people like.
Luckily, they don't need to use modern GNOME, there are projects out there that replicate the older design style. I don't see what constantly harping on the newer UI adds if you're not going to be happy with it anyway. Unlike with Windows, where I sorely miss the glory days of Windows Aero, there are alternatives one click of a button away. Just install something else, anything else. KDE and LXDE allow you to recreate your weird old setup with some tweaking, go use that.
However, I do have some problems with the way the GNOME team operates sometimes. There have been attempts to address the file picker problem that went absolutely nowhere. The decision to completely abandon all styling options also disappointed me. The unreasonable demand of forcing client side decorations onto everyone because of their preference annoys me greatly. I like the stuff made for GNOME on GNOME but I wouldn't use it on any other desktop environment or operating system because the "let's do everything ourselves" approach makes applications look incredibly out of place.
Of course, the constant ranting about any change that doesn't turn GNOME back into GNOME2 only drives forward the segregation between devs and their users. After all, if nothing GNOME does is ever any good according to the loud minority, why even bother listening to them?
The most used Linux distros out there are Debian, Fedora and Ubuntu, all of which ship GNOME out of the box. There's a good reason for that.
I like gnome: it works, its easy to use, it looks pretty, it's free, and it doesn't feel like it's being run by a corporation that wants to control what I do. Sure there's some design things that aren't right, but I don't feel that it matters a lot, a certain other OS is popular while having a zillion design things that aren't right.
I guess because some of us, old timers that still believed in the year of Linux Desktop back in the GNOME 2.0 days, got fed up with all the incompatible rewrites, JS for extensions, removal of preferences into extensions, asking devs to write XML based UI layouts by hand,....
At least Microsoft, Apple and Google have the market share, and economic incentives to justify putting up with rewrites.
You could share your thoughts or (positive) feelings about one of those design decisions that cause discontent: putting confirmation buttons and other UI controls on the title bar, when the natural human way of processing visual information is top-to-bottom (so a confirmation button makes more sense at the bottom area of a dialog).
Do you feel that the crowded title bar design decisions are aesthetically pleasing and usable? (would really like to know the opinion on these topics from users that like how it's been done, instead of users who hate it, for a change)
Yeah. It’s fine. It doesn’t bother me. Gnome’s UI is consistent, has good fonts and margins, is minimalist, and gets out of my way. It has all of the settings I need in one consistent, easy to search place. I get the entire screen available to me with no huge useless dock or similar thing taking up real estate. It just works and works mostly how I want. :shrug:
It’s obviously not for everyone, but I like it. I also appreciate the focus and the way they cut out features that add complexity and inconsistency to the UI. So, I’m general, I’m a fan. It’s not perfect, but I like it a whole lot.
I agree. I’ve made a transition to Apple in my phone and tablet but as much as the M-series is tempting I’ve just built a new PC for GNOME/Fedora exclusively. It’s truly my favorite UI for a computer.
GNOME and GTK look spectacular these days. Even when I'm using macOS I now find myself thinking that GNOME looks better. The design is very uniform and coherent, and overall simply beautiful to my eye.
If only the usability was as good as the visual design...
De Gustibus Non Est Disputandum, I guess, seeing applications without menu bars (the greatest invention in IT, bar none (if you'll excuse the pun)) just makes me feel like I'm looking at someone putting square blocks on wheel axles or praying for lightning to hit a tree to get fire.
Like one of the screenshots has in the title bar a looking glass, three tabs, a check mark in a circle, a hamburger, and the close button. What am I even looking at?
The greatest invention was the global menu bar, as seen on Apple computers. That is the only iteration of the menu bar that respects Fitts's Law: by putting it at the top of the screen, the menu bar has infinite height, so it is infinitely easy to reach.
The global menu bar is bad UX for a windowing desktop because it visually disconnects actions from the window they belong to. It's not always obvious which window has the focus and using the menu bar can easily trigger an action in a different window or application than intended.
On Windows, I don’t stop to think “hmm, which edit menu is this”. And, if I have multiple windows from the same application open (multiple document interface), I know which document the edit menu is for.
There is a genuine tradeoff here. Global menu bars are easier targets and waste less space. Per-window menu bars are more clearly bound to their window. Neither approach is better on all counts.
To be fair, Microsoft got the memo, it took all the useful parts of the global menu bar and put them in the start bar, which is itself glued to the bottom of the screen and thus respects Fitts' Law. Windows did put the application-specific menus into the per-window title bar, but even then the most important part of the title bar is the section with the close/minimize/maximize buttons, and on Windows a maximized window puts those buttons at the edge of the screen, again as per Fitts' Law, whereas Mac disobeys Fitts' Law here and puts those buttons below the global menu bar.
> Windows did put the application-specific menus into the per-window title bar
Except that's not what Windows does. Just about every app has a different place where you can find the menu (if there is one). Looking at a couple Microsoft apps on Windows 11:
- File Explorer: menu in an ellipsis in the toolbar; toolbar is left aligned so the ellipsis menu is in the middle of the window for a reasonably wide window.
- Edge: menu in an ellipsis to the right of the address bar.
- Windows Terminal: menu in a tiny down-facing caret next to the new tab button.
That's referring to the long-ago time period when MS first decided to forego the global application menu bar in favor of the Windows taskbar. Indeed, the fact that many programs no longer feature traditional menu bars, but that they do still feature close/maximize/minimize buttons in their titlebars, only further reinforces how much more important those buttons are. Even when I used Mac, even when using apps that had useful entries in the global application menu bar, I cannot remember a single instance of voluntarily using the global application menu bar for anything (other than "please close this app", because the year is 2022 and Mac still refuses to acknowledge that closing the last window means I want the app to close).
Good observation, though Microsoft forgot it (again) when they designed Windows 11 and moved the Start button from the bottom-left corner to somewhere in the middle of the screen.
It's movable of course, but this is still a downgrade from win10. My biggest peeve is that there seems to be no option anymore to not-condense icons, and you can't change the notification color (when an app flashes its icon).
I miss notifications on my work computer all the time because the flash color just doesn't stand out very much with my dark theme, and I can't even expand the width because...well it feels like they released an unfinished and unpolished product, again.
I hate that there's trade-offs that shouldn't need to exist with every new version.
Meanwhile my mac I don't think has ever lost functionality or customizability in the last..8ish years I've been using it as my daily driver.
edit: caveat...this is a work computer and obviously has group policies/etc that might affect things. I will correct this post if I'm wrong :)
Yes, I'm not trying to defend their modern design (in)sensibilities. :P I switched from Windows to Linux (with an aborted attempt at Mac) after realizing the OS-level ads weren't going anywhere.
Not sure how that's relevant to my comment; Microsoft was indisputably "inspired" by Apple, in the same way that Apple was indisputably "inspired" by Xerox.
I disagree. I have a 38" ultrawide monitor (that I love). That is a long way for the mouse pointer to go every time I want to select something from the menu bar.
To make matters worse, I have progressive lenses and the "sweet spot" for the text to be in focus within my field of view is relatively narrow. So not only would I have to move my mouse quite a bit if I had a global menu, I have to move my head quite a bit as well.
I think Fitt's Law is something like Moore's Law: both couldn't be counted on to go on indefinitely.
Fortunately for me, I use KDE and could switch between the two if I wanted.
The global menu bar is a design flaw and evolutionary dead end. It doesn't respect Fitt's law when people have multiple monitors. It also implies alt-tab to switch application Vs alt-tab to switch window which is, again, broken when you have multiple monitors (alt-tab to switch window is the correct choice).
Not only that but Fitt's law is dying as mice become less and less used as a means to interact with a device. Touchpads and touchscreens have usurped them.
Fitts's Law is still alive and kicking in the touchpad era. Until we have anything that drives a cursor, it is relevant. A global menu bar is infinitely tall on a touchpad as well because I can randomly flick my finger up and I will have reached it.
And I do not get what a global menu bar has to do with window switching and monitor switching. Tiling WM fans all know that focus-follows-mouse is saner than alt-tabbing like a maniac, and this doesn't invalidate the role of a global menu-bar.
I know it’s not everybody’s cup of tea but I wish that global menubar options on Linux were more robust.
There are extensions to add one to GNOME and XFCE, and KDE has it as a built in option, which is great. Problem is, this feature relies on programs advertising their menus via dbus, and a lot of them don’t bother at all, meaning that it’s sitting up there blank half the time. The only reason that this is even possible is because the desktop paradigm moved menus into the space of the app UI, which I think is a mistake. Menus are such an important accessibility feature that even if they’re glued to windows, it should be a standardized system owned widget so overzealous IKEA-minded designers can’t screw with them.
This is very frustrating to me because with hamburger menus and window attached menus I feel like I’m chasing a frequently used widget around the screen.
I’ve never really understood this. None of the things you actually want to click obey Fitt’s law. It’s really an argument for having the toolbar at the top of the screen instead. Or having a taskbar at the bottom, which Windows had long before the Dock came along.
(I’m not really the target market for any of these things, to be clear, gimme the screen space back and don’t make me touch the mouse).
The Control Strip in System 7 predates the Start button and taskbar found in Windows 95. If we go back further, NeXTSTEP introduced the dock and let’s not forget that AmigaOS and RISC OS both had very similar functionality too, along with others that I’m forgetting that all predate Windows 95.
The Control Strip was pretty anaemic though. It was more like the tray (i.e. a dumping ground for stuff people don't regularly interact with). But still, when you do want to play a CD, there you have it in one click, rather than one click blessed by Fitt's Law to drop a menu down, followed by moving back down carefully to find the thing you actually want. In the meantime I just typed the command with autocompletion in Emacs and moved on with my life.
That was designed for a non-multitasking OS with a tiny screen. You have to wonder why they never stopped drinking their own kool-aid when technology changed.
> menu bars (the greatest invention in IT, bar none
Menu bars are terrible! Visually navigating a tree structure via mousing is a nightmare, especially if the whole thing disappears or radically shifts if you mouse a few pixels off. Visually scanning huge, variable chunks of the screen is inefficient, awkward, and a burden.
Everything that you can do with those nasty, collapsible visual hierarchies can be done way more efficiently and way more accessibly via a nice search interface with fuzzy filtering and autocompletion.
When it's actually fast and unencumbered by bullshit like advertisements, something like Spotlight or the modern Windows start search is infinitely better than crap like the Windows 9x start menu.
If you've ever coached someone through navigating a graphical, hierarchical menu they've never seen before, you know how painfully slow all that mental processing actually is. Even a hunt and peck typist will be faster in most cases, as all they have to type is at most a handful of letters. Menu bars suck in the exact same way, and they ought to be either eliminated or replaced in the same way as ye olde start menu, too.
I very much disagree, the discoverability with a search interface is terrible. With a menu bar even the most computer-illiterate troglodyte (e.g. me) can just go oh, it says "Help" there, I'll click it without having to worry about my one neuron overheating.
EDIT: I think the best option is taking the golden middle road and having a menu bar which can be searched through, kind of like Unity has.
> I think the best option is taking the golden middle road and having a menu bar which can be searched through, kind of like Unity has.
Yes! I've been a KDE person since like KDE 3.4, but I gave Unity a chance in its heyday and I absolutely loved it for that feature.
Discoverability with a search interface can be improved by adding a visual representation of search categories or common search terms, and an old-school hierarchical menu can do just fine for that. (I think a different kind of menu might be better for discovery, though. You could do a more search/filtering-oriented descent of the same hierarchy, and enrich the menu entries being filtered with documentation and previews.)
Discoverability of search interfaces can also be improved with by tagging things with synonyms and descriptions, so that users can search by task instead of the app's canonical names for functions.
I agree. But unfortunately it’s still pretty horrible to use. There’s just a really bad quality feel to it. Like you bought something from China trying to cheap out when you should have bought the branded thing and you’re still at the telling yourself it was a good deal phase of denial.
Edit: this is something that can be fixed but it requires well funded attention and there just isn’t that because the commercial opportunity is entirely on the server.
Not the OP, but the mishmash of icon styles in the default installation and the oversized titlebars I find amateurish to say the least. It really puts me off. Bizarrely, as a Mac user, I prefer the look and feel of KDE.
I think the thing is it's just the full picture is not good enough.
I mean I'm sitting there earlier having a shit and I shout at my watch to add some more toilet paper to the shopping list. This is now on all my devices including the one I take shopping. If this was on Linux I'd have to crawl back to my desktop, write it on that, then export it when I went shopping. Everything is just that much more difficult and disjointed.
The whole experience leaves me somewhere around 2008. I can't find any real advantages over my gnome2 desktop in 2008. It stopped being usable then for me.
Linux has become what its good at, which is a container target and server platform. As a desktop it hasn't even caught up with the 2010's yet...
The thing is that sort of stuff is what builds market share and keeps it. Once you have the tools that allow you to do that level of integration then they become leverage to stay on a platform. Without it, retaining users is difficult.
Linux on the desktop failed to retain me because of feature stagnation (and reliability issues which are quite frankly not there on other platforms)
Well, I kind of understand your point though it's from a reverse angle. My previous two jobs gave me maxed out macbooks as work machines, but I really hated them.
They were kind of half-close to the Linux servers I work with, but I needed to use homebrew to make them useable. Why can't Apple get a decent cli environment going?
The GUI stuff just pissed me off. I want to arrange some windows the way I want. I don't actually like tiling window managers, but after using macos I thought it was possibly the only way to make it properly useful.
Keyboards: well, everyone knows about how they fucked that up. The new ones are much better. I like the Mx hardware and when Asahi is fully up to speed, my next personal laptop might well be one of those.
Yeah there was a "crap zone" of Apple stuff around the butterfly keyboard disaster. The new M1 kit is completely 100% different grade of hardware.
I have no issues with macOS UI as such. It takes about 6-9 months to get used to it though coming from anything else. When you get there it actually makes sense. I've seen a lot of Windows converts expect everything to be windows-like but it's more NextSTEP than windows.
Every time I do the swipe gesture to open up the activities overview on my laptop I am delighted at how smooth and polished it is now. It's such a small thing but you do it so often throughout the day that it matters. The way the desktop moves backwards spatially, how the icons slowly fade in, how the windows correctly stay at the elevation they were at based on how recently they were clicked, how the animation curve isn't flat but feels bouncy. Just nice! Same thing applies to switching between desktops. It feels a lot better than on Windows.
> In the last post, we discussed deprecating treeviews and cell renderers, among other things. All these deprecations cause a lot of work for applications and libraries using these APIs, so why are we doing this?
> One of the reasons is to enable new features. Such as a grid view for the file chooser. It only took us 18 years! You can see the original feature request in Bugzilla. This is easily possible now because GtkListView and GtkGridView can use the same data models.
This is exactly why I do not use GNOME. Absolute insanity.
They made GtkWidget lightweight and fast. So CellRenderers have no reason to exist any more. Then they added new view widgets that use regular widgets instead of cells.
An application can consistently be made using the same primitives that are flexible, themable, performant, etc.
Computers are way faster than they were 18 years ago, so what I want to know is if, in 2003-2004, the code which provided the same functionality was less performant than it is now, or if somewhere along the GNOME development path it became bloated. Because otherwise my mind is blown about how fast my already snappy GNOME 2 Linux desktop could have been.
Today you are rendering to a 4k display (8 million pixels) and every consumer device has a general purpose GPU that is really high performance at specific rendering tasks.
So in many cases, certainly not all, GTK 2 code using Cairo to render will perform worse than GTK 4 using OpenGL even when implementing the same features. Admittedly GTK 4 does use this overhead to do "fancier" things like animations and CSS but these aren't super complex tasks on a GPU.
In my personal experience GTK 4 feels very fast and snappy, clearly more so than GTK 3 was. However I don't use GTK 2 applications to compare.
So that they could have a grid view for the file chooser, which they expect to eventually deprecate so that they can support a list view in the complete rewrite underway for GTK5.
Unfortunately they also lost tons of functionality in the process. The fact that typing on a file picker starts a recursive search instead of simply jumping to the file/folder with the prefix you typed, is nothing short of hilarious.
...and the filename is shown as a focused highlight, leading you to think that's where the focus actually is! But no, it's in the search field, at the bottom right of the dialog.
I could not believe that misfeature was actual, intended behavior from upstream gtk and not some stupid MBA-minded decision made by district maintainers when I ran into that on elementaryOS 6.
Imo the problem with Linux GUIs is that there are 2 kinds of devs working on it:
- Those who want to bring about The Year Of The Linux Desktop and believe this can be brought about by removing every remotely complicated feature under the sun.
- Those who think the only purpose of GUIs is to display multiple terminals side by side.
The enlightened, then, know that the only purpose of ANY desktop environment is to start the correct program when I hit "super" and then type the first 3-4 characters of a program name. And to do that left/right screen split thing when you hit super+left/right.
I can't figure out how my workflow is that different from other linux users or if I'm just part of the silent majority. Literally all I ask of my DE is:
- the super+search thing i mentioned above
- run the following programs fullscreen: terminator, intellij, pycharm, vscodium, firefox
And... that's just it. Oh wait, one more thing:
- make video, wifi, audio, multiple monitors etc just work
It's in service of that last one that I've been pretty happy with Gnome 3 the whole time it's been out. None of their shuffles or excisions have interrupted my workflow, so I don't mind it at all.
I agree with the point you're making, however for some reason on Linux, desktop environments usually are far more extensive than that.
KDE, GNOME, etc. usually don't only consist of an app launcher, but a file browser, text editor, archive manager, browser, image viewer and who knows what else.
I never understood this tribalism, doesn't the spirit of open source mean that I'm free to choose the tools of my liking, may the best tool win, etc.?
This certainly the case on Windows, where people usually just replace tools to their liking.
Most distros usually strongly push the desktop environment's native apps for every niche.
When I have multiple screens I run 95% of my applications in fullscreen mode. There is not much heavy lifting that a DE needs to do. Occasionally I use split windows.
Honestly, I think the latest version of gnome-screenshot that has been directly integrated into the DE is amazing.
Nice. Maybe in a handful of years there'll be applications besides GNOME itself that use Gtk4 and maybe the documentation will even exist. But right now the vast majority of applications use Gtk3 and Gtk3 has been frozen broken for a decade. Right now you literally cannot paste a file path into a file->open dialog without invoking some arcane key sequence to bring up the "path bar" first. If you just paste into a newly opened file->open dialog it litterally errors out. That basic functionality does not exist, let alone a luxury like thumbnails.
I've talked to the Gtk devs about this and they say that 3 is will not be fixed, ever. They won't even accept patches because gtk/gtk/gtkfilechooserwidget.c is so cursed.
It looks good. Sharp fonts, good use of space, clearly recognizable widgets, application doesn't treat users like idiots.
What do we have now? Fuzzy-ass fonts (except on phones where DPI>400), huge margins, barely recognizable widgets, GNOME applications written for people in comas.
That screenshot is a significant step down from Windows 95 already. It's simply too complex.
Way too many random vertical and horizontal lines going everywhere. A mix of text way too close to other controls right next to whitespace controls. Outlines intersecting with the text they're highlighting when there's plenty of space around them. Drag&drop bars that attract way too much attention with how textured they are.
I personally like the modern, simpler designs better. The aesthetic of late 90s UI were great but their designs were often a hodgepodge of whatever control the developers could fit onto the screen, with resize bars placed to let the user overcome the crammed design on demand.
I don't know what your working system looks like, but my fonts aren't fuzzy. The margins are visually pleasing and the widgets are quite intuitive because they're used consistently.
Feel free to go back to the old ways with Chicago 95 and LXDE. It's not exactly Windows 95, but it's pretty damn close. But please don't bring back the jank of overcrammed late 90s UI design, you'll only scare people away.
For me personally, NeXTSTEP/OPENSTEP was probably peak UI design.
Mac OS X Server/Rhapsody v, where they basically mixed NeXTSTEP and Mac OS 9, and early Mac OS X releases (before brushes metal) were also nice. All downhill from there… now get off my lawn! ;)
Here here! I miss my NeXT (I used way beyond a reasonable length of time lol). Fantastic UI.
So many modern UIs are so damn space inefficient. Drives me mad. It’s like designers think everyone is an 80yo with Parkinson’s and bad eyes. Massive screen waste; white space everywhere; blah blah.
But but my whitespace! I really love low density interfaces. The new DB app manages to fully halve the number of connections on a screen compared to the old one. That’s progress!
I wonder.. has anybody tried training Stable Diffusion on GUIs? I'd love to play with it and perhaps see how GTK1 would look like with better font rendering, border-radius, a modern color palette, etc.
At the time of the 2->3 GNOME transition, I agreed it needed some overhaul and started looking dated (the default&vanilla GNOME install, that is). But there were many decisions they took I could not understand:
- The applications-places-system menu. As said in other post the other day, it was so clever to have all the stuff in your computer categorized in those three categories. You knew at first sight, even if you've never ever used GNOME2 before, where to send your mouse when reaching something, it wasn't a guess game like in Mac or that cram-everything-in-one-button like the Windows start menu - not to talk about the 'moving around your mouse through the whole screen to launch an app' like GNOME3/4 itself.
- Clearlooks was the pinnacle of theming in Linux. Easily readable/scanneable and beautiful by default, 'themeable' up to the tiniest detail with a readable CSS-like syntax (I'm fuzzy on the details but seem to recall it wasn't a feature exclusive of Clearlooks). I concede Adwaita inherited visual inspiration from Clearlooks, but now with GNOME4 they decided to ditch it altogether. For some reason.
- Technological aspects aside which I won't talk about because you people know much more than me on that, but restricting the user to customize their GNOME install was an double-edge sword they seem didn't thought much through. GNOME2 had an almost perfect balance between simplicity and customization capabilities; whereas with GNOME3 upwards it is up to devs decide many things (and it seems those decisions are based much on their criteria rather than their users...). That brought the unfortunate consequence of frustrating users with every unexpected change with releases, something didn't happened with GNOME2 (or maybe even before than that).
Needing an untrusted user plugin to do basic things like display application tabs on the GNOME bar makes the entire project a nonstarter.
I really appreciate team GNOME's commitment to wayland, but outside of that, they have released a completely unfinished product which pales in comparison to the feature set of its previous incarnation.
> This is the culmination of more than a decade of work, and was only made possible by GTK4’s complete rewrite of its rendering system, and the introduction of highly performant and scalable list & grid widgets.
I hate to be the person who just complains about Gnome, but… a few years ago, you could type into the file chooser, and it would search, quickly, for matching files and folders and display them. Then it broke and didn’t get fixed for years. Once it got fixed, you see matches, but if you actually try to select a matching folder, you hit really hilariously bad bugs that wouldn’t pass the briefest test.
Maybe Gnome could focus on getting old functionality working?
End of an era.
The lack of thumbnails in the file picker was what started my KDE journey years ago. Doubt I'll ever go back to a GTK desktop but glad to see this finally implemented.
Yeah, I'd rather they fixed scrolling in large lists, which makes Nautilus almost unusable in directories with more than 500 items. So much for "scalable".
And, ironically, touch support is currently broken, too.
Hmm. I just opened a thumbnail view of a directory of 770 PDFs (with thumbnails disabled for now due to a HiDPI bug[1]) in Nautilus (GNOME Files) 43.0, and while the scrolling is a tad janky it basically works. I do dislike how long it takes to load that folder at first, yes, but I don’t think I understand your complaint here.
agreed! not to take away from the win here for the filepicker -- thank you :)
but since fedora 37 scrolling is totally busted... think it only occurs on x (which i use over wayland for a dozen reasons). its pretty brutal tbh, scrolling is kind of... fundamental.
Now fix your synchronous dbus calls to gvfs on the UI thread in the file dialog init code that hangs everything for 20s whenever gvfs shits the bed (not rare when you have more than a handful of mounts).
Then you should probably talk with your employer, or your employer with Red Hat, instead of demanding things in comments on a post of some volunteer giving their time to implement something.
As for many others here in the comment section gnome went downhill for me after the migration to version 3. gnome v2 was such an easy to use, clean and fast experience and after that it degraded not only from the usability perspective but also resource allocation. Suddenly my PC was stuttering when using Linux cause I only had my cpu to render the ui
What would be best (and of course, exactly the sort of thing that Gnome would likely oppose) is to be able to choose your own file chooser -- it should be modular like that.
The most annoying thing these days is how they're all different. I just want one (and honestly, I'd love it to be my hacky fzf solution, but again, modular)
I always wonder when people choose to use the word peformant if that’s what they really wanted to say. I mean it’s good that the grid works well enough to be considered functional, but is that really what they were shooting for? I suspect they meant to say fast or maybe fast and small.
> Performant means that something is working correctly or well enough to be considered functional. In a technology context, this term is believed to have originated with programmers seeking a concise word to express that a system or program will work, but may not yet be optimal.
That's interesting. While that seems to be consistent with other definitions online, in my experience most software developers use the word as a synonym for "fast" or "efficient".
This is not the technical problem, that's for sure. Maybe GNOME finally got a real UX expert from IBM :)
I had few talks about it with GNOME devs, they said mostly "this is not a problem!" , "go fix it yourself!" and "we're volunteers, pay us". Most of it was in aggressive manner, just like in Trump supporters community.
Theres always a ton of negativity associated with gnome. I'm just a basic linux user who doesnt have any problems, doesnt think about this kind of stuff. I think that's basically a glowing review.
That's the nice thing about the RiscOs way of saving and loading files, you never get in trouble because your file requester doesn't emulate all the features of your default file manager.
explorer.exe isn't responsible for file picker dialogs in Windows 98 (file picker != file manager). And the Win98 file dialogs didn't have thumbnail support.
The point stands. Explorer.exe 11 is nearly two decades ahead of GTK / Gnome.
And MacOS is even worse. I just bought my daughter a MacBook and sat down with a Mac for the first time since 86. My expectations were high. I thought I was going to see a Unix GUI done right. Instead it’s nearly as clunky as CDE.
MS may deserve grief about some things, but dang, Windows is about as polished as a product can get.
> The point stands. Explorer.exe 11 is nearly two decades ahead of GTK / Gnome.
No, it doesn't.
Explorer is the file manager application on Windows. The file manager application on Gnome is called Nautilus, and Nautilus has had thumbnail support for a very long time.
This is about the file picker dialog, which both on Windows and on Gnome/GTK+ is not coming from the file manager. You can say that dialog should have had for thumbnail support for longer, sure. It's also correct that Windows added thumbnail support to its file picker dialogs earlier. But Win98 did not have this, either, and Windows at least for some time did not have parity between the file manager and the file picker dialog.
It's surprisingly common for DEs across different operating systems to have several independent implementations of file lists/icon views between the file manager, the desktop background and the file picker dialogs. I think across Win, Mac, Gnome, KDE this actually describes most of these systems for most of their history.
You sometimes do find code reuse or even sharing a process between the file manager and the desktop background. Windows has done this, and Gnome also had a phase like this.
KDE recently unified the view code for the file manager (Dolphin) and the file dialogs, but the desktop background has distinct UI code (with the same directory model backend, and shared code for thumbnailing, context menus and other bits). In that case the reason is different UI frameworks (Qt widgets vs. QML).
I love how android solves such problems. Instead of making the decision of whether a file manager must somehow be able to handle file picking, every application is allowed to choose whether it can do file picking. For a file manager it would probably be trivial, but the wonderful thing about this design is that it is very flexible
Windows 11 is the furthest thing from what I'd describe as a "polished experience". It too has suffered from braindead reversal of UX norms in the last decade.
In the ODBC dialog you can find a Windows 3.1 style file picker still out there.
They've stopped supporting the Windows 1.0 feature of clicking the window icon for the window menu though (and broke the "double click the top left icon to close" workflow in their weird new app designs, sadly).
I find these buttons at the top extremely confusing, as I often - from my experience with reading - after I've dealt with the subject at hand (in this case, picking a file), assume the natural place to confirm my choice would be after it (i.e. below it).
What are the UX arguments for placing the confirm buttons at the top of a dialog?