They're probably referring to the functional regressions it made with it's first official release, and how it furthers the idea of GNOME/GTK lock-in. libadwaita has made it extremely difficult to package cross-platform desktop apps, especially while appearing native on different desktops (eg. adopting the native Breeze look on KDE while retaining the native Adwaita look on GNOME). The lack of this functionality at launch (and subsequent empty promises of a replacement) have rightfully left a bad taste in some people's mouth, particularly now that much of the GNOME leadership denies that this is a problem in the first place.
I don't think adwaita is that bad, but rather feel like they _yet_ have to polish some small details.
Like the interline spacing on things, sometimes it feels inconsistent. KDE menus, for example, have a nice spacing - but GTK ones feel cramped. And those submenus that they place on things like the top-right menu on the panel have different line heights.
Some other third party apps, for example that mail client I tried the other day (it wasn't evolution, but I can't remember its name) had serious layout issues. libadwaita was supposed to fix those inconsistencies and make devs lifes happier, but...
And speaking of buttons and top right corners, I will never, ever get why they place the open/save/select dialog buttons in the top right corner of the dialog. Where you are used to find the 'close' button. Why?
All of this is pretty much how I feel on the matter, too. GTK3's interface was a really lovely blend of skeuomorphism and more abstract widgets that came together to make a really unique experience. Even if it didn't work in every context, I appreciated how well it worked for less complicated applications and making great-looking, device-agnostic GUIs. Cawbird was a wonderful native Twitter app made possible with GTK3. Curlew packed all of the important features of Handbrake/FFMPEG into a more streamlined, simple package. Foliate took e-book reading into the 21st century. So many amazing apps were enabled with this switch, and even though it's still a second-class toolkit, it was my guilty pleasure on Linux.
In comes GTK4. Much like the article alludes to, the elegant and simple shadow of interactive elements goes poof. Developers spend hundreds of hours crusading against letting people use third-party themes, just so they can simplify and reduce UI elements to a nigh-unusable pulp. Developing with GTK4 is a nightmare. Using GTK4 is a pain in the ass. For christs sake, there was a devastating font-rendering glitch that existed for more than ten months after the first GTK4 release that was ignored in lieu of simplifying buttons, developing a new forced stylesheet and telling people "don't theme our apps!" Whenever I take this up with a maintainer, they immediately take it personally and write out a litany of reasons why I'm wrong and why I'm not allowed to disagree. The priorities here are almost unbelievably misaligned, I've pinned my GTK packages at the last GTK3 release and await some sort of admission of failure.
I simply can't take it anymore. These are the people making desktop Linux miserable, and I frankly feel no remorse watching their attempts at "simplifying" the ecosystem crash and burn.
This is exactly how I feel about it. The sad thing is that if the whole gnome ecosystem burns down I'd have to use the alternatives that I like even less.
I'm just not designing gtk4 apps untill it's actually better than gtk3
I'm sorry but most of this comment is a lot of nonsense. You're certainly allowed to disagree, but when you approach people with comments about their own work that are factually wrong, you'll get corrected. You're confusing those two things and taking it personally and that's a terrible mistake. Don't do that, it hurts you and it hurts everyone else around you.
Just to clear up any confusion:
- People have been working on the font glitch for the last ten months. It's not easy and the solution is not straightforward. Multiple solutions have been proposed but none are without issues. The problem is not being ignored. I want it to be fixed too.
- The choice of whether to allow themes or not belongs to the app developer. This hasn't changed at all from GTK3. When making an app, you can choose to allow themes or not. Some app developers won't, but you don't have to make that choice.
- The stylesheet isn't forced at all, when you develop an app you can configure your styles to always override the platform theme. This also hasn't changed at all from GTK3 and doesn't change with libadwaita. Take a look at the style context priority system for more info.
- Pinning your packages to GTK3 in protest doesn't help you. It doesn't make a difference to the GTK developers at all. If you want to make use of some GTK4 features eventually, it would be best to start working with it and getting your issues sorted out now. You can ignore what the other app maintainers are saying, that has no effect on you.
Oh good, I always look forward to condescending GNOME apologists to reply to my comments. Let's disseminate this comment and use it to help understand why me, OP, and hundreds of other people in this thread are frustrated with the state of GTK and GNOME right now:
> People have been working on the font glitch for the last ten months. It's not easy and the solution is not straightforward.
Then why was it working fine in GTK3? Sounds to me like someone made a breaking change, and didn't anticipate the consequences. The solution is to roll things back or wait until this new implimentation is fixed to push the code to actual users. Unfortunately, the GNOME developers are more interested in scorching earth than they are in maintaining a well-made desktop.
Oh, and it's not because it's a "hard issue" to fix, it's because nobody made a PR for several months. Apparently none of the core maintainers considered it much of a problem.
> The choice of whether to allow themes or not belongs to the app developer. This hasn't changed at all from GTK3.
No, it doesn't. There is not a single application written with GTK3 that can stop me from changing it's theme. I'm sorry if you disagree, but that's just an outright lie (I say this as someone who actually writes GTK3 code).
> The stylesheet isn't forced at all, when you develop an app you can configure your styles to always override the platform theme.
...and I can override it again. Any questions?
> Pinning your packages to GTK3 in protest doesn't help you.
Correction, it doesn't help you. It keeps my applications looking just fine.
> It doesn't make a difference to the GTK developers at all.
That seems to be a recurring trend when negotiating with GNOME/GTK developers. I don't care, I'm perfectly satisfied taking matters into my own hands since they'll ignore me anyways.
> If you want to make use of some GTK4 features eventually, it would be best to start working with it and getting your issues sorted out now.
I don't. What features are there, right now? Worse text rendering? Less accessibility features? More extreme, abrasive maintainers and fewer people writing code? A worse native experience, more middleware and less software freedom? Less native packaging? More Flatpak bloat? Worse touchscreen compatibility and an increasingly fractured codebase? More broken custom widgets that don't adhere to the GNOME HIG? An uglier, flatter overall design philosophy? Militant users and developers who hunt people down when they express their feelings about software they used to use on Hacker News?
Worse looking buttons?
You can keep it.
> You can ignore what the other app maintainers are saying, that has no effect on you.
I don't even know what you're trying to say here, but it sounds like doublespeak. This entire comment does, actually, and I'm not sure what your goal was by posting this. Nothing you've said accurately describes the reality of using GTK applications, it's more like an idyllic reflection of what people think the ecosystem should look like, ignoring everyone who doesn't throw away their current workflow to live in GNOME-land. Unless you start acknowledging the pragmatic reality of GTK's end-users, GNOME will continue to hemorrhage maintainers and stir up unnecessary and counterproductive drama for the sake of a few people's ego. And to think that what I said was nonsense, get a grip...
>I always look forward to condescending GNOME apologists to reply to my comments.
Stop. This is nonsense and adds nothing to the discussion, it's like if I started off immediately dismissing you as a "GTK3 apologist" or something like that. If you have a history of getting hostile replies, your confrontational attitude is directly the reason why, and it's something only you have the power to change.
>Then why was it working fine in GTK3? Sounds to me like someone made a breaking change, and didn't anticipate the consequences.
Yes, that's what happened. The whole renderer was changed to a hardware accelerated one.
>The solution is to roll things back
That's not possible because the renderer touches the entire project. It's probably the main feature of GTK4.
>Unfortunately, the GNOME developers are more interested in scorching earth than they are in maintaining a well-made desktop.
Please avoid these comments. This is a pretty meaningless generalization and adds nothing to the discussion. Just like any large project, there are some GNOME developers that focus on new features and some that focus on maintenance.
>Oh, and it's not because it's a "hard issue" to fix
No, this is extremely wrong. The issue actually is that hard. If you are a font rendering expert and you believe the issue is easy to fix, then please submit your own PR. I'll be the first in line to try it if you do.
>There is not a single application written with GTK3 that can stop me from changing it's theme. I'm sorry if you disagree, but that's just an outright lie (I say this as someone who actually writes GTK3 code).
No, this is also extremely wrong. Any external configuration method you use, a GTK3 application can override it or disable it. I'm not disagreeing and this isn't a lie, this is an actual fact of the toolkit. Feel free to list any of them and I'll explain how it can be trivially disabled.
>...and I can override it again.
I'm sorry, now it sounds like you're agreeing with me.
>Correction, it doesn't help you.
No, this has nothing to do with me. You sound like you were interested exploring GTK4 at some point, if you're still interested, then you'll eventually have to take steps to address the issues. If you don't want those then I don't see what your issue is, your original comment seems to be making assertions about nothing in that case.
>That seems to be a recurring trend when negotiating with GNOME/GTK developers.
This sentence right here illustrates the main mistake you've made. GTK is an open source project, by choosing to use it you're not entering in any "negotiation" with anybody. It's a take it or leave it proposition, and that's the way it's always been.
>I'm perfectly satisfied taking matters into my own hands since they'll ignore me anyways.
In the long run, that approach isn't sustainable. I find that most open source projects including GTK or Qt or any of those other toolkits won't ignore you if you have something useful to add or can take real steps towards correcting the issues that you're having. But being combative and approaching everything as a "negotiation" is the exact wrong thing to do and is probably the root cause if you find yourself getting ignored. Don't do that. You are making everything worse for yourself.
>What features are there, right now?
As previously mentioned, there is the hardware renderer with improved performance. There is also the multimedia framework and the new, faster list models. Those are the big features that I know of. It's absolutely fine if you don't want any of those, by all means stay on GTK3. But if you do want those eventually, then you'll need a plan to migrate.
>ignoring everyone who doesn't throw away their current workflow to live in GNOME-land
The font rendering on that example of "the perfect button" is rather atrocious. It's kind of sad that Windows is (was?) the last bastion of serviceable font rendering.
Linux font rendering has come a long way in the last couple years. With TrueType2 and Windows fonts taken from an installer ISO (and not the ancient corefonts package), you can actually get some overall mostly okay font rendering. Every now and again, the hinting bugs out and it looks unreadable, but its far better than the olden days.
What exactly has happened in the last couple of years? And how would installing those newer Microsoft fonts affect font rendering elsewhere than where they are used (not at all by the desktop environment by default, and as to web sites, it depends on what you use)?
IIRC the last big-ish change for me was around 15 years ago when some patent-encumbered patches were enabled by default by (some) Linux distributions. Which is okay for me because overall I think freetype font rendering is better than that in Windows with most fonts, the arguable exception being certain Microsoft fonts – however, freetype has the additional advantage that it rarely if ever produces pixelated ugliness with unhinted webfonts, unlike what I've seen happening with Windows.
> What exactly has happened in the last couple of years?
Some subpixel rendering techniques became unencumbered quite recently. So newer versions of freetype should have nicer subpixel rendering enabled by default.
Maybe there's some configuration magic you can do, but I don't think I've ever seen decent font rendering on a Linux distro out of the box.
It's one of the biggest reasons I've never switched to desktop Linux, and I'm not even one of those super picky people who talk about the intricacies of typefaces all day.
Interesting, I always disliked Windows font rendering and much prefer the was MacOS renders fonts. I couldn’t explain why, but I know many graphic designers who say the same. I guess it’s a matter of taste!
> 4K (or better) monitors have long since become the choice for most of those who cares about how font rendering looks.
This is the hardware solution to something that can be solved in software. If your game is laggy, of course upgrading to a 3090 is going to help, but that doesn't mean you're solving the problem.
It can't be solved in software, due to the Nyquist limit: Sharp high-contrast edges (text) necessarily have high frequencies, and you need a high sampling rate (pixel density) to produce a good approximation of that signal. People have spent a lot of effort to push anti-aliasing techniques as far as they can go, but displays with higher pixel density are just better for displaying text.
I agree that if you are making something and your target audience will be using non-HiDPI displays, then you should actually design your thing on those displays too. But no matter how good your software is, pixel density places a limit on what you can achieve.
Pixel-perfect rendering (i.e. hinting) is needed in order to reach the Nyquist limit. By forgoing it, you're limiting yourself to an effective resolution that's only 0.7× or so the physical one,
Bitmap fonts (and hinted fonts are automatically generated bitmap fonts) are pixel art, so the Nyquist limit doesn't apply. In pixel art, the pixels are treated as little squares or rectangles, not band-limited point samples. This means you sacrifice the ability to display arbitrary shapes, but I'm not trying to reproduce printed text so I don't care.
I have perfectly sharp text on a 1080p monitor because I disable antialiasing in ~/.config/fontconfig/fonts.conf and force full hinting.
Nitpicking, but a pixel is always a point sample, not a little square. The native medium for displaying pixel art is CRT displays, where these point samples are used to control an electron gun that introduces a Gaussian blur, basically the best case for purely analog upsampling (or DAC, rather) of a pixel raster. No little squares in sight, though! What you're talking about is using pixel-perfect control to reach the Nyquist limit, as mentioned in my sibling comment.
Pixel art is defined by treating pixels as little squares. There is no single native medium for displaying pixel art. The same techniques were used for games on portable systems with LCD displays. Additionally, there are many examples of printed art using blocky pixels.
The Nyquist limit is irrelevant to pixel art, because the Nyquist limit applies only to reconstructing signals from point samples. Using pixel art on a monochrome LCD (no subpixels), I can display signals with maximum frequency limited only by the sharpness of the edges of the little squares.
Just like programmers should have to run their apps on 10 year old computers and feel the pain, so should designers have to try their work on 10 year old monitors.
That isn't going to be the case for Apple users though is it. Apple don't have any non retina devices in their lineup now. The only Apple users who will see a low dpi display are those plugging in a low dpi external monitor. They are going to be a minority.
Perhaps a better survey would be the one by Firefox[0] since it isn't biased towards gamers. Basically HiDPI monitors are like a combined 2% of all Firefox users.
1080p usage is lower than on Steam but that is because 768p usage is higher :-P.
I guess that is the reason why every musician should copy their master to a cassette tape and go to a shitty car with a tape-player and listen there, why every developer should have a very old crap-computer to run their software on and why every UX designer should have a crappy screen to view their design on. :-)
The flat UI trend baffles me. The removal of text from icons and buttons baffles me.
For example, in Windows 11 I spent close to a minute looking for "Rename" in the right-click menu in Windows Explorer. Turns out it's not there! It's been removed out of the flow of the list and put in the top of the right-click menu, behind a small, picture-only icon that I've never seen before.
MacOS is guilty of this too: Buttons along the top of native apps like Finder don't have text anymore, the buttons are flat without borders, and the icons are thin lines. How is anyone supposed to know what they do??
In most UIs (Apple and Android in particular), I can't tell when one of those on-off switches is ON or OFF. Is the dark side ON or OFF? Maybe the light side is ON. Oh, it's the opposite when Dark Mode is enabled; great.
1. Accommodating disabled people is in no way an insult.
2. Being disabled is a normal fact of life, also not an insult.
3. Accessibility affordances are not only for disabled people. Lots of people who wouldn’t identify as disabled routinely and gladly use a wide variety of accessibility features.
4. Having difficulty identifying actionable elements like buttons isn’t about reading anyone’s mind, and it isn’t a universal difficulty regardless of their presentation. The ability to customize it so it’s easier for you is inherently an accessibility affordance.
5. It’s entirely possible this setting (along with several others under accessibility) may be more helpful when needed if they were available in another location, but it’s also possible that would make the experience more confusing, and quite possibly for more people—especially for disabled people.
6. People may benefit from this information—quite a few here based on other comments—and it doesn’t deserve this kind of negativity.
7. With all of that in mind, while I’m keeping this response direct, I took the last point as a prompt to edit some of my own negativity out of it. I had a strong negative reaction both because I think accessibility is a universal good and because I appreciate accessibility affordances which help me. But that’s not a reason for me to be a jerk either.
I read the parent as implying that it's the designer who is thinking of “disability” as a begrudged requirement that is afforded an out-of-the-way configuration option so as to not inflict the ugly affordances on the rest of the population.
That seems like the least charitable interpretation of the facts I can imagine. Nonetheless if it’s true, Apple doesn’t just wing it when someone goes rogue on full design language redesigns.
1. Accommodating disabled people is in no way an insult.
No, but treating non-disabled people as disabled could be. Just like offering help to some disabled people triggers them.
I was going to respond to these numbered points in turn, but that'd be silly. My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice. To put it under the accessibility options can (if we're even a tiny bit snarky) be seen as an insult - possibly to disabled people as well since it lumps a simple standard usability thing in with stuff designed for people with actual challenges.
It's also not cool for them to make critical UI cues an option when they also take away themes which are the ultimate option.
Ultimately they have given no valid reason to make so many things look the same when they used to be visually (and functionally) distinct.
Sorry for the trigger, I didn't mean any insult to anyone other than the UI designers.
> No, but treating non-disabled people as disabled could be. Just like offering help to some disabled people triggers them.
Putting this option in accessibility settings does no such thing. That assumption is what I take issue with, and what prompted all of my points above.
> My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice.
I disagree. I often find designs with fewer borders and shapes easier to use—that is, more accessible to me—_because_ there’s less information for me to visually process to find what I’m looking for.
That said, I’d be perfectly fine if they inverted the default… or even just asked on first install/startup, with a note on where you can change it later if you change your mind.
This. Material design relies on the browser hint to inform you the mouse/pointer has moved to an active element. Viewed with no focus on an active element, how are you meant to tell which pane of flat colour is a pressable, actionable element?
It looks great in print. It doesn't respect the modality of use for an online world.
I'm tempted to think we have to go to browser vendors and ask them to make <blink> happen..
I ended up reverting back to the old context menu. Those icons are annoying to parse and I have a tendency to look down each row as 20+ years of context menus has taught. And having so many options tucked an extra click away.
This is why I have reverted to the CLI whenever possible.
There's something deeply assuring knowing that I don't have to relearn my whole workflow every few months when the trends change. ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent.
All I want is to get work done the way I want, and I've found the CLI is increasingly the path of least resistance.
> ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent.
Those command-line tools don't have any "engagement" opportunities nor are there bloated teams of product managers & designers having to justify their salaries by reworking them for no good reason.
It can be restored with the `net-tools` package, thankfully. That's among my first installs on a Linux box. Never quite got into `ip addr show` when I've most of the ifconfig flags memorised from use.
Which may contradict my previous point slightly, but at least it is easy to put the system back into a state I want and the system will maintain this state.
At 2600 BC hieroglyphs already included symbols used for phonetic spelling, so hieroglyphs are not the way to go if you want to get rid of spelled out words unless you ban the subset that can be directly mapped to greek letters[1]. Otherwise it just ends up a fancy font.
You jest, but I'm not sure that is a bad idea. bash/zsh seem happy with emojis as function/alias names, and I can input emojis easy enough. In fact some emojis are easier to type in my chosen layout than the string necessary to disambiguate completion for some commands.
Thanks for the idea, and I'll redirect co-worker scorn at U+1F984 for `git push` towards you ;)
Edit to add: Using emoji for commands/arguments is actually quite workable with global aliases or custom zle widgets in zsh, and moderately workable by using $INPUTRC to specify text replacements for readline if you're a bash user.
Had a developer change some config file names to emoji based file names. Boss thought his computer was broken when he took a look at some output txt file. He wasn't amused even though it was April 1.
> ls, grep, find, ps, htop will always be what they are.
SystemD screwed with a few that I'm still discovering one by one. "cron", "shutdown" is no longer in the default debian path, I think ulimit was another one.
But at least I don't wake up one morning with the whole interface rearranged.
cron is in /usr/sbin (and is a daemon, not a command you'd ever run manually); shutdown is in /sbin; and ulimit is a shell builtin, not a standalone executable at all.
If I had to guess, I'd say that /sbin and /usr/sbin aren't on your $PATH for some reason. systemd is unlikely to be the culprit.
This resonates so much with me .. especially the On/Off buttons where designers show off how cool and smooth they can make them look, usability be damned. Dark patterns especially around opt-ins uses these type of controls very well putting a lit of mental load on us to opt-out.
This is honestly a large part of why I enjoy keyboard shortcuts, like F2 to rename on Windows. But it’s of course also a low grade for their UI design because I like it for knowing how to reach it instantly. Unlike by using their user interface.
For everyone mad at at "Don't theme my apps," consider why developers are doing it.
Getting complaints about how your app is broken because of an overzealous theme that is beyond your control sucks. And after 10 years of dealing with it, GNOME developers decided it was enough.
And... I don't wholly agree, but at the same time, themes had a decade to get their act together and stop angering GNOME developers. They didn't.
But why Qt/KDE developers don't lose their minds ? Either GTK theming is broken or the GTK app developers are not using it correctly or GNOME devs are assholes and really.really want to force their branding and vision. The above OR is not exclusive so it could be all 3 things.
I develop GTK3 apps. Theme breakage is generally a very real concern, as it usually points towards an issue with either
a. The usage/implementation of widgets in the application
or
b. The stylesheet the end user is implimenting
In either instance, the solution is very simple and within arms reach. It will always make more sense to encourage robust development practices over building fragile application stacks.
The don't theme my app people were complaining about their bug trackers being full of theme-related issues. Instead of just setting up a filter rule in their tracker so they could ignore those issues, they decided to go super draconian and remove theming for the entire desktop.
That disproportionate response to what comes down to an organizational shortcoming on their end made people upset, I'm not sure what they expected.
Note that they don't care about the themes their end users pick, though. You can theme your app just fine. They just want operating systems using their software (with their logos, trademarks and support links) to stop shipping their custom themes by default.
They just don't want Canonical or Fedora to ship a theme that makes all applications that didn't come bundled look like shit. If you like the Windows 95 Hotdog Stand theme, you can configure that and everybody probably agrees that that's great. If you inflict that pain upon yourself, that's your problem.
The current "solution" to themes breaking applications is to just not follow the system theme any longer. Everything gets packaged with a hardcoded theme in a sandboxed environment and you'll just have to live with that.
So what? Why should they continue to support some minor feature if it costs them a lot of resources and they think it's not worth it because it doesn't really fit their project?
If you have a feature that is used by one customer out of thousands but it's causing problems at every update you push out. It might be better to remove the feature and fire the customer, than to keep supporting it no matter what.
Now you know why the application developers are so loud and angry. We can’t have nice things because distributions shipped broken default configurations, and that’s messed up.
Don't say "the application developers" like we're all one person. There are multiple GTK developers in this thread that don't care what distros ship with: this is exclusively a GNOME complaint. Don't drag the rest of us into this.
honestly i would rather remove the ability of developers to make shitty controls and widgets. GUIs either ask you for some set of data or display it to you. Weve had a basic set of controls that work great for decades now. Im all for a platform that just requires the use of those and maximizes the ability if users to theme away.
I agree 100% with the author, the old GTK button was gorgeous, it will be missed.
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
This is one of my biggest complaints with the super flat modern designs. Many widgets lost their skeuomorphic depth, which encoded a lot if visual information (the clickability, the current status), but in many cases nothing was added to supplant the loss of those visual cues, so now it is just a label (or a label in a white or grey box) and there is no way of knowing if it is clickable or its current status.
I'm also really not sold on those new "tabs" which are just text with an underlined colour. It's low effort and dreadfully unclear. I can only vaguely guess what they are based on their upper placement, but what's to really distinguish that from a menu? or just a descriptive label?
I don't like saying this because I want Linux desktop apps to have every success, but these small and pointless frustrations kill my enthusiasm.
As a side point, I predict Sheriff and Sans-Sheriff fonts to also go into similar phases too though over a longer time scale. We're in a very long Sans-Sheriff phase now but I think Sheriff will be "in" in 20 years.
FWIW, Macintosh System 6 was just black and white (and only 640x480px), so 3D wasn't really tenable.
System 7 and 8 had support for color, and was as 3D as it could muster, like highlight and shadow treatment on buttons and other widgets, and embossed, draggable thumbs.
Mac OS X brought Aqua, which was a pinnacle of 3D and skeuomorphic design. You know you're going hard for 3D when you add a drop shadow on all the text in your menubar:
I'm using macOS 12 right now and there are a lot of 3D elements especially if you compare it to Windows 10 or Gnome in the screenshots of this post. It seems to be a mix of both approaches (similar to GTK 3).
It's not very different. I don't know if "flat" was ever the right word to describe the look it started moving toward post-Aqua; I think I'd be more inclined to call it "minimal", occasionally to a fault. With a few exceptions (most notably the bonkers choice to make all keyboard shortcuts gray in menus so at first glance they all look disabled), though, I mostly like the look that Big Sur's ushered in.
Recently I’ve been enjoying serif fonts in more places than I used to, because I instructed Firefox not to allow sites to override my font choices (so I get exclusively Equity for serif, Concourse for sans-serif and Triplicate for monospace), which is quite pleasant and relaxing in general (Google’s foolish/poorly-implemented ligature-based icon font technique is the only notable breakage/uglification I’ve found in the couple of weeks I’ve been doing this), but apparently it’s more common than I realised for people to omit the fallback “sans-serif” or “serif” or “monospace” that they should always have on their font-family stacks, and my fallback default is serif. (e.g. I’m just now looking at a `font-family: 'Lato','Helvetica','Arial';`, and yesterday examined a `font-family: some-web-font, Open Sans;`.)
A couple of times i found myself clicking on various text labels just to see if it is a title or a button. All these flat minimalist designs are a step in a horribly wrong direction.
I've seen all 4 combinations of "looks like" vs "is actually" {button,static text} on a web app I was once forced to use. Some of the plain text was actually a clickable button (with NO hover effect), and some of the "buttons" (or more precisely, short actionable text with a rectangle around it) were actually just labels. Imagine the word "Order" presented in both styles, and my astonishment when I figured out which one I actually had to click.
I spend far too long in GTK apps looking for the right menu to do basic stuff. It's like someone once saw an iPad from across a room and tried to implement what they remembered of it.
The flatness of some UIs along with the removal of some visual cues has happened that I have tapped on things that aren't actually a button thinking that they might be one.
When I make my own apps one day, I am going to ignore design fads and only make intuitive interfaces.
we started using Full Story at work. It tracks clicks on non clickable items. It is staggering that this is even a problem. Having to explain to people that links and buttons and radio boxes and checkboxes should look uniform has gone the way of the dodo and now we must instead have people clicking random items to hope something happens.
This rattled my brain, that this is a feature now, says volumes about the quality decline in UI. I am a developer, and mainly use tools on the command line, or with TUIs.
But whenever I use android apps and websites, I constantly find myself longclicking or rightclicking things, hoping for stuff to happen, that just doesnt.
Interesting concept, but I would add keyboard shortcuts (underlined items) to the menu to make it more of a reminder than be forced to use the mouse all the time.
Visually nice but it's almost always going to overlap the thing you've right clicked. Under any circumstance I still want to see the thing I've right clicked.
This and many variants of the idea has been explored in games a lot - in particular in point and click adventures and isometric (or at least top-down view) RPGs. Probably also in strategy games and anything else that has both a cursor and context-specific actions.
I too hate the material design kind of flatness. For me, only apple somehow gets UI right (at least for me) and it feels very intuitive for me while also looking very good.
The new "flat" design that pops up everywhere sometimes just feels like a lazy version of UI design, where you basically don't need proper styles anymore and just make everything b/w with maybe a border here and there.
My understanding of material design is that it tries not to be too flat. Material design reduces the 3d roundedness and gradients of many elements but still relies heavily on drop shadows to indicate hierarchy and overlapping.
> I too hate the material design kind of flatness. For me, only apple somehow gets UI right (at least for me) and it feels very intuitive for me while also looking very good.
I dunno about that (both Apple using flat, and the "gets it right" part).
I'm looking at activity monitor now, under memory pressure, and the table of memory types has "Memory used" row expanded, and yet none of the rows are actually clickable. I spent a few seconds yesterday trying to click the other rows.
Then I looked at system preferences, and it's not actually flat widgets - they have relief for those things that can be interacted with. Things that are clickable are visually marked as such.
>I'm looking at activity monitor now, under memory pressure, and the table of memory types has "Memory used" row expanded, and yet none of the rows are actually clickable. I spent a few seconds yesterday trying to click the other rows.
I can see why you might get confused there but it feels like nitpicking. I never expected to click on any of those elements because they don't look like a traditional table or outline view.
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
Exactly this. I often help others use computers and phones. In the old days it was easy to see what could be clicked. Now input and output look the same. It makes it harder to use.
In many ways it is a victory of style over substance - UI's are now designed by the same crowd who designs high fashion, that is clothes not designed to be worn but to be gawked at.
> In many ways it is a victory of style over substance - UI's are now designed by the same crowd who designs high fashion, that is clothes not designed to be worn but to be gawked at.
Is it? Style is no style at all if the thing in question does not fulfill its function. The whole point of something stylish is that it accomplishes its end so well and respects the appropriate constraints that is pleases the intellect when it recognizes this perfection.
So if someone is designing a UI that is difficult to use, that is a failure of both style and substance since there is no style without substance.
In the case of the article, that is somewhat unfair.
> GTK4 has been in development for a bit and has improved a lot of the internals. One of the great upsides is that it can take more advantage of the GPU when rendering the UI.
So there was a clear need to rewrite parts to fix internals.
> The Adwaita theme has also been nicely carried over and looks very similar to the GTK3 counterpart.
...
> When I want to make a gtk4 application for mobile I would need libhandy, but libhandy for gtk4 is not a thing. The "solution" is libadwaita. This provides the widgets I need but it comes with the downside of having some of the worst decisions in application theming.
So, there we have it: it's not "UI folks just changing stuff", its a ground-up rebuild of a UI-language.
Now, whether or not that ground-up should be flat, modern, or just copy the old, is another discussion.
> In many ways it is a victory of style over substance - UI's are now designed by the same crowd who designs high fashion, that is clothes not designed to be worn but to be gawked at.
I'm an art-school educated designer, decade+ full-time web developer for over a decade and regular FOSS contributor for about as long, and regular FOSS users since the late 90s. Like most other designer/developers I know— there are way more than you think— I contribute code regularly but never design work. Why? Because it's a sucky experience.
Most FOSS UIs are akin to someone's first website made from cargo-culted code from free tutorials. Fixing it is harder than starting from scratch and either approach takes significant intellectual work before even seriously proposing changes... and those proposals are received with something on a spectrum of suspicion to outright hostility.
Would you contribute code to a project run by people with no coding experience but were extremely opinionated about code, bikeshedded and poopooed all code changes as a matter of course AND referred to developers and their work with the same glib contempt you and so many other developers here displayed in your comments? Gosh I hope not.
I often hear FOSS developers lament lack of designer involvement, but won't even entertain the prospect of having any culpability for that. I mean, come on.
UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. The problems you see in UIs are because the people running the projects Solicited the wrong kind of designers or let people without subject matter expertise trampler on some core features of the design.
To some extent you can tell from their title and previous work, just like with developers. Foe example, I had an entirely non-technical boss that understood I might not be the guy to re-write some printer drivers because I was a web developer. He didn't know the specifics, but being in charge, knew he had to ask someone who did, or do enough research to figure it out.
Likewise, UI designers will specialize in designing UIs and be better at making buttons look like buttons than Graphic Designers, and Experience Designers will be better at integrating user feedback and research into projects. Just like you wouldn't trust any one developer to implement critical functionality you don't understand without outside input, you probably shouldn't rely on one designer to that either. If you maintain a project, though, you can't expect designers to instinctually work around what you don't know. Being in charge means that you're in charge of figuring out how to evaluate it. I'm positive that a "I'm not sure how to interface with this sort of thing. Let's work through it so I can figure it out." will be received kindly by people you should consider working with. Good design proposals should already come with explanation and justification to help you down the path
This is a random selection from a google image search of proposal ideas. It was from another post where I was talking about higher-level topics but the principle is the same. Changing a set of control widgets should require no less thought and explanation.
> Developers absolutely refer to developers with glib contempt.
ok— now copy and paste the rest of what I wrote. An overly opinionated, defensive person with veto powers that understands the purpose and value of your work is fundamentally different.
The complaint about flat design isn't levelled only at FOSS, but at the whole industry. Your points may explain the situation in FOSS, but it doesn't explain the poor work being put out by the thousands of designers and UI/UX people working as professionals in industry.
Part of me wants to throw up my hands in the air and cry out "Why, God, why?" when I encounter yet another UI with flat design.
It is like a mass delusion or something that some segment of the population seems to think it that flat design is actually useful for the everyday user.
We've seen other stupid useless crap spread like a wave across our industry, across our society... so I guess I shouldn't be surprised. Though I've started to question my own sanity.
Modern UI design is optimized for screenshots in a PowerPoint, and from there, to screenshots in a portfolio and on marketing pages where the audience that needs to be satisfied is marketing themselves, and especially people very concerned that every piece of everything be "on brand" and who are entirely sure this matters a ton for making sales.
a) there probably aren't many lead designers, creative directors and art directors on this developer-centric site
b) interface choices for most commercial products are deliberately made by other people
c) interface choices for most FOSS projects are made by developers
Second, I didn't directly address the criticism for the same reason I don't go into game forums and argue with the inevitable teen tech wizard lobbing glib, unsubstantiated technical criticism at the "stupid devs." Their peers might believe their saying that a "microservices architecture" caused low frame rates in the last release, but professional developers will roll their eyes hard enough to sprain an eyelid.
I won't waste my time with a point-by-point teardown, but if you're actually interested, here's the first half dozen unsubstantiated assumptions I've seen here about design/designers and the design process:
- 'Flat designs' are uniform enough to judge their value as a unit.
- A bad flat design was bad because it was flat— not the hundreds of other problems a design can have.
- Designers change things solely to suit their taste or follow trends
- Designers don't commonly test or measure usability with quantifiable, auditable data
- Bad usability is acceptable if it looks good.
- How well you parse something is representative of how everybody else does regardless of their culture, age, experience with other objects, experience with computers, vision, disabilities, etc.
- Skeuomorphism was the most effective form to convey those visual cues.
aaaand the list goes on. It's fine that many developers don't totally understand how design works because nobody expects you to be a subject matter expert in anything other than development. That said, confidently making sweeping judgements about design and designers when you don't understand some important fundamentals is just bad form.
> UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies.
As a developer who always had an interest in UI design but has zero formal education in the field, I be really interested to know more about this. Could you maybe explain some of those strategies?
My subjective impression is that design has shifted from building a consistent "language" to a more goal-driven and data-driven approach today. The product owner defines a list of user stories and UI is primarily concerned with making those user stories as frictionless as possible - even if this means a less consistent overall design snd even if it means that less common features become harder to use. Performance is measured in a feedback loop through telemetry and A/B tests.
I might be wrong though, so I'd be interested in a qualified opinion.
(Also disclaimer: I grew up with Windows 98, ME/2000 and XP. So I guess this is my "good old times" spot then, where I'm wearing the rose-coloured glasses.)
Yay! UI design is cool. I really love helping people solve their problems with software and often find the intellectual work involved with crafting their interactions to be far more interesting than getting the best algorithm for something, implementing the most reliable architecture, etc.
What I believe you're noticing is the the adoption of ideas under the (poorly named, IMO) UX umbrella. UI design is either considered part of it, or close enough to get the UX/UI slash treatment. It's not quite there as an idea— people can't decide if UX people are the same or UX Researchers are different than UX Designers or if UX Designers just do wireframes and user flows or also design UIs or if that's left to Interaction designers, blah blah blah. The base ideas seem to be an amalgam of human factors engineering, graphic/media design communication theories, and quantitative marketing type work.
While there are hundreds of trillions of articles on the topic by people thirsty for medium claps, I think the most interesting jumping-off point might be an image search for ux design process and using the charts you see to guide an exploration. The Nielsen Norman group has a TON of stuff online about the topic. Not just design itself, but measuring the maturity of usability organizations, research techniques, best practices and data strategies... I mean all kinds of stuff.
I think a lot of the ideas are tremendously valuable but much of what's written about it feels a little bit too much like marketing material. The ideas are presented a bit too confidently considering how often they change, and too much has that LinkedIN magic bullet kind of vibe. Also, like tech, the industry is subject to spike trends (like tech saw with NoSQL databases) and pendulum swings (like centralization vs. decentralization of services, thin vs thick clients, etc.) For something a bit more structured, the former Lynda.com, now LinkedIn Learning has some really fantastic educational resources on modern design of nearly any stripe.
I'll swing back through if I can think of any specific resources worth checking out.
Yeah I keep saying that modern UIs are designed to be looked at and enjoyed like museum art pieces, not to be actually used. They look nice-ish when static, but they're unbearable in real use.
i don't think flat design is really a question of style over substance. flat design has been popularized because designers like it, but designers like it because it's easy.
a flat element can be re-coloured without having to worry you've gotten the shadows correct on the new color. you can put two buttons beside each other without worrying that one appears to have more depth than the other. we make things flat because we're lazy, not because we think it looks good. a culture of lazy designers has convinced people it looks good, so we can continue being lazy.
The one that irritates me these days is working out at a glance what has input focus. Window borders are so thin, and the difference between focused and not minimal, app have custom chrome so while titlebars are a good indicator sometimes often they are not, or are just two subtle, etc. MS Office apps are an offender here.
Which of those has focus? There is actually a difference (and to take the screenshot they overlapped making it obvious that way) but it is subtle. Try spotting it reliably when they are on different monitors.
At some point it'll annoy me enough that I'll write a util to scan for the current window that is top of the stack and draw a bright green border (or otherwise unmissable clue) around it… It'll look ugly, but I'll darn well know where what I'm about to type will go!
100% agreed. I want buttons to, at minimum, indicate that my click or touch was successful. Even a little wiggle. Flat design has me wondering with no visual indication, and I hit this all the time.
Borderless buttons to have the right to exist, but you should be very careful with their use. For example, take this UI I made recently: https://mastodon.social/@grishka/107998100334356147, 2nd screenshot. The button to decline invitation looks like a link (same color) and it's next to a real button. No one would ever get confused by this, it's pretty clear it's clickable.
But a black word in a larger font among black text would definitely NOT be recognized as a button by most people. Context matters a lot.
I disagree. I had to sit and think for a few minutes as it was extremely unintuitive - my first impressions were that I couldn't decline the invitation at all, and the button was disabled or missing for some reason (I've seen some bad CSS in my career so it no longer surprises me when it goes missing).
> No one would ever get confused by this, it's pretty clear it's clickable.
I don't know how you can reach that conclusion, because we only recognise it because of how many times we've been fed this exact pattern over and over again in flat UIs (and failed to realise it was clickable the first N times)
It does not look like a button. It's just a label floating around.
When designing user interfaces, use the mantra: "Don't make me think!" Don't make the user think about whether something is a button or not. Don't make them have to infer that the label is in fact a button due to context.
I am but an ignorant user, but making you think to do complete one action but not another seems to be a significant part of the point. I find it deeply coercive, and hope to see the other side of this trend sooner rather than later.
Moving the goalposts, but the decline button in your example looks significantly harder to engage than the join button, and engaging with it would cause at least a twinge of anxiety in anticipation of having to essentially coerce the interface to accept that I do not wish to travel the gilded path.
It frustrates me that this sort of design has become not just acceptable but celebrated as 'correct', and I long for the days when interfaces did their best to seek my enthusiastic consent to my chosen course of action.
It's not very clear to me it's clickable.. Is it an action, or a link to a different page/view? If it's an action (accept/decline invite), make it a button. If it's navigation, make it a text link. You are giving totally disparate cues to the user when the actions taken upon clicking are of the exact same type.
My initial reaction to a piece of text directly next to a button is "why is there random unrelated text there?" and then the sensation of anger as I come to the realization someone consciously decided to make me think about the UI more than I needed to. It's purely a distraction.
Just make it look like a button. There is literally zero reason not to, and you can eliminate the chance of confusion. Why increase the possibility of uncertainty at all? What value does that provide to anyone?
Every UI or design element that causes me to think about it wastes precious moments I could have been thinking about something I actually cared about, for example the actual task I was in the middle of. On top of that, when you use unconventional design, even after someone learns the seemingly-arbitrary, specific quirks of the design you've used, you will cause them to think about it all again later when you redesign the application.
Literally zero reason not to? I think it’s emphasising the “default” action quite nicely, and de-emphasising the other action quite appropriately.
“Decline invitation” needs to be something you can do, of course, but it will be used < 1% of the time, I imagine.
I find that having buttons side by side forces me to think in a mildly unpleasant way, like I have to read two thinks more carefully because there is more onus on me to decide which is the typical action.
No, that's still not a reason to conceal the behaviour/purpose of the UI element.
If you want to emphasize/de-emphasize a UI element, you can do something like was established on most GUIs 30+ years ago: make the default/safest option have a thicker border, and the secondary/de-emphasized option have a thin border. Early examples (1985 and 1991 respectively):
Note how immediately-obvious it is which action is the "typical". You don't even have to read the text, you could even squint your eyes or glance from a great distance and still understand which button is the one you probably want.
UI design involves trust, especially for software where people are trying to actually get something done. Making unconventional designs erodes your users' trust. Have respect for them and what you can reasonably expect them to "know" arriving at your software, and they will have an easier time and love you for it. As we can see, these conventions have existed for decades, and deviating from them warrants a very compelling reason, not just "cuz it looks neat".
The button to decline doesn't add an entity. There are already two options to consider whether to accept or decline. Making the external state and internal state match avoids confusion.
That's an action link, not a button. In a UI context it would be rendered in a different color and underlined, to highlight it being an active element rather than a simple label.
Like so many other pointed out, this is wrong, I got confused, it looks like a link, would that get me to some kind of unsubscribe page? is it phising?
buttons should be actions,
links should be directions,
directions would take me somewhere, actions would has an effect and consequence. That you think this is okay, and assume no-one would ever be confused by this. Is clearly an issue in the industry at large
>No one would ever get confused by this, it's pretty clear it's clickable.
It's pretty clear that it's clickable, but I definitely wouldn't think it's a button. My best guess would be that it's a navigation element, and that clicking on it brings you to some other page where a decline invitation button might be found, or where you have to fill out some form to explain why you're declining.
Part of it is because it looks exactly the same as "Test User", and presumably that isn't a button... I imagine that is a navigation element. But part of it is also because quite a few recent Microsoft corporate products (Sharepoint, Dynamics, etc.) seem to use the idiom you're trying to use for signaling that something isn't a button.
Misuse (or no use) of affordances is so, so annoying, both in software and real life.
Things like having pull handles on both sides of a door that has to be pushed from one side. Or having no push plate on either side of a glass door. Do I push? Is it a sliding door that's not working? Don't know!
My car has the climate controls hidden behind a graphic of the current state on the stupid touch screen. It used to be buttons that had three zones for head, body and feet, a wheel for fan and a wheel for temp[1]. Volvo used to pride themselves on having controls you could use with gloves on, so all the buttons had 3D features and a positive press feel.
Now it's not even obvious the graphic is a button at all (it's also incredibly dangerous as you cannot do anything without a multi-click modal process with only visual feedback that you have to look at to use). Thankfully the window demister is still a physical button because that would be incredibly dangerous to hide behind a soft screen interface: when you need it you need it. However, it's lost its 3D profile and is now just a flat button.
My office has an amusing one: there's a door at each end of the building. The building is the same on both sides, neither side looks more "fronty" than the other, and the doors are the same. Only one of these is the main entrance. The door next to the car park (i.e. where anyone unfamiliar with the site will arrive) is not the main door. Therefore there are no call buttons. However, there's also no indication that there is another door on the other side. A whole building basically has no obvious start menu. Just...why do that?
Wow, that's definitely something. Implying that tinkering with the low level aspects of a system are acceptable, but don't you dare apply a different stylesheet, because adjusting colors is delicate work that shouldn't ever be done by anybody but the developer.
I agree with the key points though, which is that distros need to stop messing with themes unless they can validate that all applications work with custom themes.
They bear no ill will against users who download or make their own theme.
Getting rid of themes is a decision distinct from that of choosing the one true theme. Going with FLAT was a poor choice and is what the current discussion is about. If there is any irony it's that more people will want to change the theme now, since the default is worse than before.
> The dark theme, while not officially supported as a normal application theme, works absolutely brilliantly and is a great example of how to design a dark theme.
There are only three small screenshots of UI in the dark theme, but to me it looks very clearly like a naive "invert all the design token colors and call it a day" implementation.
You can't make an omelette without breaking a few eggs. (You can't break the back of modularity-induced fragmentation and make a consistent GUI without making a few people unhappy with the UI design that the majority chose).
That is Gnome. Gnome has become a top-down project that values consistency/coherency over modularity/theming. It's an extreme, and I suspect that they went too far, but with it comes a number of benefits, such as a unified visual style across all apps, and an easy to use internationalization/localization subsystem.
Gtk+ 3 with a custom theme allowed for a unified visual style across all desktop environments, not just GNOME. I could use a MATE- or Xfce-bundled app and not have it look out of place in a GNOME desktop, or vice versa. It's sad to lose this because of a combination of pointless churn and active hostility ("don't theme my app") to outside efforts that might improve the ecosystem.
>> You can't break the back of modularity-induced fragmentation and make a consistent GUI without making a few people unhappy with the UI design that the majority chose
Not sure what that even means. The majority are not the Gnome developers, and many users will just adapt to whatever they're fed, even if it's worse.
>> That is Gnome. Gnome has become a top-down project that values consistency/coherency over modularity/theming.
No. People aren't complaining about a lack of consistency or a lack of theming (some do). They are complaining about a shitty design where the elements are consistently nonsensical and harder to understand than past version of the same.
Top-down means a few people who are at "the top" think they know better. Not that they're great designers either - they are copying stupid trends that other "design" people came up with. This stuff is complained about on all OSes these days. It's not a vocal minority either, and you can tell because nobody complained that GTK was falling beind and needed to update to a modern "flat" design.
What you're not understanding is, just because something seems nonsensical to you doesn't mean that the majority of users don't find it perfectly reasonable. But you've already waved that possibility away by saying that most users will take whatever they're given, so I don't suppose you'll consider it.
> That is Gnome. Gnome has become a top-down project that values consistency/coherency over modularity/theming
They care about that so much that they break Gtk+ every few version, to the point that in 2022 there are still Gtk+ 2 apps around, and there will be Gtk+ 3 apps following old design paradigms for years to come. So much for consistency.
It's 2022 and I don't see Qt 4 around anymore, or apps using it still being widely in use. Guess why? Because Qt developers actually give a damn about people using their library, and they give a damn about people using the _latest_ version of it.
What GNOME is doing today is telling everyone to go fuck themselves, and pushing people towards writing their next app in Qt, which by the way integrates nicely with GNOME and does not look like garbage everywhere else. Now with PySide being finally a first class citizen and working well with QML there's not even the "but C++ is ugly" card to play against going Qt.
Wait ten years. New people will start working, old people will move on to other things. The new people will change stuff, mostly for the sake of it as it always happens, and one of the results will be less flat interfaces. Old people will be infuriated by the change. Very old people will rejoice but also complain that those UIs are not as good as the really old ones. New people will shrug them away and keep changing stuff mostly for the sake of it as it always happens.
It's already happening, new interfaces from both Apple (see Big Sur/Monterey) and Google (Material design) are noticeably less "flat" and going back to 3d effects for "active" widgets. The effects are much as seen in GTK+ 3 - just subtle enough to not look overly confusing when compared to a totally "flat" screenshot, but still helpful to unfamiliar users.
This presumes that all things are equally good and the only difference is familiarity. This isn't generally true of other functional areas of endeavor. Neither computers nor cars are all alike save aesthetics. I see no reason why it would be true of UIs.
On macOS Desktop, checkboxes, buttons and everything else are still designed for mouse/kb
On gnome things are designed for vertical and touch screens, so you forced to endlessly scroll, windows is doing something similar, wich is an indication that they target mobile users, they are so out of touch
Only Apple knows what they are doing when it comes to UI/UX for desktop, and they make sure they don't mix desktop/mobile UX
---
Now one of the worst parts is that everywhere I only even hint at not completely loving the new libadwaita theme I instantly get shut down and disagreed with before I can even get the chance to give some feedback. Apparently not liking flat themes makes me a madman in this world. Why am I not allowed to even have opinions about the look of the operating system I'm using?
---
But to be honest, isn't it one of the recurring point of people running away from gnome? Haven't they just proceeded going ahead not listening to anyone?
It's kind of cathartic watching this happen to a new generation of developers. They can't say I didn't warn them!
Ultimately I think this will be quite good for QT/kde in the long term. Gnome/GTK gets a lot of corporate support, especially from red hat, but seeing the issues pop OS had with GTK makes me hopeful that more companies will adopt QT.
I've been hoping that for 20 years but it hasn't happened yet. It seemed like American companies always favoured GTK/GNOME (I guess because Qt/KDE development was more European?), even though Qt/KDE generally managed to do more with less. But I can appreciate that if you're aiming for the corporate market, customizability may be a downside.
I think that Red Hat (now part of freaking IBM) has always been oriented to big corporations, knows how to speak their language, and is an obvious choice for corporate Linux support. If you're already in bed with RH on the server front, it makes obvious business sense to also follow them on the (much, much smaller) desktop front. Since RH basically owns Gnome development (I know, I know), they impressvely used it as a lever to push systemd adoption, for instance: major distros had to switch to it not (solely) on its merits, but because they could not drop Gnome support.
KDE does not seem to have an equivalent behemoth behind them, even though Qt enjoys a lot of heavyweight corporate support.
Which is insane because even back in KDE 3.5 days, and Trinity following that, the support for complex user environments, security features, using any type of remote storage natively through the KIO subsystem, really good support for LDAP and AD and other things... it seemed like a natural fit for a more complex corporate environment. Especially tools like Konqueror and Kmail, both of which to me follow a natural progression out of the windows of the late 90's era, had really good usability and made sense fairly quickly to windows users.
Yeah. SUSE (at one point owned by Novell) was kind of trying to go the same route, but never really got as big as RH. (Though again I wonder how much of that was just an America/Europe split)
So basically the new GTK is iOS but without the professional designers behind it.
What I cannot understand is how Canonical, Red Hat, or some rich SV person hasn’t thrown money at the problem and hired a big wig design firm or person to overhaul it all. Johnny Ive is now even available (if he’d take the project). But even going thru a site like dribbble there are so many amazing designers out there. To me it would be a more impressive portfolio piece for a young designer to properly design GTK/Gnome and put it out there for the world. What is stopping this? It can’t be caring with the history of people sharing their themes. Is it just taste / money?
Lots of rich companies threw money at the problem of Linux UI, Linux application packaging+sandboxing, and several other things. The result is the Android OS ecosystem, where each hardware vendor has its own proprietary shell, in capitalist competition with other vendors’ shells.
I’m not even saying that that’s a bad thing. As it happens, Android has been generalized and generalized from its original use-case until it is today a quite-workable desktop PC OS.
Easy for someone who works at Apple to say "just throw money at the problem" while there is so much more to consider. Design as a workflow for Open Source design (as in UI/UX) hasn't even been worked on that much. Ideally, open source contributors work on projects because they care about it, and want to improve it. I'm not sure how many designers are using GTK applications day-to-day to care enough about it to start contributing. There is a learning curve as well on how to contribute to these large projects.
It'd be great if it could be solved with just one pass of design work and then it's done, but I'm afraid the task is much bigger than that, and "big wig design firms" are expensive, so are design people as well. Not to mention the other problems around that.
Inherently, good design requires top down authority to force a consistent look, and implementing it requires a bunch of programmers to spend time on boring work. That just doesn't work well in open source where people only want to work on their own thing, sometimes, and in their own way.
Same could be same about good software design (as in programming), but we've found to design well written software before in a open source manner, I'm sure we could (if we focus on it) figure out something for UI/UX design as well that works in a open source context.
For example, style guides written and enforced by a small team can allow open contributions for the UI design.
I think it's mostly that not many have tried to figure out how to organize and actually run large-scale open source design work for UI/UX and that's why we haven't figured it out, I don't think it's "inherently" impossible.
And look at how these projects are organized. Most of the time it's pretty much top-down with a. It's why we have the term BDFL.
> good software design (as in programming)
That's the second problem. Most programmers probably know about about how good software design works, but have poor taste and prefer designs that aren't suitable for software that is to be used by non-programmers that want sane defaults that work and don't overwhelm them.
Just look at the theming debate. People in software developer forums are mad about it. Most users probably don't even know it exists. They just want settings and a UI that's simple enough for them to understand and allow for some basic settings.
So you would have to force volunteers to implement a design that they feel is bad. And you see how a lot of people react to it in the Gnome project where people leave because of it. But at the same time Gnome is a good example of how to do UI/UX for a big open source software project (even if you don't agree with their design decisions).
> And look at how these projects are organized. Most of the time it's pretty much top-down with a. It's why we have the term BDFL.
To make a more general point: top down leadership is not inherently bad. But in order for this to work well, people need to have the ability to enter and exit a project or polity at will.
(See eg how McDonald's doesn't let customers vote what to put on their menu, but customers are free to eat at a competitor or make their own food at home.
And compare that with North Korea also not letting citizens vote on their menu. But also taking steps to keep people from switching to a competing provider of government services, like South Korea. Similar also for the Berlin Wall.)
As I mentioned before, Canonical and Red Hat have money and could afford proper designers. Programmers are expensive as well, and they have plenty of those on staff.
Someone is putting together standard HIGs for Gnome, writing these standard themes, designing the base apps, etc. So you can't just say it's all decentralized and so there's no hope -- there's a ton of collaboration and top-down work happening with Gnome. Pulling in great UX/UI design talent should be prioritized.
> So basically the new GTK is iOS but without the professional designers behind it.
Professional designers seem to be the ones creating these problems. Back when it was just programmers you could tell a button was a button, a tab was a tab and we didn't hide basic functionality behind a swipe gesture or long press that users were supposed to just know.
> Back when it was just programmers you could tell a button was a button, a tab was a tab and we didn't hide basic functionality behind a swipe gesture or long press that users were supposed to just know.
You're basically proving the point. That is so much clearer and obvious to use than the screenshots in the original article, and it doesn't treat you like an idiot.
Yes, I know which things are buttons, which things are text entry, and which are checkboxes. This was a strength of early 2000's UI design, and it's a shame that so many applications don't give such clear indicators any more.
This application still has an absolutely crap design.
* How do I specify where the downloaded data goes? Why are there onscreen options for literally everything else, but not that?
* Which text entry fields are disabled, and which ones are enabled? This is something Win95 got right.
* What even is "force directories"? And it looks like checkboxes are used for both it and "no directories", so what happens if I check both?
* What's the difference between Spider and Recursive? Those sound like the same thing to me, and I know I'm in a pretty elite club just knowing what web spiders are at all.
* Are jpeg/gif/etc only used when Reject is turned on, or are they also used when Accept is turned on?
* Is the wget-list input field connected to the Input file checkbox? It's right underneath it, and presumably I have to specify the input file somewhere, but the spacing implies it's not.
* What's the difference between "quiet" and "non verbose"? What happens if both are turned on?
* The rest of the buttons are pretty well labeled, but what's AG?
* Does it really need its own quit button? The window manager already provides one.
I'm not saying it's perfect, but it's better than the "small mysterious monochrome hieroglyphics floating in a sea of white/darkness" that "modern" UIs seem to be gravitating towards. At least textual labels are searchable.
I didn’t stop listing problems because I ran out. I stopped because I got bored. Now you got me going again:
* Why does input-file have no “Browse” button?
* Why does log file have no “Browse” button?
* What is the point of showing the command line flags? I’ve seen a few GUI apps that let me “export CLI” commands that match what I configured in the GUI. That would be a much better way to do this.
* Why does nothing indicate that the exclude/include lists are only used for recursive fetching?
* Extra Params can potentially be very long, yet the box is tiny.
* I assume quota=0 turns the feature off. Why no check mark?
* Why do the exclude lists have check marks, when leaving them empty should be equivalent to turning them off, if quota has none.
Wget’s CLI is better than that thing.
> but it's better than the "small mysterious monochrome hieroglyphics floating in a sea of white/darkness" that "modern" UIs seem to be gravitating towards. At least textual labels are searchable.
I did intentionally start my post by saying I agree with this part. iOS 7 was a mistake.
Were you raised in the desert by a cactus or something? Because there is nothing clear nor obvious to me about that motif word salad.
Ah, I can just feel it failing to pop up a tooltip when I mouse over the "spider" option!
I can also feel the entire window disappearing when I click "START wget." Is that what happens? Maybe not, but that was par for the course on a lot of those motif GUIs.
And I can definitely feel how the growing information density was even frustrating the poor dev. "Load sett.", "Save sett.", ah fuck it... "AG"
And again, feeling the disappointment as I mouse over "AG" and get nothing...
There are many crappy UIs made by dragging buttons and labels in visual editors, but I believe this example comes from a discussion of a different problem. Namely, how to make a non-shitty non-toy GUI for a console tool. And the answer is, you can't, unless you'd already had the mental model, the hierarchy of options and modes of operation that could be projected onto both types of interaction before you made them.
Essentially, this is not even a GUI application, this is a printed cheat sheet for console program with interactivity, like HyperCard or '90s context help systems, but with “callbacks” affecting the program state. It is made for people who know and understand the console version, and just want to choose options with the mouse. Of course, it may be advertised as something made for regular people, but that's a honest false belief. It's more of a convenient shell alias transferred into 2D, something which is not expected to be super nice, or handle all corner cases if it helps you in general.
I think it is, actually, something to be encouraged. There are some tools that people made in Flash for their own use or some fan group because that's what they “programmed” in, not to mention big examples like (Visual) Basic, etc. A user is not just a consumer of what comes to the dumb personal device, a user is someone who can make it work in some unique way, because that's what computers are made for.
1. Developers with a wide range of understanding of UI from negligible to acceptable.
2. UI experts who actually understand code.
3. UI "experts" in industry whose only skills are image editors.
4. Academics who did said research.
Seems like the entire problem is the ascendancy of Camp 3 which decision makers who being ignorant of technical matters themselves can't tell from camp 2.
That's my impression too. Camp 2 is also a problem when they decide to improve things under heavy time constraints, but it's mostly camp 3 being the issue, and camp 4 being ignored.
Meanwhile, camp 1 mostly won't break anything by themselves (developers do usually learn enough UX for that), but also are unable to fix anything.
I'll just add that camp 4 didn't exist only in universities by the time those things got developed. But they almost only exist there now.
I think the problem Gnome, and Microsoft, have is they keep throwing money at designers. So designers keep making designs for the sake of designing. They should stop designing, stick to the design they already have and only do incremental updates when new widgets come out.
It's not like everything was perfect in the past and so we're done. Far from it.
Even beyond that, the world is changing. New needs, new expectations, new styles in design. Just like we wouldn't expect cars to be frozen in time in the 1950s, we shouldn't expect UI/UX to be either.
Linux DE's have never had a particularly well thought out, well designed look. There's been a lot of themes that people create to mimic other commercial systems out there, but not a lot of very high quality original work going on. Yet we can see plenty of good work technologically. For a long time when it was largely grey beards most people didn't mind so much, but now people expect good design across all products. The standards have risen, and the FOSS world should meet that challenge head on.
The article is really about GTK3 versus GTK4, using the settings pane as an example. My comment is about the larger picture. However, take a look at what it meant to reset your default settings in 2010: https://www.omgubuntu.co.uk/2010/08/restore-default-gnome-se...
Settings panes are still largely confusing on all platforms, commercial included, as you broaden your user base. They've also grown in utility as iOS has pushed the idea of a centralized place for settings for all aspects of the system (apps included), which you're starting to see elements of on other platforms as well. There's plenty of room for improvement, including simplifying everything down so that few settings can make big differences where the heavy lifting is done for you. Linux in particular suffers from this, from a legacy of a million .conf files everywhere that many people blindly copy-pasta'd random configurations they found online (I'm looking at you XFree86).
To play a bit in this space, if you check out the settings panel in Ubuntu compared to, say, the Windows XP control panel, you'll see that Gnome's settings panel is more usable. Mainly on account of having a single entry point, and the search bar on the top.
I think a lot of this is influenced by modern MacOS and iOS settings management (much like, to my recollection, Gnome 2 settings panels were very influenced by how Windows was doing things). It's not like it's 100% better, but for my usage it's felt nicer.
There are also a lot more work in this idea that there are many different ways to get to a settings pane. That way it's easier for people to get to a thing even if they have different ideas of where it "should" be
> Just like we wouldn't expect cars to be frozen in time in the 1950s, we shouldn't expect UI/UX to be either.
I think your example points to a peculiarity of UI/UX: cars have changed a lot since the 1950s, but their interface has remained surprisingly constant.
I think there is a point to be made that an interface can reach a point at which it cannot be improved, or at least not without a whole paradigm change.
But even that is not true. Windows are now mechanized, with child locks. The ways to open and lock doors is different, both in the car and from afar. The entire center console now is different, to the point where Tesla has just a touch screen on many models. There are cup holders, EVs have fruncks and often are largely driven using 1 pedal, side mirrors are adjustable with motorized buttons, seat placement is totally different and often a setting that can be memorized by the car, stick shifts and clutches are largely gone, the wheel inner shapes are different and often contain buttons, starting/stopping the car is usually a button, etc etc.
If you’re focused simply on the steering wheel itself that’s like saying there’s still a mouse and keyboard. Yes, that’s true — and even that will likely be disrupted over time. But everything else has changed.
Why are designers so different from the rest of us I wonder? They value minimalism above all else, with little debate, but everyone else has a lot wider of a range of preferences it seems like.
I imagine that its a constant refinement between utility and minimising distraction. They end up skirting this fine line because they live the details, much like how anyone can be distracted or obsess over miniature details when you have hyperfocus on a subject.
Every screenshot in this blog post showcases dated design paradigms. Flat UI was popularized around the release of Windows 10 in 2015. When I go through dribbble I see a lot of mediocre and copycat design. Design is about more than copying what Apple is doing. You're not going to get style from fat guys with ponytails.
Sort of. It largely was a copy of Apple, unfortunately. However I think it at least pushed the bar of what might be possible with Linux, and they're no longer around [1]. I'm hoping someone can come and give real high quality work to the FOSS community and take on a wider perspective. They had to basically do their own thing instead of pushing GNOME/KDE along, which may have to be unfortunately the case. It would be better if we could leverage the existing code bases rather than starting from scratch, but there maybe enough major things that need to change and enough resistance from the existing communities to allow for that to happen.
I love ElementaryOS, it's great, everything just works, I didn't have to tweak a single thing or mess with drivers earlier this year when I installed it on a new laptop that even Mint was having issues with.
yep, If you have troublesome hardware then I find the fastest solution is to just cycle through the top 10 distros to see if it works on any of them. If it does then great, you can either stop there or use it as a "guide" for how to get your favorite distro working.
If you're Apple and you make your desktop more attractive and pleasant you drive sales and market share. If you're redhat and you resource that you drive market share, to Ubuntu, who I believe still have a policy of never paying for development except for Ubuntu things, eg their failed desktop nobody else would use, Mir, bzr, etc.
Is that still the case? It would be a huge disincentive for other distros to contribute to the commons when ubuntu just parasite from it to a big market share.
>If you're redhat and you resource that you drive market share, to Ubuntu, who I believe still have a policy of never paying for development except for Ubuntu things, eg their failed desktop nobody else would use, Mir, bzr, etc.
Fact check, Gnome was filled of memory leaks and performance issues until some competent Canonical developer started working back on GNOME and fixing them.
So while Ubunut was not using GNOME the RH could have safely put their money into GNOME and it would not have benefited Canonical but the reality is that Canonical had to pay competent people to fix GNOME bugs, but probably Canonical can't change the desinger dictator so they usewd for a while a fixed theme and not the shity GNOME default.
I disconnected myself from Linux news so I don't know what drama happened in latest 2-3 years.
Who? When? What? They hired Henstridge to work on nothing to do with gnome? Redhat hired a bunch of core gnome devs to work on gnome? No? Happy to find out I'm wrong if there are facts involved...
Are you new to GNOME? this is a few years old when Canonical dropped Unity.
What was happening was that each GNOME release fixed some memory leaks but create a few new ones, the lag was terrible and when Canonical moved back to GNOME a Canonical developer started fixing stuff, GNOME devs were blaming the hardware for the bugs or were busy with removing features.
https://www.omgubuntu.co.uk/2019/10/ubuntu-improves-gnome-sh...
you can google the dev "Daniel Van Vugt" and check his work on GNOME, or you can google "GNOME shell memory leak" , as I said I stopped following Linux stuff (I am still a Linux users) and I have no idea what happened in recent years except the major things like GNOME's reset triggering a new fracture in it's community.
Anway, Canonical was not using GNOME so RH did not avoided paying for better developers because Canonical would benefit. Later when Canonical decided to use GNOME they fixed the major performance issues and memory leaks and put back some of the features the users wanted but designers refused to provide.
You may want to ask yourself why Red Hat despite having a lot more money and investing some of it in desktop Linux still has a fraction of the market share of Ubuntu. They are in a great position to dominate that market.
Instead we get a very rapid iteration with a 6 month release cycle that continually pulls in new tech prior to it actually being ready while it still has massive issues with end user experience including but certainly not limited to gnome 3, pulseaudio, gnome 3, wayland by default in 2016 which is now 6 years later supposedly almost fully ready for prime time.
My experience running Fedora for 7 years is that each release was a chance to play with new tech and fix new broken things. In place upgrades were also extremely dicey making a fresh install of the new version necessary every 6-9 months.
This is great for a toy less great great for something you intend to use. I'm sure current proponents say its great now but they literally have been saying the same thing forever.
I don't believe that Canonical or Red Hat would make any money from having a better GUI. Most of their (paying) customers are probably just running servers, or maybe running some simple dumb terminals for nontechnical employees (like a Point-of-Sale where the user may open a web browser or something).
> Microsoft was stupid for doing it. I think Apple is stupid for doing it
Microsoft isn't actually responsible for this nonsense. Metro did get rid of bevels, but it didn't get rid of obvious buttons: they simply turned into trivial colored rectangles.
I'm not entirely sure who "refined" it, but Microsoft did eventually end up copying a bad iteration of their own good idea.
I don't understand why modern toolbar icons are basically abstract shapes represented by lines. It's 2022, we have 32 bit colors, but toolbar icons have less color than back 30 years ago in Windows 3.1.
Old win 3.1 toolbars had tiny 16×16px icons, that could be quite colorful without being overly distracting even on a lower-resolution screen. With the new emphasis on "touch" readiness combined with higher screen resolutions we get bigger icons but simpler, black-and-white shapes, which helps tell apart simple toolbar functions from icons that might represent all sorts of other things within an application.
> I don't understand why modern toolbar icons are basically abstract shapes represented by lines
Much, much easier to style based on whatever the surroundings are. Also easier to maintain a good look if you switch to a completely different theme, and for third party icons to mesh with the OS set of icons (only so many ways you can mess up the sillouette of the shape).
Oh, and they scale to basically infinite proportions without looking weird, which cannot be said for color vector icons.
The reason is because colorful designs were ugly AF in virtually all but the very best (or native) applications so users developed an allergic reaction to them. Minimal design felt fresh and it’s harder to fuck it up...sadly it’s also harder to tell icons apart
For what it's worth, I recently discovered that I can move windows on GNOME by holding down the Windows/super key and dragging. It's a small thing but it's actually quite nice.
the ones for resizing and moving are quite handy indeed. Learn them. Sometimes windows have bugs and get bizarrely huge and this is a way to get them back down to a reasonable size
For me, what you're referring to is one of the reasons I don't like to use Windows as a desktop OS (because you need to hunt for these relatively small target areas to organise multiple windows). The alternative which I greatly prefer is outlined in the other responses.
In the past, I used to disable title bars entirely even on full-sized monitors. These days it's not so easy to do that, though.
This is one of my pet peeves, too. I shouldn't have to find some pixels of unused space on a title bar before clicking on it lest I bring down another menu or launch something. Microsoft programs seem to be enamored with the "search input box in the title bar" concept. Give me a magnifying glass, and drop down the input box or something. I want to be able to just grab the title bar and move the window.
The old button was good in the desktop context, but I can't get behind this point:
> The design even works very well on Linux phone formfactors.
The author must mean something very different when they say "works very well" than I do when I say that. As much as I want it to, nothing about GTK works well in a phone form factor, IME. I look forward to continued improvement that will make that statement incorrect.
I for one don't want the phone form factor to influence my desktop experience. They are two completely different workflows that have conflicting needs IMO.
The main influence so far has been enabling smaller window sizes for gtk+3/libhandy apps, which is good for all users especially those on older, lower-res hardware. Hopefully libadwaita can get forked into something like a libhandy equivalent for gtk+4, that otherwise preserves sane defaults doesn't enforce their silly "flat" theme choices.
>The main influence so far has been enabling smaller window sizes for gtk+3/libhandy apps
I don't think so, touch targets are a lot bigger. Using the default theme for both a KDE App with equivalent functionality will take a fair bit less space than a similar gnome app. Of course I think plasma mobile uses a theme that makes the touch targets bigger...
KDE also manages to get a lot more functionality into their similarily sized windows. Take a look at this page showing comparisons:
Agreed. The major sin of modern UI/UX is the desire to create a one-size-fits-all experience that works for both touch devices and desktops, when in reality the work styles of touch devices and desktops are very different. Unfortunately Windows (since Windows 8), macOS (since Big Sur), and GNOME (since GNOME 3) have sought (and continue to seek) these unified designs that work okay on touch devices but are a downgrade on desktops. The desktop reached its zenith in the late 2000s with Windows 7, Mac OS X Snow Leopard, GNOME 2, and KDE 3, and today's desktops are a downgrade from these (though KDE Plasma is nice and is an improvement over KDE 3).
I'll go as far as to say that the desktop experience hasn't received much love by major software companies; since the late 2000s the money has gone toward smartphones, tablets, and the Web. Since those platforms get the attention, the desktop is increasingly getting populated with ports of smartphone and Web apps; hence, Windows Metro/UWP, Catalyst, Electron, and the like.
> The only issue with it is that font rendering looks horrific, but that might just be my machine.
This is because GTK4 enables pixel/scaling-independent fractional vertical positioning, even with hinting enabled. There's a long (somewhat ongoing) discussion at https://gitlab.gnome.org/GNOME/gtk/-/issues/3787, though I haven't followed the last few months of discussion.
Even though GTK4 aims to achieve scale-independent layout, the 4 horizontal/vertical positions still produce a bit of judder, and fonts do not scale smoothly (even with bilinear interpolation) with hinting enabled, and (unless fixed) there are rendering issues due to failing to clear the texture atlas properly: https://gitlab.gnome.org/GNOME/gtk/-/issues/4322
Interestingly there's a proposal to switch GTK4 fonts to SDF-style rendering. This is somewhat like what Qt Quick 2 implemented already (and KDE turns off and reverts to FreeType rendering, to make QML apps mimic Qt Widgets font rendering more): https://blogs.gnome.org/chergert/2022/03/20/rendering-text-w... However, I looked at https://github.com/behdad/glyphy and it seems to implement vector-based SDFs, instead of earlier texture-based SDF/MSDFs used by Valve games and Qt Quick.
“Scale-independent layout” (layout that ignores pixel aliasing) really requires PPI over ~200, that is, more than most desktop monitors provide. We’re still just not there.
You could do text hinting (snapping to the (sub-)pixel grid) after layout, based on some kind of auto-hinting heuristics. Arguably, this is needed anyway because text gets "laid out" all the time as part of advanced typesetting, including all sorts of complex microtypography that doesn't really play well with the old-fashioned "bitmap font" type of hinting.
The maintainer responded that "[c]hanges to the rounding behavior of glyph positions really belong into pango, though". I understand, but I don't know whether he's suggesting fractional layout but integer-rounded rendering, or integer-rounded line heights and layout and rendering. And I don't know how to change Pango, and lost interest in digging further.
It’s going to be a bloody mess for a long time, because the choices for how to handle resolution independence are all inherently filled with compromise.
With font rendering, I think there is hope. Horizontal subpixel positioning with vertical hinting seems like a good tradeoff to me. Grid fitting vertically is not too jarring, and grid fitting horizontally to subpixels instead of pixels looks pretty good too, on low resolution displays.
But it really is a son of a bitch elsewhere. For example, if you want a crisp 1px border on 96 dpi, you could specify it to be a 1px border at 96 dpi… but then what happens at 1.5x or 1.75x scale? From a purely logical position, the blurry line is actually the general case, and the integer scale case is actually an edge case. That desktop UIs aren’t blurry basically always is because we define them in terms of 96 DPI displays.
It gets worse for APIs, because APIs that want to present a resolution-independent world will cause difficult to tolerate bugs. The VS Code terminal will often be blurry at non-integer scales because it is using HTML canvas. If the canvas width or height is not a multiple of the size of a CSS pixel, it will cause the internal buffer to be scaled horridly. The fix might be a new API that reveals true coordinates… very, very nasty.
Apple’s solution was extreme: dump all font hacks, always render apps at 2x, then scale the whole framebuffer for different scale factors. It’s somewhat blurry, but avoids many ugly pitfalls in the common case, and makes apps simpler.
Unfortunately, the rest of the world is just stuck with really bad scaling and more often blurring on 96 DPI displays, the worst of both worlds.
> For example, if you want a crisp 1px border on 96 dpi, you could specify it to be a 1px border at 96 dpi… but then what happens at 1.5x or 1.75x scale?
The border width should get snapped to the physical (sub-)pixel resolution as part of rendering. Typically, this should come with changes in contrast too, such that if a line is forced to become thinner it also gets drawn with higher contrast wrt. the surroundings, and vice versa. All of this stuff can be made to work.
Also, if you are forced to render a canvas at a resampled resolution because existing APIs give you no other choice, at least do it right using a proper Lanczos-style resampling. This might end up with a quaint "watercolor" effect but guess what, that's a lot better than a blurry, eye-fatiguing mess.
We’ve tolerated a great degree of complexity just to make fonts look good at 96 DPI. Looks like we’re able to tolerate a bit more complexity to enable GPU rendering. However, many years into having high DPI displays, it’s not obvious people are willing to take the complexity to make low DPI and high DPI screens look good simultaneously.
The thing is, with fonts, we already bear the burden of font rendering being complex because that was needed for 96 DPI displays. But, we won’t need much of this magic or complexity when a vast majority of people are using higher DPI displays, because at >200 PPI the difference between a blurry line and a sharp line is basically nil. That is obvious enough on Apple platforms, where many are perfectly happy with the scaling even though it uses 2x as a base for all scales.
I think the future is simply pain. People want cleaner graphics pipelines, and only high DPI displays will get them anywhere.
The font rasterizer is a massive hack in modern UIs. Subpixel rendering is a serious pain in the ass. When you render text using subpixel rendering, you render the actual vectors at 3x the spatial resolution. But, not simply as if the vectors were 3x wider, because that would look too sharp: it needs to render as if there was 3x as many pixels, which is different.
Then there’s compositing. Normal layers can be composited using alpha blending, assuming some sane format like premultiplied alpha RGBA. But not subpixel rendered text, because alpha blending the components will fuck up the subpixel rendering.
And it goes on, because if you want to handle text like everything else, you need special cases for it to look right. Rotation? Need to render the vectors rotated; can’t rotate in raster. If you need to render to a surface then transform that surface, you’re SOL; it can’t go to rasters until the end.
Normal surfaces can also be rendered at subpixel positions, and of course this does not work for surfaces containing text, because again, it will destroy the subpixel rendering.
OK. So you can get rid of the subpixel rendering and render slightly blurrier glyphs instead. (R.I.P. anyone trying to tell hanzi/kanji apart.) It’s still going to murder legibility if you move it over by a subpixel value because text is already on the edge of readability at 96 DPI.
I haven’t considered gamma correction, hinting, blending different colors, different blending modes, GPU acceleration, etc. because I simply don’t have the brain power to try to reconcile it all. It’s a nightmare.
We already did some of this for text. Which is a herculean effort. We use a freakin virtual machine to power font hinting, and ugly, complex, slow special casing at many layers of already ridiculously complex vector graphics stacks (I mean if you disagree with that assessment, you may just be smarter than I am, but I have serious trouble following the Skia codebase and I doubt Cairo is really that much better.) And speaking of which, there only really seems to be a handful of them out there: there’s Skia, used by most web browsers; Cairo, used by GTK; Direct2D, in Windows; Whatever modern macOS uses that isn’t QuickDraw anymore; and I guess there’s Mozilla’s pathfinder, a promising Rust-based vector graphics engine that was built as part of Servo and seemingly mostly abandoned, much to the world’s detriment. This work is hard. It can be done, but it’s not something I think a single engineer can do, if you want to build one that competes with the big boys even disregarding a few things like performance. I’d love to be wrong, but I have a sinking feeling I’m not.
Even text isn’t done being overcomplicated. As nyanpasu has mentioned above, some software have started implementing SDFs for font scaling. We do this because text legibility is really that important, whereas a line in the UI being slightly blurry for users on older screens is really just not that important. Some languages flat out can’t be read with crappy font rendering, and any of them will give you eyestrain if it’s ugly enough. As much as it sucks, a blurry border on a button doesn’t have an accessibility issue. And rendering at 1x and making the compositor upscale is not a great solution either because again, it’s already hard enough to read text in some languages; the added blurriness of scaling text and ruining subpixels is basically intolerable.
These hacks aren’t free, and with high DPI displays, they’re not needed. There’s a reason Apple did what they did.
OK, but there's clearly an existence proof, and it ran fine on 32 bit machines with slow processors (or even embedded CPUs in the 80's!) way before all the piled hacks you are describing were invented.
As I understand it, all that's needed is a vector renderer, and you keep everything (even text) in vector format as long as possible. RGBA then becomes a special case, as it must be for any DPI independent rendering pipeline.
Trying to compose rendered vectors using pixel based operations is madness, so... don't?
That means you can't have a bitmap-based compositor. So what? GPU's are great at rendering vectors. Composite those instead of bitmaps.
Or, just don't composite at all. A decade later, Linux desktop compositors are still an ergonomic regression vs. existing display drivers with vsync and double buffering support.
> OK, but there's clearly an existence proof, and it ran fine on 32 bit machines with slow processors (or even embedded CPUs in the 80's!) way before all the piled hacks you are describing were invented.
Yes. Driving ~1024x768 framebuffers, on single core processors, with far less demanding workloads, but still, yes. (They still badly needed good glyph caching to accomplish this.) (I’m assuming a Windows XP-tier machine since that was the era most people started using ClearType/subpixel rendering.)
(Single core processors are obviously slower than multicore processors, all else equals, but exploiting multi-core processors effectively is harder and often leads to code that is at least a bit slower in the single-core case…)
> As I understand it, all that's needed is a vector renderer, and you keep everything (even text) in vector format as long as possible. RGBA then becomes a special case, as it must be for any DPI independent rendering pipeline.
I don’t want to sound like I’m being patronizing, but I get the feeling that you may not be grasping the problem.
We can’t just use text rendering logic to power other vector graphics. For many reasons. Text is not just rendered like vectors, as that would simply be too blurry at 96 DPI. Old computers used bitmap fonts or aggressive hinting, and newer computers use anti-aliasing, often with subpixel anti-aliasing. Doing that with every line on screen isn’t feasible even if you wanted to write the code. Here’s an attempt to enumerate just the obvious reasons why:
- It’s slow. Yes, old 32 bit computers could do it, yadda yadda ya. But they did it for text. At the glyph level. And then cached it. They were most certainly not rendering anything near the entire size of the framebuffer at once.
- It’s difficult to GPU—accelerate. GPUs can do vector graphics and alpha blending fast, but subpixel rendering as its done with text is not something that can be done using typical GPU rendering paths. It could still be made to exploit GPUs, but it requires more work and is slower.
- Fonts achieve better crispness on lower DPI displays using hinting VMs. Without them, many glyphs would be quite blurry. Hinting VMs allow typographers making font outlines to make specific decisions about when and how vectors should be adjusted to look good on raster displays. In case it isn’t obvious, the problem here is that doing this for every line on the screen requires you to write special casing for every line on the screen. Maybe you could come up with a general rule that makes everything look good and doesn’t wind up with uneven looking margins or outlines ever (you really can’t, but…) — you have to run this logic for every line. That’s an increase in complexity.
- Glyphs only need to care about their relationships with eachother. UI elements on screen have arbitrary concerns. They have relationships with other things on screen; they line up with other shapes and the whitespace between them is significant. Glyphs only care about other glyphs horizontally adjacent to them (or vertically in some scripts, perhaps) but other UI elements care about their relationship with potentially any neighboring UI elements.
- UI rendering code does not exist in a vacuum. At some point, apps will need to do something that requires them to know the size of something on screen either in physical or logical dimensions. Normally, this isn’t a problem, but if all vector rendering was as complex as text, it would absolutely be an issue. The naive way of handling it would seem correct in many cases, but it would be wrong in many others, just like how old APIs that expose pixels instead of logical units tend to lead to apps with subtle scaling issues.
> Trying to compose rendered vectors using pixel based operations is madness, so... don't?
Yes, of course.
Except that, too, is hard. Think about web browsers: they need to support arbitrarily large layers for compositi...
The underlying logic for rendering "hinted" line borders and UI widgets is a lot simpler than for hinting arbitrary text. It's a matter of snapping a few key control points to the pixel grid, and making sure that key line widths take up integer numbers of pixels. Much of the complexity you point out only arises because we now insist on having physically sized rendering for "mixed-DPI" graphics, like a single window spanning both a low- and a high-resolution display. That's not necessarily a very sensible goal, and it's not something that would've been insisted on back when achieving "pixel perfect" rendering was in fact a major concern, regardless of display resolution.
A similar concern is the demand for arbitrary subpixel positioning of screen content, that basically only matters in the context of on-screen animations. Nobody really cares if an animation looks blurry, but it's somewhat more important for static content to look right. Trying to have one's cake and eat it too will always be harder than just focusing on what's actually important for good UX.
> The underlying logic for rendering "hinted" line borders and UI widgets is a lot simpler than for hinting arbitrary text. It's a matter of snapping a few key control points to the pixel grid, and making sure that key line widths take up integer numbers of pixels.
This is exactly what I was “hinting” at when I said coming up with a universal function that would work for anything. You can’t just snap some/all things to a pixel grid; it would look absolutely terrible because it would make lines and whitespace uneven. Even font autohinting, which does exist, is more sophisticated than just aligning key control points to a pixel grid.
> Much of the complexity you point out only arises because we now insist on having physically sized rendering for "mixed-DPI" graphics, like a single window spanning both a low- and a high-resolution display. That's not necessarily a very sensible goal, and it's not something that would've been insisted on back when achieving "pixel perfect" rendering was in fact a major concern, regardless of display resolution.
It’s not. Even under Wayland, which can achieve this, the application would only render one surface at a specific resolution at any given time. Nothing I’ve been talking about is related to being able to split a window across different DPI screens.
> A similar concern is the demand for arbitrary subpixel positioning of screen content, that basically only matters in the context of on-screen animations. Nobody really cares if an animation looks blurry, but it's somewhat more important for static content to look right. Trying to have one's cake and eat it too will always be harder than just focusing on what's actually important for good UX.
If you scale a UI that was designed for 96 DPI pixels to a screen that is around 160 DPI, you already have subpixels. If you then attempt to snap to a pixel grid instead of rendering elements at subpixel positions, then you have uneven, ugly looking UI elements.
This unevenness is arguably more tolerable for text than it is for UI elements, but Microsoft actually took the approach of not having it for text regardless; to make text look cleaner, text uses more aggressive gridfitting in Microsoft UIs, resulting in each glyph being gridfit. This is exactly why old Windows UI scaling lead to cut off text and other text oddities; it’s because the grid fitting lead to text that had different logical widths when rendered at different resolutions!
You can’t just wish away subpixels. Numbers that just happen to be whole numbers are the real edge cases in a world with arbitrary scale factors.
Are we talking about single-pixel rounding errors, or something else? The former are already practically undetectable at 1080p, and nearly-so at 768p. Given a high standard of "pixel-perfect" rendering, there's basically zero reason to push resolution any higher!
Of course one can even make pure subpixel-based rendering (no fitting-to-pixels at all) look correct, by starting either from pure vectors or from a higher-resolution raster and then using a Lanczos-style filter to preserve perceived sharpness near the resolution limit of the display. This gets us as near as practicable to something that's almost "pixel perfect", without distorting spatial positions to make them precisely fit a pixel grid.
> some software have started implementing SDFs for font scaling
My "wip/chergert/glyphy" branch of GTK 4 does rendering using https://github.com/behdad/glyphy which uses fields to create encoded arc lists and are uploaded to the GPU in texture atlases. The shaders then use that data to render the glyph at any scale/offset.
Some work is still needed to land this in GTK 4, particularly around path simplification (mostly done) and slight hinting (probably will land in harfbuzz).
Regarding slight hinting... currently GTK4 hints glyphs (distorting glyphs by quantizing vertical positioning) then renders them at fractional vertical positions (resulting in blurry horizontal lines). This is the worst of both worlds, achieving neither the scale-independent rendering of unhinted glyphs with fractional positioning, nor the sharpness of hinted glyphs with integer vertical positions. What is your plan for hinting and positioning?
I’ve come to the same conclusion. Making hi(-ish)-DPI work would be possible with the right APIs. But it’s virtually impossible to also make it work for traditional low-DPI displays at the same time. The departure from pixel-art icons to vector icons alone has already degraded the low-DPI experience substantially. It doesn’t help that developers and designers tend to not use low-DPI displays anymore. But many regular users will, because it continues to be the cheaper option, also in GPU terms for gamers. Full-HD monitors won’t be going away anytime soon. Meanwhile, the mid-DPI space (e.g. 1440p) is in an uncanny valley, often requiring fractional scaling (more than 100%, less than 200%) unless you have excellent eyesight.
I really don't understand what was wrong with the X11 approach. I had a high DPI monitor in 2001. I typed the DPI into /etc/XFree86.conf or whatever, and it all Just Worked (TM).
Edit: I think modern web browsers implement ctrl-+ and ctrl-- the same way, except X11 apps kept separate directories of icons rendered for different DPIs, because 1GHz single core still seemed luxurious. Web browsers scale the bitmaps using some reasonable algorithm. Other than that, arbitrary zooms work with zero blur.
For what it's worth, PostScript also got this right back in the 80s.
Well, how much it Just Worked really depended on what you were doing and how. At a point, it all stopped Just Work-ing.
Old old X11 apps used X11 drawing commands. These sucked, and nobody liked them. If you think you liked them, please show me your clean Xlib codebases for proof :P As far as I can recall, these still dealt with pixels, so clients were on the hook for dealing with scaling, though in theory it wasn’t too bad. They don’t really solve any of the pixel perfection issues that I am discussing, though.
More modern apps (— early 2000s should be “modern” enough by X11 standards, but my memory is foggy and I’m too young to really be an expert here —) instead blit pixmaps sent over shmem, defeating both network transparency and the inherent “vector” nature of many of the old drawing commands. X11 didn’t really handle anything other than knowing the DPI (… that you told it …)
At that point, up to GTK+2 and Qt 3, which is to say, even quite a while After 2001, you had at best limited scalability. If you had your CRT cranked up to around 150 PPI, everything was OK — you could get text scaling and the disparity wasn’t so bad. However, GTK+2 and Qt 3, and their ancestors, were not built with DPI independence. At best, they could adjust vector text sizes according to DPI and scaling preferences. Again, this looks OK for nvidia-xsettings and a modest PPI increase, but it’s absolutely terrible for anything more. Margins don’t adjust, padding doesn’t adjust, icon sizes don’t adjust, nothing. There’s no blur or jankiness because there’s no true scaling.
(Just as a quick note, this is literally the reality of GIMP today, right now. It’s still on GTK+2, and so the best you can get is text scaling, or flat out nothing.)
And that’s to say nothing about what happens if the DPI changes, which requires you to effectively restart everything. And that also doesn’t help people who have two different displays with different PPIs. The ever common case of the high DPI laptop with a cheap LCD plugged in. Have fun with that crap.
Modern Linux can do better. The Wayland protocol comes with DPI negotiation that allows naive clients to get blurry upscaling, “simple” clients to pick a set of scales they can support and have the server adjust for whatever one they decide to render to, and advanced clients can render at any DPI, in response to the server advertising what DPI the current display is. With atomicity of configuration changes that allows a properly written client and server to never render an “intermediate” incorrect frame, and scaling that ensures that surfaces across multiple displays display at the correct DPI on all of them (albeit with either upscaling or downscaling on some of them.)
And that still does absolutely nothing to solve the fact that pixel perfect layouts are inherently not perfectly “scalable.” Because truly scaling some vector drawing commands that just happen to be pixel perfect at one resolution will not always result in pixel perfect rendering in another. You would need code that compensates for the scaling. Old X11 apps did not do this.
Of course I could be completely wrong and old X11 could’ve had some amazing DPI scaling technology that I somehow missed for decades. I don’t think so. My memory is that when I finally hooked up a high DPI display to Linux, I experienced tiny Skype, Pidgin (GAIM) with tiny icons and large text, and nvidia-xsettings with weird hinting/kerning. I’d like to move on from that kind of scaling.
P.S.: PostScript doesn’t do anything magic either. Everyone’s graphics systems were PostScript inspired, and yet macOS wound up with the same DPI scaling conundrums as anyone else. Most people wouldn’t tolerate desktop apps as blurry as a PDF at 96 DPI.
> More modern apps (— early 2000s should be “modern” enough by X11 standards, but my memory is foggy and I’m too young to really be an expert here —) instead blit pixmaps sent over shmem, defeating both network transparency and the inherent “vector” nature of many of the old drawing commands. X11 didn’t really handle anything other than knowing the DPI (… that you told it …)
This is entirely untrue. Did you even try ? Qt even at version 6 still supports rendering through X11 commands, and afaik does that by default when ssh'ing on Debian distros.
And I can set my Xft.dpi to, say, 144, ssh -X somewhere and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will so far all use the correct local DPI. Which other remote UI technology supports that ?
> This is entirely untrue. Did you even try ? Qt even at version 6 still supports rendering through X11 commands, and afaik does that by default when ssh'ing on Debian distros.
When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network. Not all X11 clients continue to work properly if XShm can’t be established, and hardware acceleration is basically a no-go despite OpenGL/glx theoretically being a client/server ordeal.
> And I can set my Xft.dpi to, say, 144, ssh -X somewhere and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will so far all use the correct local DPI. Which other remote UI technology supports that ?
Waypipe. Unlike X11, Wayland doesn’t start with network transparency as a principle, but it is completely possible to proxy it. Other than not being able to get a hardware-accelerated OpenGL or Vulkan context, a client connected over Waypipe is very similar to a local client. The proxy can handle things like serializing data sent over shared memory, so UI toolkits and other client code doesn’t need to behave any differently over the network; it just needs to use synchronization primitives correctly.
> When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network.
no, this is false. Here's a video of dolphin, KDE's Qt 5 file manager, run over ssh on another computer: does that look like it's blitting pixmaps over the network ?
When checking nload, this uses ~8 megabyte/second, I can let you imagine how much it would be to blit a constantly scrolling UI at 140 fps - I can assure you that even gigabit ethernet does not cut it unless compressing a lot :-)
Honestly, I regret arguing on this point. There’s no reason for me to continue on it, since it has nothing to do with what I was really trying to discuss about X11 apps. Still, 8 MiB/s is a shit ton of data, and given that it is screen data I’m sure it would zlib compress very well. Is it shipping the whole app as one pixmap? I am not really making that claim, though I actually thought they dropped XRender based QPainter somewhere in Qt 4, but it’s not plainly obvious that they did. I’ll concede on that. It’s still mostly shipping pixmaps either way, especially depending on how things nest, because the text is absolutely all pixmaps, but it would be more efficient by a decent bit than shipping the entire app as pixmaps due to being able to do compositing on-server.
It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.
it is minuscule, and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less. And it's while running a moderately image-heavy app with most likely room for optimization. One I often use is pavucontrol-qt: this one gives me less than 1MiB/s of network traffic when resizing it madly.
> It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.
icons are scaled, images are scaled, text is scaled... what is missing ?
Also, regarding zlib: I took a screenshot of this window and compressed it as png (which uses zlib if I'm not mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So more than twice as much as what X11 manages (and that is raw X11, IIRC there are X11 protocol extensions which also pass the X11 messages through gz, but I've never felt the need for that as things are already perfectly fast).
If you can show me any video-compression-based implementation that allows me to get this close to zero latency with zero image degradation (especially for text, you really don't want subpixel font AA to be video-compressed) and as little network overhead as what Qt gives over X11 I'll be super happy, but I really think it is unrealistic.
> it is minuscule, and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less.
If 70% of the pixels are the same shade of gray, that’s not impressive at all. If you are serializing image data and storing it over the network, you can do better than uncompressed with virtually no CPU load increase. Even moreso if you’re doing multiple correlated frames.
> when I set Xft.dpi to 144 on my machine and run the same thing over ssh I see this: https://i.imgur.com/JQhEcvG.png
icons are scaled, images are scaled, text is scaled... what is missing ?
Nothing.
That scaling is done by Qt, and has all of the aforementioned issues with regards to scale factor. That’s why we’re talking about X11; there is no “X11” way of handling scaling. X11 clients are responsible to scale things. Even events do not get their coordinate spaces scaled, either.
The point of this thread is not that you can’t scale UIs. It is that GTK+4 looks bad on low DPI monitors because it has stopped attempting to do pixel perfect UI and instead uses truly scalable layout and rendering. In the truly scalable world, 96 DPI is as blurry as 200+, only you don’t see it when there are more pixels.
That said, Qt has plenty of UI scaling bugs.
> Also, regarding zlib: I took a screenshot of this window and compressed it as png (which uses zlib if I'm not mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So more than twice as much as what X11 manages (and that is raw X11, IIRC there are X11 protocol extensions which also pass the X11 messages through gz, but I've never felt the need for that as things are already perfectly fast).
Yeah, because even raw X11 with pixmaps won’t redraw the whole screen at once. It will use dirty rects. When scrolling this could still be a substantial amount of data, but nonetheless.
As I suspected, as far as I can ascertain, it really is just shipping pixmaps. 8 MiB/s sounds very consistent with what bug reports are saying;
This was changed in Qt 4.8, exactly like I remember it. But what I didn’t know was that XRender rendering was reintroduced in 5.10, because of this exact problem.
(Just to be clear, that means you get efficient SSH for most Qt apps, which have native mode enabled, from Qt 4.0 to 4.8, then 5.10 onward. A substantial slice of history to be sure, but more limited than it seems people think.)
If you’re on 5.10+, you should be able to get dramatically better performance with `-graphicssystem native`
> If you can show me any video-compression-based implementation that allows me to get this close to zero latency with zero image degradation (especially for text, you really don't want subpixel font AA to be video-compressed) and as little network overhead as what Qt gives over X11 I'll be super happy, but I really think it is unrealistic.
What can do better? Yes, it’s true, compressing text with lossy algorithms could pose a prob...
> Besides, at 8 MiB/s, lossless video codecs are pretty doable for fullsceen UI. Modern VNC implementations (Ultra, Tiger, etc.) make a joke of this figure and can still get good text quality.
Here's how tigervnc looks on the exact same situation:
Sure, it uses less bandwidth (between 2 and 2.5 MiB for the busy part of this video) but it is also full of artifacts (https://i.imgur.com/4QrV9xl.png), super slow compared to X11 and does not respect my local settings. no thanks !
True! VNC is not ideal because it's pretty old by now. Chrome Remote Desktop would've been a better example, and even that is behind what can be done, as I believe it still uses VP8. It's possible even a lossless codec like ffv1 could be plausible in the window of 8 MiB/s, but I'm not sure it's necessary, as even old h264 does a pretty convincing job at very low bitrates.
Here's a snippet of my 2256x1504 screen, uncompressed:
...But they are not really noticeable in motion, and it clears up quickly.
I don't have a high framerate, high DPI display to test, but I'm guessing most people will only strongly care about one or the other since displays that do both are pretty expensive.
And yeah, chroma subsampling on subpixel rendering should impact legibility, but in practice it's difficult for me to tell any difference.
I've played around for a bit and I don't go above 1 MiB/s so far. I probably would need to play a video for that.
The only place where the text looks remotely smudged to me is in the low contrast bits in the header. It’s very difficult for me to tell the difference otherwise, especially considering that it’s high DPI.
And h264 is old, and I’m using software x264 with fairly modest settings. More modern general video codecs like h265, VP9, perhaps even AV1 can eek out slightly better fidelity at similar bitrates, at the cost of higher complexity. (But if it can be hardware accelerated at both ends, it basically doesn’t matter.)
And these codecs are designed for general video content… it would be instructive to see exactly what kind of performance could be achieved if using lossless codecs or codecs designed for screen capture like ffv1 or TSC2.
It would be… but honestly, there’s no point, because all I was trying to illustrate is that I sincerely doubt 8 MiB/s is the best that can ever be done for a decent desktop experience. Judging by Qt issue reports, it’s worse than what Qt used to be able to accomplish. If you really like your X11 setup, there’s no reason to change it, because it isn’t going to become unusable any time soon. Even if you switch to Wayland in the future, you should still be able to use `ssh -X` with Xwayland as if nothing ever really changed.
This is all a serious tangent. The actual point was that again, X11 doesn’t have any built-in scaling. All along, it was Qt 4+, GTK 3+, and other X11 clients that have been handling all of the details. And traditionally, it wasn’t good. And even contemporarily, it still has issues. Beckoning to the “way X11 did it” makes no sense because 1. X11 as a protocol or server never did anything 2. Even then, historically toolkits have had a lot of trouble dealing with it. The fact that you set the DPI for Xft specifically, which is just a font rendering library, hints at the reality: what oldschool X11 “scaling” amounted to in the 2000s was changing how font sizes were calculated. Modern toolkits just read this value to infer the setting, and it still isn’t good enough for many modern setups that Linux desktops want to support.
> I think modern web browsers implement ctrl-+ and ctrl-- the same way, except X11 apps kept separate directories of icons rendered for different DPIs, because 1GHz single core still seemed luxurious. Web browsers scale the bitmaps using some reasonable algorithm. Other than that, arbitrary zooms work with zero blur.
Web browsers scale bitmats if no other version is available but you can provide different bitmaps for different pixel ratios to avoid any blurryness [0]. Resolution independence is one thing that the modern web stack gets right - even 1-pixel borders/lines and space between elements generally works as expected for different scales.
Of couse *mobile* browsers made the IMO stupid decision of only activating these scaling features when you add a special tag to your HTML header.
They should take note of Windows 11 and the fallout from new menu item style due to the font no longer scaling properly at DPI “100%”. Many reported it as a bug! But it’s per design in the new Segoe Variable file where hunting breaks down at “low” (i.e. normal, non-hi) DPI.
Which is why QtQuick controls always looked like absolute garbage.
And firefox degraded as well when webrender got enabled.
I'm not sure I follow the upstream reasoning, in either gtk/qt/firefox/chrome... I'm reading text all day. The UI is still built around 90%+ text, except in very few edge cases.
I'm using 4k monitors, and I'm still a minority. Despite this, at 4k, we're still several years away from the point where we can turn off hinting. Probably a decade away for universal support. A lot more if we include existing monitors.
Between 92 and 270 dpi text still looks bad without proper grid fitting. Under 120dpi we're talking about garbage-level quality. And between 250-300 the difference is still noticeable to make it worth it.
It looks like garbage because of poor rendering quality. There's no theoretical reason why a screen could not look quite sharp even at 768p, and literally perfect at 1080p; anything higher would then be pure overkill or at best catering to a tiny minority of users with superhuman eyesight. You don't even need hinting or fitting to a pixel grid for "correct" rendering, it's just generally easier that way. But you can't let the rendering itself blur stuff and waste screen resolution - you need a good resampling filter to preserve sharpness even at the highest spatial frequencies, and the typical bilinear/bicubic approach doesn't do that.
Non techies have been using flat design interfaces for like a decade now and the world hasn't ended. If you personally like another style, totally fine. But it's odd that programmers always think they know more about usability than people who study it for a living.
The problem isn't techies but non techies, unless you think only techies should be using Linux GUI...
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
There is a reason why Apple backpedaled on all that flat insanity for MacOS and iOS. Graphic designers and trendsetters usually know very little about usability, these are 2 completely different disciplines, and the Flat style was imposed by graphic designers, not UX people.
> But it's odd that programmers always think they know more about usability than people who study it for a living.
I’m sure it has something to do with them needing to justify their existence. No reason to have a designer if nothing has changed in the world of design. Programmers learn new languages (or go back to old ones), designers do the same with interface design principles.
Do non-techies have a choice, though? Given the lack of theming in many modern apps, its not like users have a choice between flat design and the designs of the 90s and 2000s. What about sticking to old versions? I can only use old versions of software for so long before it becomes infeasible for many reasons (security and interoperability being the biggest reasons), and even on Linux where users have a great deal of control, not all GUI software is themable.
It's not just programmers who complain about modern UI/UX trends. The Nielsen Norman Group, a UI/UX consulting group that was founded by HCI legends Don Norman and Jakob Nielsen, have written articles against the overuse of flat design (https://www.nngroup.com/articles/flat-design/).
I tend to see it from the opposite perspective. Physical looking buttons, borders, and always-visible controls were designs born from rigorous user testing in the 1980s and early 1990s. The push to flat design that really picked up steam around a decade ago did not have, as far as I can tell, the same level of testing, and was promoted largely by programmers who wanted designs that were easier to implement.
Platform developers were incentivized to go flat because it lowered the cost of development and development time if developers were using fewer, simpler custom assets. At this time, both Apple and Google were bragging about how many apps were on their stores, and how fast they were growing, and neither wanted to fall behind the other.
But admittedly, my perspective was that of a third-party developer. I have no direct knowledge of why Microsoft, Google, and Apple all embraced this trend, and I have only anecdotal evidence that it made things more difficult for novice users. There could be a treasure trove of research showing that flat is better, but I have never seen it presented.
To say that it is the pinnacle of design is a wide stretch give what they did to menus in all the apps. Obscure buttons and burger menus replaced menus..
The other nice thing about "the nice GTK button" is that it feels consistent enough with the current tab buttons styling in Firefox: https://imgur.com/a/OEKc4So . It also just feels better for direct manipulation (touch).
Is there any way to vote for keeping it? Does 'high contrast' mode possibly bring it back?
It seems like KDE and Plasma is the place where look and feel is constantly but incrementally refined; we've been saved from this flat design trend so far and things keep looking pleasant and modern and being usable. We know they care, and have great attention to details because that's documented weekly [1].
I find the Breeze theme really well done and its GTK port, Brise, is also very nice, to the point Gnome looks good in it.
There was just the KDE 4 era where I didn't like Oxygen at all (and indeed I used to change the theme to Fusion there) but that's over. KDE 3 was fine and KDE 5 is great. At this point, most things that are not Breeze don't look great to me now.
As for the customization and theme support, that's supported and it works well, they prove that it's nothing insurmountable too. KDE comes with themes that look like Windows 95, Motif, Adwaita, GTK 2 and other things and you can download more if you want.
I'd be curious to have a review of Breeze / KDE by Martijn.
Breeze is being ported to Qt 6, and from the screenshots I see (https://www.volkerkrause.eu/2022/01/15/kf6-continuous-integr..., unsure what others), there are no visual changes so far. Time will tell if they change Breeze's appearance further before/after Plasma 6's release (I didn't ask about KDE's current plans). One possibility is O2 (https://pinheiro-kde.blogspot.com/), a reworked theme by the author of KDE 4's Oxygen, though it's not very far into implementation yet.
That's because there's no Breeze theme for Qt 6, so it's using the builtin Fusion theme which is literal cow dung. If you port your theme to Qt 6, the app should look identical.
I do not use a theme. I think you have it the wrong way around. What's missing here is the Qt6 equivalent of KDE System Settings → Appearance, or configuration tool <http://qt5ct.sf.net>, and it's not my task as the end user to provide these, but the toolkit and desktop environment developers'.
You always use a theme with Qt or Gtk. On Plasma the default Qt and Gtk theme is Breeze, which has not been ported to Qt6 yet. ATM the only Qt Widgets-compatible themes I have on my system are "Fusion" and "Windows" (as in "Windows 95"), both of which look absolutely horrible. Fusion is the default, and it's what you currently see when you open a Qt 6 Widgets app (for instance, QBittorrent right now).
By the way, qt6ct exists <https://github.com/trialuser02/qt6ct>, and it's even in Arch's repositories right now. The main issue is that it's useless, because there are simply no Qt6 themes out there yet and KDE still does not support Qt6 so you have to force qt6ct manually.
GNOME 3 was a fiasco not because of GTK+ 3. It was a fiasco because they threw 12 years of work and UI/UX design in the rubbish bin instead of thinking of ways to improve on it. MATE now runs on GTK+ 3 and it's leaps and bounds better in terms of UX compared with GNOME > 3. Sure, GNOME now has all the eyecandy and stuff, but it still sucks hard compared to GNOME 2. GNOME 2 was the pinnacle of UX IMHO, it was a novel design that really showed that you could innovate without copying others, that there was a third possible way that was not either a Dock or a start menu. All wasted, I suppose.
How's KDE/Plasma with touch these days? I'm running GNOME on my Surface right now because it does pretty well with both Desktop and Tablet modes, but I'm pretty unhappy with the at times patronizing philosophy behind the project.
I have a pine-phone and the virtual keyboard just refuses to pop up for some apps (like firefox!!). I keep looking in the settings for "force virtual keyboard on" or something but can't find it.
It indeed works now. Firefox was unusable on Plasma Mobile in 2020, it now mostly works on an updated Pinephone Pro (can't click on those popups when you try to install an extension, but the virtual keyboard shows up and seems to work ok).
Turning scaling down to 1.8 (default 2.0 on Manjaro/Plasma) or lower lets Firefox work on the screen; I didn't have this problem on pmOS; either the default scaling is lower on pmOS, or they have some other workaround.
I like how sxmo lets you open/close the keyboard whenever you want by swiping up from / down to the bottom edge of the screen, regardless of what apps are open or what’s happening within them.
There's some minimul visual elements, eg if you choose the tabbed layout.
So the comparison for XMonad wouldn't be all of KDE or Gnome, but just how those two choose to decorate their windows. Eg their 'minimize' and 'close' buttons and window borders.
To be slightly more serious than my original comment was:
If you can rethink your UI in such a way that some things can become invisible, that can be a very ergonomic choice.
To give a better example: look at the bad old days of C and memory management via malloc and free.
One direction you can go into is Rust. Compared to C, Rust has a greatly improved user interface [0] for handling memory allocation.
Another direction you can go into is Python. Compared to C, memory management is basically invisible in Python. It just works.
Now, of course, Python gets to simplify its UI by essentially removing control from the user. But for many programming tasks, that's a good trade-off to make.
Similarly, iOS gets to drop the UI elements associated with manipulating windows, because it puts every app in full screen. (And XMonad greatly discourages you from fiddling with Window placement and layout manually; but has some less-intuitive less-discoverable means to do that manual fiddling, if you need it.)
[0] The user of Rust being typically called a 'programmer'.
• switch to sidebar view and examine the buttons at the top of the sidebar
• go Workspace → Workspace Behaviour → Desktop Effects and examine the buttons at the right
• go Workspace → Workspace Behaviour → Virtual Desktops and examine the buttons at the right
• go Workspace → Workspace Behaviour → Activities → Activities and examine the buttons at the right
• go Workspace → Window Management → Window Rules and examine the buttons at the right
• go Workspace → Startup and Shutdown → Autostart and examine the buttons at the right
• the most egregious example: go Personalisation → Regional Settings → Formats and examine the whole dialogue, it is entirely made of frobable regions
• go Network → Connections and examine the buttons at the bottom of the connections list
• go Hardware → Printers and examine the buttons at the top of the dialogue
I do not understand what goes on in the responsible programmers' heads. Why does the implementer reinvent buttons badly, instead of using a standard button? Is there no one reviewing? Is there no one saying "no, we cannot burden a KDE user with this bad usability, I will not merge this code"?
I abandoned KDE during the KDE-3 (edit: to 4) migration apocalypse, when nothing worked as it did before, or at all, and everything looked like it needed at least another year of refinement.
Is this settled and past now? Is KDE still adament on making virtually every other pixel configurable?
KDE 3 was rock solid. They did break a lot of stuff when releasing KDE 4. That was very unstable / crashy. At that time I moved to Gnome 2, and moved back when Unity was shipped by default in Ubuntu. The late KDE 4.X releases were rock solid. I didn't like KDE 5 at first. A lot of things felt unfinished / not ready. but KDE 5 has been rock solid for years now, and from what I understand they have promised they would make more incremental changes from now on (so no more KDE 4.0-like disruptions). They are currently focusing on ironing out the small things instead of breaking stuff every month.
Now the world seems more mature: Cinnamon, KDE and The Ubuntu favor of Gnome seem to work very well (Each time I see Ubuntu Gnome I think "wow, that looks good!"). Xfce have been rock stable and reliable for years and years for people who like it. Still looks the same as when I discovered it 17 years ago. I've heard people like the current versions of Gnome and that the latest versions are better.
And yes of course everything is still highly customizable in KDE. There are people who make it look like old Windows, some who make it look like Mac and both work quite well. But you are not forced to customize, the default are top notch and that's what I use. They've been working on the settings center which was a mess and which is still not perfect, but it's gone to the point where it is one of the best I've seen. In comparison, the Windows' several setting centers are a huge mess and the Gnome settings are lacking, and you need to install Gnome Tweaks to have some useful stuff and now you have two settings panels.
I used KDE 4 from the first alpha versions (~2007) and never quit using it. However, I had friends who didn't like the mess that KDE 4 was in the beginning and who were very verbose about the good KDE 3 features they were missing and the new behavior they didn't like.
However, at some point they saw that the very few things they were still missing were neglectable compared to the good things that KDE 4 brought with it.
Nevertheless, 2007 to 2012 were 5 years during which it wasn't easy to be a KDE user ;-)
> I'd be curious to have a review of Breeze / KDE by Martijn.
He mentions KDE in the blog post:
> The feedback I get is that I should move to QT/KDE, but I think that theming has had the same issues for way longer already and I do really like the Gnome HIG.
> It seems like KDE and Plasma is the place where look and feel is constantly but incrementally refined;
Every time I see a comment like that, I try again KDE, only to leave it 15 minutes later because it is a huge mess. Everytime I try configuring the panel to my liking nothing goes where I want to and I end up with widgets everywhere.
665 comments
[ 4.4 ms ] story [ 275 ms ] threadLike the interline spacing on things, sometimes it feels inconsistent. KDE menus, for example, have a nice spacing - but GTK ones feel cramped. And those submenus that they place on things like the top-right menu on the panel have different line heights.
Some other third party apps, for example that mail client I tried the other day (it wasn't evolution, but I can't remember its name) had serious layout issues. libadwaita was supposed to fix those inconsistencies and make devs lifes happier, but...
And speaking of buttons and top right corners, I will never, ever get why they place the open/save/select dialog buttons in the top right corner of the dialog. Where you are used to find the 'close' button. Why?
In comes GTK4. Much like the article alludes to, the elegant and simple shadow of interactive elements goes poof. Developers spend hundreds of hours crusading against letting people use third-party themes, just so they can simplify and reduce UI elements to a nigh-unusable pulp. Developing with GTK4 is a nightmare. Using GTK4 is a pain in the ass. For christs sake, there was a devastating font-rendering glitch that existed for more than ten months after the first GTK4 release that was ignored in lieu of simplifying buttons, developing a new forced stylesheet and telling people "don't theme our apps!" Whenever I take this up with a maintainer, they immediately take it personally and write out a litany of reasons why I'm wrong and why I'm not allowed to disagree. The priorities here are almost unbelievably misaligned, I've pinned my GTK packages at the last GTK3 release and await some sort of admission of failure.
I simply can't take it anymore. These are the people making desktop Linux miserable, and I frankly feel no remorse watching their attempts at "simplifying" the ecosystem crash and burn.
I'm just not designing gtk4 apps untill it's actually better than gtk3
Just to clear up any confusion:
- People have been working on the font glitch for the last ten months. It's not easy and the solution is not straightforward. Multiple solutions have been proposed but none are without issues. The problem is not being ignored. I want it to be fixed too.
- The choice of whether to allow themes or not belongs to the app developer. This hasn't changed at all from GTK3. When making an app, you can choose to allow themes or not. Some app developers won't, but you don't have to make that choice.
- The stylesheet isn't forced at all, when you develop an app you can configure your styles to always override the platform theme. This also hasn't changed at all from GTK3 and doesn't change with libadwaita. Take a look at the style context priority system for more info.
- Pinning your packages to GTK3 in protest doesn't help you. It doesn't make a difference to the GTK developers at all. If you want to make use of some GTK4 features eventually, it would be best to start working with it and getting your issues sorted out now. You can ignore what the other app maintainers are saying, that has no effect on you.
Hope that helps, thanks.
> People have been working on the font glitch for the last ten months. It's not easy and the solution is not straightforward.
Then why was it working fine in GTK3? Sounds to me like someone made a breaking change, and didn't anticipate the consequences. The solution is to roll things back or wait until this new implimentation is fixed to push the code to actual users. Unfortunately, the GNOME developers are more interested in scorching earth than they are in maintaining a well-made desktop.
Oh, and it's not because it's a "hard issue" to fix, it's because nobody made a PR for several months. Apparently none of the core maintainers considered it much of a problem.
> The choice of whether to allow themes or not belongs to the app developer. This hasn't changed at all from GTK3.
No, it doesn't. There is not a single application written with GTK3 that can stop me from changing it's theme. I'm sorry if you disagree, but that's just an outright lie (I say this as someone who actually writes GTK3 code).
> The stylesheet isn't forced at all, when you develop an app you can configure your styles to always override the platform theme.
...and I can override it again. Any questions?
> Pinning your packages to GTK3 in protest doesn't help you.
Correction, it doesn't help you. It keeps my applications looking just fine.
> It doesn't make a difference to the GTK developers at all.
That seems to be a recurring trend when negotiating with GNOME/GTK developers. I don't care, I'm perfectly satisfied taking matters into my own hands since they'll ignore me anyways.
> If you want to make use of some GTK4 features eventually, it would be best to start working with it and getting your issues sorted out now.
I don't. What features are there, right now? Worse text rendering? Less accessibility features? More extreme, abrasive maintainers and fewer people writing code? A worse native experience, more middleware and less software freedom? Less native packaging? More Flatpak bloat? Worse touchscreen compatibility and an increasingly fractured codebase? More broken custom widgets that don't adhere to the GNOME HIG? An uglier, flatter overall design philosophy? Militant users and developers who hunt people down when they express their feelings about software they used to use on Hacker News?
Worse looking buttons?
You can keep it.
> You can ignore what the other app maintainers are saying, that has no effect on you.
I don't even know what you're trying to say here, but it sounds like doublespeak. This entire comment does, actually, and I'm not sure what your goal was by posting this. Nothing you've said accurately describes the reality of using GTK applications, it's more like an idyllic reflection of what people think the ecosystem should look like, ignoring everyone who doesn't throw away their current workflow to live in GNOME-land. Unless you start acknowledging the pragmatic reality of GTK's end-users, GNOME will continue to hemorrhage maintainers and stir up unnecessary and counterproductive drama for the sake of a few people's ego. And to think that what I said was nonsense, get a grip...
Stop. This is nonsense and adds nothing to the discussion, it's like if I started off immediately dismissing you as a "GTK3 apologist" or something like that. If you have a history of getting hostile replies, your confrontational attitude is directly the reason why, and it's something only you have the power to change.
>Then why was it working fine in GTK3? Sounds to me like someone made a breaking change, and didn't anticipate the consequences.
Yes, that's what happened. The whole renderer was changed to a hardware accelerated one.
>The solution is to roll things back
That's not possible because the renderer touches the entire project. It's probably the main feature of GTK4.
>Unfortunately, the GNOME developers are more interested in scorching earth than they are in maintaining a well-made desktop.
Please avoid these comments. This is a pretty meaningless generalization and adds nothing to the discussion. Just like any large project, there are some GNOME developers that focus on new features and some that focus on maintenance.
>Oh, and it's not because it's a "hard issue" to fix
No, this is extremely wrong. The issue actually is that hard. If you are a font rendering expert and you believe the issue is easy to fix, then please submit your own PR. I'll be the first in line to try it if you do.
>There is not a single application written with GTK3 that can stop me from changing it's theme. I'm sorry if you disagree, but that's just an outright lie (I say this as someone who actually writes GTK3 code).
No, this is also extremely wrong. Any external configuration method you use, a GTK3 application can override it or disable it. I'm not disagreeing and this isn't a lie, this is an actual fact of the toolkit. Feel free to list any of them and I'll explain how it can be trivially disabled.
>...and I can override it again.
I'm sorry, now it sounds like you're agreeing with me.
>Correction, it doesn't help you.
No, this has nothing to do with me. You sound like you were interested exploring GTK4 at some point, if you're still interested, then you'll eventually have to take steps to address the issues. If you don't want those then I don't see what your issue is, your original comment seems to be making assertions about nothing in that case.
>That seems to be a recurring trend when negotiating with GNOME/GTK developers.
This sentence right here illustrates the main mistake you've made. GTK is an open source project, by choosing to use it you're not entering in any "negotiation" with anybody. It's a take it or leave it proposition, and that's the way it's always been.
>I'm perfectly satisfied taking matters into my own hands since they'll ignore me anyways.
In the long run, that approach isn't sustainable. I find that most open source projects including GTK or Qt or any of those other toolkits won't ignore you if you have something useful to add or can take real steps towards correcting the issues that you're having. But being combative and approaching everything as a "negotiation" is the exact wrong thing to do and is probably the root cause if you find yourself getting ignored. Don't do that. You are making everything worse for yourself.
>What features are there, right now?
As previously mentioned, there is the hardware renderer with improved performance. There is also the multimedia framework and the new, faster list models. Those are the big features that I know of. It's absolutely fine if you don't want any of those, by all means stay on GTK3. But if you do want those eventually, then you'll need a plan to migrate.
>ignoring everyone who doesn't throw away their current workflow to live in GNOME-land
What I was saying is that those people...
IIRC the last big-ish change for me was around 15 years ago when some patent-encumbered patches were enabled by default by (some) Linux distributions. Which is okay for me because overall I think freetype font rendering is better than that in Windows with most fonts, the arguable exception being certain Microsoft fonts – however, freetype has the additional advantage that it rarely if ever produces pixelated ugliness with unhinted webfonts, unlike what I've seen happening with Windows.
Some subpixel rendering techniques became unencumbered quite recently. So newer versions of freetype should have nicer subpixel rendering enabled by default.
It's one of the biggest reasons I've never switched to desktop Linux, and I'm not even one of those super picky people who talk about the intricacies of typefaces all day.
But I understand libre licensed typefaces it ships with might not be to everyones liking.
After a decade of “retina” screens, I’m ruined, I can’t stand the look of anti-aliased fonts, whether Windows, Linux or macOS.
This is the hardware solution to something that can be solved in software. If your game is laggy, of course upgrading to a 3090 is going to help, but that doesn't mean you're solving the problem.
I agree that if you are making something and your target audience will be using non-HiDPI displays, then you should actually design your thing on those displays too. But no matter how good your software is, pixel density places a limit on what you can achieve.
I have perfectly sharp text on a 1080p monitor because I disable antialiasing in ~/.config/fontconfig/fonts.conf and force full hinting.
The Nyquist limit is irrelevant to pixel art, because the Nyquist limit applies only to reconstructing signals from point samples. Using pixel art on a monochrome LCD (no subpixels), I can display signals with maximum frequency limited only by the sharpness of the edges of the little squares.
The devs and designers are all using 4k, 5k displays these days. Trying to use modern apps etc. on just "FHD" (1080p) displays is painful.
[1] https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
That isn't going to be the case for Apple users though is it. Apple don't have any non retina devices in their lineup now. The only Apple users who will see a low dpi display are those plugging in a low dpi external monitor. They are going to be a minority.
1080p usage is lower than on Steam but that is because 768p usage is higher :-P.
[0] https://data.firefox.com/dashboard/hardware
https://www.joelonsoftware.com/2007/06/12/font-smoothing-ant...
For example, in Windows 11 I spent close to a minute looking for "Rename" in the right-click menu in Windows Explorer. Turns out it's not there! It's been removed out of the flow of the list and put in the top of the right-click menu, behind a small, picture-only icon that I've never seen before.
MacOS is guilty of this too: Buttons along the top of native apps like Finder don't have text anymore, the buttons are flat without borders, and the icons are thin lines. How is anyone supposed to know what they do??
In most UIs (Apple and Android in particular), I can't tell when one of those on-off switches is ON or OFF. Is the dark side ON or OFF? Maybe the light side is ON. Oh, it's the opposite when Dark Mode is enabled; great.
Bring back text. Bring back nice buttons.
Also it looks funky. The padding is messed up and the text doesn't fit.
Fascinating. Sounds like if you can't read the mind of the desinger you must have a disability. What a great attitude :-p
2. Being disabled is a normal fact of life, also not an insult.
3. Accessibility affordances are not only for disabled people. Lots of people who wouldn’t identify as disabled routinely and gladly use a wide variety of accessibility features.
4. Having difficulty identifying actionable elements like buttons isn’t about reading anyone’s mind, and it isn’t a universal difficulty regardless of their presentation. The ability to customize it so it’s easier for you is inherently an accessibility affordance.
5. It’s entirely possible this setting (along with several others under accessibility) may be more helpful when needed if they were available in another location, but it’s also possible that would make the experience more confusing, and quite possibly for more people—especially for disabled people.
6. People may benefit from this information—quite a few here based on other comments—and it doesn’t deserve this kind of negativity.
7. With all of that in mind, while I’m keeping this response direct, I took the last point as a prompt to edit some of my own negativity out of it. I had a strong negative reaction both because I think accessibility is a universal good and because I appreciate accessibility affordances which help me. But that’s not a reason for me to be a jerk either.
No, but treating non-disabled people as disabled could be. Just like offering help to some disabled people triggers them.
I was going to respond to these numbered points in turn, but that'd be silly. My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice. To put it under the accessibility options can (if we're even a tiny bit snarky) be seen as an insult - possibly to disabled people as well since it lumps a simple standard usability thing in with stuff designed for people with actual challenges.
It's also not cool for them to make critical UI cues an option when they also take away themes which are the ultimate option.
Ultimately they have given no valid reason to make so many things look the same when they used to be visually (and functionally) distinct.
Sorry for the trigger, I didn't mean any insult to anyone other than the UI designers.
Putting this option in accessibility settings does no such thing. That assumption is what I take issue with, and what prompted all of my points above.
> My point is that having basic (previously standard) UI cues like buttons is important and stuffing that option anywhere is a poor choice.
I disagree. I often find designs with fewer borders and shapes easier to use—that is, more accessible to me—_because_ there’s less information for me to visually process to find what I’m looking for.
That said, I’d be perfectly fine if they inverted the default… or even just asked on first install/startup, with a note on where you can change it later if you change your mind.
It looks great in print. It doesn't respect the modality of use for an online world.
I'm tempted to think we have to go to browser vendors and ask them to make <blink> happen..
There's something deeply assuring knowing that I don't have to relearn my whole workflow every few months when the trends change. ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent.
All I want is to get work done the way I want, and I've found the CLI is increasingly the path of least resistance.
Those command-line tools don't have any "engagement" opportunities nor are there bloated teams of product managers & designers having to justify their salaries by reworking them for no good reason.
Which may contradict my previous point slightly, but at least it is easy to put the system back into a state I want and the system will maintain this state.
For example,
Edit: HN appears to strip emojis, so my new edited comment doesn't pack the same punch.[1]https://youtu.be/NIxn9auks24?t=2009
That literally every ancient civilization went from pictures to words as fast as they could should say something about modern icon only design.
Thanks for the idea, and I'll redirect co-worker scorn at U+1F984 for `git push` towards you ;)
Edit to add: Using emoji for commands/arguments is actually quite workable with global aliases or custom zle widgets in zsh, and moderately workable by using $INPUTRC to specify text replacements for readline if you're a bash user.
SystemD screwed with a few that I'm still discovering one by one. "cron", "shutdown" is no longer in the default debian path, I think ulimit was another one.
But at least I don't wake up one morning with the whole interface rearranged.
If I had to guess, I'd say that /sbin and /usr/sbin aren't on your $PATH for some reason. systemd is unlikely to be the culprit.
Getting complaints about how your app is broken because of an overzealous theme that is beyond your control sucks. And after 10 years of dealing with it, GNOME developers decided it was enough.
And... I don't wholly agree, but at the same time, themes had a decade to get their act together and stop angering GNOME developers. They didn't.
It's either something I'd have to fix in my app or fixed in that theme. Just ignoring the situation is just a shitty response.
a. The usage/implementation of widgets in the application
or
b. The stylesheet the end user is implimenting
In either instance, the solution is very simple and within arms reach. It will always make more sense to encourage robust development practices over building fragile application stacks.
That disproportionate response to what comes down to an organizational shortcoming on their end made people upset, I'm not sure what they expected.
They just don't want Canonical or Fedora to ship a theme that makes all applications that didn't come bundled look like shit. If you like the Windows 95 Hotdog Stand theme, you can configure that and everybody probably agrees that that's great. If you inflict that pain upon yourself, that's your problem.
The current "solution" to themes breaking applications is to just not follow the system theme any longer. Everything gets packaged with a hardcoded theme in a sandboxed environment and you'll just have to live with that.
If you have a feature that is used by one customer out of thousands but it's causing problems at every update you push out. It might be better to remove the feature and fire the customer, than to keep supporting it no matter what.
Now you know why the application developers are so loud and angry. We can’t have nice things because distributions shipped broken default configurations, and that’s messed up.
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
This is one of my biggest complaints with the super flat modern designs. Many widgets lost their skeuomorphic depth, which encoded a lot if visual information (the clickability, the current status), but in many cases nothing was added to supplant the loss of those visual cues, so now it is just a label (or a label in a white or grey box) and there is no way of knowing if it is clickable or its current status.
I don't like saying this because I want Linux desktop apps to have every success, but these small and pointless frustrations kill my enthusiasm.
Windows 2.0 - 3.1: 2D
Windows 95 - 7: 3D
Windows 8 - 10: 2D
MacOS 6 - 7: 2D
MacOS 8 - 10: 3D
MacOS 11: 2D
As a side point, I predict Sheriff and Sans-Sheriff fonts to also go into similar phases too though over a longer time scale. We're in a very long Sans-Sheriff phase now but I think Sheriff will be "in" in 20 years.
System 7 and 8 had support for color, and was as 3D as it could muster, like highlight and shadow treatment on buttons and other widgets, and embossed, draggable thumbs.
https://en.wikipedia.org/wiki/System_7#/media/File:Mac_OS_7....
Mac OS X brought Aqua, which was a pinnacle of 3D and skeuomorphic design. You know you're going hard for 3D when you add a drop shadow on all the text in your menubar:
https://en.wikipedia.org/wiki/Mac_OS_X_10.0#/media/File:MacO...
(and that IE logo in the dock wasn't there as a joke: it really was the best browser for OS X until Safari was a thing, years later)
http://www.righto.com/
I'm using macOS 12 right now and there are a lot of 3D elements especially if you compare it to Windows 10 or Gnome in the screenshots of this post. It seems to be a mix of both approaches (similar to GTK 3).
[1] http://bytepointer.com/resources/old_new_thing/20040728_291_...
Are you a lawyer? (There is an in-joke here, I swear)
The best i've seen was a web page with a hamburger menu which had no action.
What, on an iPad, should a designer look at in detail to improve the GTK app, for example?
When I make my own apps one day, I am going to ignore design fads and only make intuitive interfaces.
This rattled my brain, that this is a feature now, says volumes about the quality decline in UI. I am a developer, and mainly use tools on the command line, or with TUIs.
But whenever I use android apps and websites, I constantly find myself longclicking or rightclicking things, hoping for stuff to happen, that just doesnt.
Strangely enough, we don't seem to mess around with steering wheels in cars.
https://bindpose.com/custom-marking-menu-maya-python/
https://ia800200.us.archive.org/0/items/ibmsj2703E/ibmsj2703...
the figure on page 2 shows exactly what you are describing.
The new "flat" design that pops up everywhere sometimes just feels like a lazy version of UI design, where you basically don't need proper styles anymore and just make everything b/w with maybe a border here and there.
I dunno about that (both Apple using flat, and the "gets it right" part).
I'm looking at activity monitor now, under memory pressure, and the table of memory types has "Memory used" row expanded, and yet none of the rows are actually clickable. I spent a few seconds yesterday trying to click the other rows.
Then I looked at system preferences, and it's not actually flat widgets - they have relief for those things that can be interacted with. Things that are clickable are visually marked as such.
I can see why you might get confused there but it feels like nitpicking. I never expected to click on any of those elements because they don't look like a traditional table or outline view.
Exactly this. I often help others use computers and phones. In the old days it was easy to see what could be clicked. Now input and output look the same. It makes it harder to use.
In many ways it is a victory of style over substance - UI's are now designed by the same crowd who designs high fashion, that is clothes not designed to be worn but to be gawked at.
Is it? Style is no style at all if the thing in question does not fulfill its function. The whole point of something stylish is that it accomplishes its end so well and respects the appropriate constraints that is pleases the intellect when it recognizes this perfection.
So if someone is designing a UI that is difficult to use, that is a failure of both style and substance since there is no style without substance.
> GTK4 has been in development for a bit and has improved a lot of the internals. One of the great upsides is that it can take more advantage of the GPU when rendering the UI.
So there was a clear need to rewrite parts to fix internals.
> The Adwaita theme has also been nicely carried over and looks very similar to the GTK3 counterpart. ... > When I want to make a gtk4 application for mobile I would need libhandy, but libhandy for gtk4 is not a thing. The "solution" is libadwaita. This provides the widgets I need but it comes with the downside of having some of the worst decisions in application theming.
So, there we have it: it's not "UI folks just changing stuff", its a ground-up rebuild of a UI-language.
Now, whether or not that ground-up should be flat, modern, or just copy the old, is another discussion.
Oh? Where do the Gnome designers list their runway appearances on their site? https://wiki.gnome.org/Design/
I'm an art-school educated designer, decade+ full-time web developer for over a decade and regular FOSS contributor for about as long, and regular FOSS users since the late 90s. Like most other designer/developers I know— there are way more than you think— I contribute code regularly but never design work. Why? Because it's a sucky experience.
Most FOSS UIs are akin to someone's first website made from cargo-culted code from free tutorials. Fixing it is harder than starting from scratch and either approach takes significant intellectual work before even seriously proposing changes... and those proposals are received with something on a spectrum of suspicion to outright hostility.
Would you contribute code to a project run by people with no coding experience but were extremely opinionated about code, bikeshedded and poopooed all code changes as a matter of course AND referred to developers and their work with the same glib contempt you and so many other developers here displayed in your comments? Gosh I hope not.
I often hear FOSS developers lament lack of designer involvement, but won't even entertain the prospect of having any culpability for that. I mean, come on.
UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. The problems you see in UIs are because the people running the projects Solicited the wrong kind of designers or let people without subject matter expertise trampler on some core features of the design.
> solicited the wrong kind of designers
This points to me that the root problem is that we can't tell what kind is the wrong kind. It's a trust issue, but also a competence legibility issue.
That said-
> referred to developers and their work with the same glib contempt
Uh yeah? Developers absolutely refer to developers with glib contempt.
To some extent you can tell from their title and previous work, just like with developers. Foe example, I had an entirely non-technical boss that understood I might not be the guy to re-write some printer drivers because I was a web developer. He didn't know the specifics, but being in charge, knew he had to ask someone who did, or do enough research to figure it out.
Likewise, UI designers will specialize in designing UIs and be better at making buttons look like buttons than Graphic Designers, and Experience Designers will be better at integrating user feedback and research into projects. Just like you wouldn't trust any one developer to implement critical functionality you don't understand without outside input, you probably shouldn't rely on one designer to that either. If you maintain a project, though, you can't expect designers to instinctually work around what you don't know. Being in charge means that you're in charge of figuring out how to evaluate it. I'm positive that a "I'm not sure how to interface with this sort of thing. Let's work through it so I can figure it out." will be received kindly by people you should consider working with. Good design proposals should already come with explanation and justification to help you down the path
This is a random selection from a google image search of proposal ideas. It was from another post where I was talking about higher-level topics but the principle is the same. Changing a set of control widgets should require no less thought and explanation.
https://github.com/openstreetmap/iD/issues/759 https://github.com/stashapp/stash/issues/1549 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/creativecommons/creativecommons.github.io... https://github.com/godotengine/godot-proposals/issues/1823
> Developers absolutely refer to developers with glib contempt.
ok— now copy and paste the rest of what I wrote. An overly opinionated, defensive person with veto powers that understands the purpose and value of your work is fundamentally different.
The failings of flat design are everywhere.
It is like a mass delusion or something that some segment of the population seems to think it that flat design is actually useful for the everyday user.
We've seen other stupid useless crap spread like a wave across our industry, across our society... so I guess I shouldn't be surprised. Though I've started to question my own sanity.
That's what's going on, as far as I can tell.
a) there probably aren't many lead designers, creative directors and art directors on this developer-centric site b) interface choices for most commercial products are deliberately made by other people c) interface choices for most FOSS projects are made by developers
Second, I didn't directly address the criticism for the same reason I don't go into game forums and argue with the inevitable teen tech wizard lobbing glib, unsubstantiated technical criticism at the "stupid devs." Their peers might believe their saying that a "microservices architecture" caused low frame rates in the last release, but professional developers will roll their eyes hard enough to sprain an eyelid.
I won't waste my time with a point-by-point teardown, but if you're actually interested, here's the first half dozen unsubstantiated assumptions I've seen here about design/designers and the design process:
- 'Flat designs' are uniform enough to judge their value as a unit. - A bad flat design was bad because it was flat— not the hundreds of other problems a design can have. - Designers change things solely to suit their taste or follow trends - Designers don't commonly test or measure usability with quantifiable, auditable data - Bad usability is acceptable if it looks good. - How well you parse something is representative of how everybody else does regardless of their culture, age, experience with other objects, experience with computers, vision, disabilities, etc. - Skeuomorphism was the most effective form to convey those visual cues.
aaaand the list goes on. It's fine that many developers don't totally understand how design works because nobody expects you to be a subject matter expert in anything other than development. That said, confidently making sweeping judgements about design and designers when you don't understand some important fundamentals is just bad form.
As a developer who always had an interest in UI design but has zero formal education in the field, I be really interested to know more about this. Could you maybe explain some of those strategies?
My subjective impression is that design has shifted from building a consistent "language" to a more goal-driven and data-driven approach today. The product owner defines a list of user stories and UI is primarily concerned with making those user stories as frictionless as possible - even if this means a less consistent overall design snd even if it means that less common features become harder to use. Performance is measured in a feedback loop through telemetry and A/B tests.
I might be wrong though, so I'd be interested in a qualified opinion.
(Also disclaimer: I grew up with Windows 98, ME/2000 and XP. So I guess this is my "good old times" spot then, where I'm wearing the rose-coloured glasses.)
What I believe you're noticing is the the adoption of ideas under the (poorly named, IMO) UX umbrella. UI design is either considered part of it, or close enough to get the UX/UI slash treatment. It's not quite there as an idea— people can't decide if UX people are the same or UX Researchers are different than UX Designers or if UX Designers just do wireframes and user flows or also design UIs or if that's left to Interaction designers, blah blah blah. The base ideas seem to be an amalgam of human factors engineering, graphic/media design communication theories, and quantitative marketing type work.
While there are hundreds of trillions of articles on the topic by people thirsty for medium claps, I think the most interesting jumping-off point might be an image search for ux design process and using the charts you see to guide an exploration. The Nielsen Norman group has a TON of stuff online about the topic. Not just design itself, but measuring the maturity of usability organizations, research techniques, best practices and data strategies... I mean all kinds of stuff.
I think a lot of the ideas are tremendously valuable but much of what's written about it feels a little bit too much like marketing material. The ideas are presented a bit too confidently considering how often they change, and too much has that LinkedIN magic bullet kind of vibe. Also, like tech, the industry is subject to spike trends (like tech saw with NoSQL databases) and pendulum swings (like centralization vs. decentralization of services, thin vs thick clients, etc.) For something a bit more structured, the former Lynda.com, now LinkedIn Learning has some really fantastic educational resources on modern design of nearly any stripe.
I'll swing back through if I can think of any specific resources worth checking out.
a flat element can be re-coloured without having to worry you've gotten the shadows correct on the new color. you can put two buttons beside each other without worrying that one appears to have more depth than the other. we make things flat because we're lazy, not because we think it looks good. a culture of lazy designers has convinced people it looks good, so we can continue being lazy.
Or as Statler and Waldorf would have put it: it is a victory of care over matter - we ( developers) don't care and you ( users) don't matter.
An example taken right now with Firefox under Windows: https://daveflix.deeohhtee.enneeetee.net/stuff/tmp/FocusNotO...
Which of those has focus? There is actually a difference (and to take the screenshot they overlapped making it obvious that way) but it is subtle. Try spotting it reliably when they are on different monitors.
At some point it'll annoy me enough that I'll write a util to scan for the current window that is top of the stack and draw a bright green border (or otherwise unmissable clue) around it… It'll look ugly, but I'll darn well know where what I'm about to type will go!
Now if I can't find anything then I just start clicking on random design elements in case they turn out to be a secret button to a hidden page.
I had a win phone 7 device. It was the pinnacle of consistent Gui.
Is it colored? Then it's a button. Is it white? It's a Text box. Is it a giant title? It's tabbed horizontal scroll.
Are you a "designer" who wants to color something non-clickable? Piss off, you don't get to do that.
But a black word in a larger font among black text would definitely NOT be recognized as a button by most people. Context matters a lot.
I would still prefer a border around the button as I'm not sure what you gain by removing it, but at least you provide hints.
I agree that it might not be ideal, but when it is used literally everywhere I do not believe it's that hard to read.
I don't know how you can reach that conclusion, because we only recognise it because of how many times we've been fed this exact pattern over and over again in flat UIs (and failed to realise it was clickable the first N times)
When designing user interfaces, use the mantra: "Don't make me think!" Don't make the user think about whether something is a button or not. Don't make them have to infer that the label is in fact a button due to context.
Just make it look like a button!
It frustrates me that this sort of design has become not just acceptable but celebrated as 'correct', and I long for the days when interfaces did their best to seek my enthusiastic consent to my chosen course of action.
My initial reaction to a piece of text directly next to a button is "why is there random unrelated text there?" and then the sensation of anger as I come to the realization someone consciously decided to make me think about the UI more than I needed to. It's purely a distraction.
Just make it look like a button. There is literally zero reason not to, and you can eliminate the chance of confusion. Why increase the possibility of uncertainty at all? What value does that provide to anyone?
Every UI or design element that causes me to think about it wastes precious moments I could have been thinking about something I actually cared about, for example the actual task I was in the middle of. On top of that, when you use unconventional design, even after someone learns the seemingly-arbitrary, specific quirks of the design you've used, you will cause them to think about it all again later when you redesign the application.
“Decline invitation” needs to be something you can do, of course, but it will be used < 1% of the time, I imagine.
I find that having buttons side by side forces me to think in a mildly unpleasant way, like I have to read two thinks more carefully because there is more onus on me to decide which is the typical action.
What's the reason that the designer wants to nudge me to accept invitations again? I missed it.
Also, what's the difference between that and a dark pattern?
If you want to emphasize/de-emphasize a UI element, you can do something like was established on most GUIs 30+ years ago: make the default/safest option have a thicker border, and the secondary/de-emphasized option have a thin border. Early examples (1985 and 1991 respectively):
https://guidebookgallery.org/pics/gui/settings/appearance/wi...
https://guidebookgallery.org/pics/gui/system/features/search...
Note how immediately-obvious it is which action is the "typical". You don't even have to read the text, you could even squint your eyes or glance from a great distance and still understand which button is the one you probably want.
UI design involves trust, especially for software where people are trying to actually get something done. Making unconventional designs erodes your users' trust. Have respect for them and what you can reasonably expect them to "know" arriving at your software, and they will have an easier time and love you for it. As we can see, these conventions have existed for decades, and deviating from them warrants a very compelling reason, not just "cuz it looks neat".
buttons should be actions, links should be directions,
directions would take me somewhere, actions would has an effect and consequence. That you think this is okay, and assume no-one would ever be confused by this. Is clearly an issue in the industry at large
It's pretty clear that it's clickable, but I definitely wouldn't think it's a button. My best guess would be that it's a navigation element, and that clicking on it brings you to some other page where a decline invitation button might be found, or where you have to fill out some form to explain why you're declining.
Part of it is because it looks exactly the same as "Test User", and presumably that isn't a button... I imagine that is a navigation element. But part of it is also because quite a few recent Microsoft corporate products (Sharepoint, Dynamics, etc.) seem to use the idiom you're trying to use for signaling that something isn't a button.
Things like having pull handles on both sides of a door that has to be pushed from one side. Or having no push plate on either side of a glass door. Do I push? Is it a sliding door that's not working? Don't know!
My car has the climate controls hidden behind a graphic of the current state on the stupid touch screen. It used to be buttons that had three zones for head, body and feet, a wheel for fan and a wheel for temp[1]. Volvo used to pride themselves on having controls you could use with gloves on, so all the buttons had 3D features and a positive press feel.
Now it's not even obvious the graphic is a button at all (it's also incredibly dangerous as you cannot do anything without a multi-click modal process with only visual feedback that you have to look at to use). Thankfully the window demister is still a physical button because that would be incredibly dangerous to hide behind a soft screen interface: when you need it you need it. However, it's lost its 3D profile and is now just a flat button.
My office has an amusing one: there's a door at each end of the building. The building is the same on both sides, neither side looks more "fronty" than the other, and the doors are the same. Only one of these is the main entrance. The door next to the car park (i.e. where anyone unfamiliar with the site will arrive) is not the main door. Therefore there are no call buttons. However, there's also no indication that there is another door on the other side. A whole building basically has no obvious start menu. Just...why do that?
[1] https://bparts-eu.s3-eu-west-1.amazonaws.com/ftp/azor_2/000/...
They bear no ill will against users who download or make their own theme.
There are only three small screenshots of UI in the dark theme, but to me it looks very clearly like a naive "invert all the design token colors and call it a day" implementation.
That is Gnome. Gnome has become a top-down project that values consistency/coherency over modularity/theming. It's an extreme, and I suspect that they went too far, but with it comes a number of benefits, such as a unified visual style across all apps, and an easy to use internationalization/localization subsystem.
Not sure what that even means. The majority are not the Gnome developers, and many users will just adapt to whatever they're fed, even if it's worse.
>> That is Gnome. Gnome has become a top-down project that values consistency/coherency over modularity/theming.
No. People aren't complaining about a lack of consistency or a lack of theming (some do). They are complaining about a shitty design where the elements are consistently nonsensical and harder to understand than past version of the same.
Top-down means a few people who are at "the top" think they know better. Not that they're great designers either - they are copying stupid trends that other "design" people came up with. This stuff is complained about on all OSes these days. It's not a vocal minority either, and you can tell because nobody complained that GTK was falling beind and needed to update to a modern "flat" design.
They care about that so much that they break Gtk+ every few version, to the point that in 2022 there are still Gtk+ 2 apps around, and there will be Gtk+ 3 apps following old design paradigms for years to come. So much for consistency.
It's 2022 and I don't see Qt 4 around anymore, or apps using it still being widely in use. Guess why? Because Qt developers actually give a damn about people using their library, and they give a damn about people using the _latest_ version of it.
What GNOME is doing today is telling everyone to go fuck themselves, and pushing people towards writing their next app in Qt, which by the way integrates nicely with GNOME and does not look like garbage everywhere else. Now with PySide being finally a first class citizen and working well with QML there's not even the "but C++ is ugly" card to play against going Qt.
On macOS Desktop, checkboxes, buttons and everything else are still designed for mouse/kb
On gnome things are designed for vertical and touch screens, so you forced to endlessly scroll, windows is doing something similar, wich is an indication that they target mobile users, they are so out of touch
Only Apple knows what they are doing when it comes to UI/UX for desktop, and they make sure they don't mix desktop/mobile UX
But to be honest, isn't it one of the recurring point of people running away from gnome? Haven't they just proceeded going ahead not listening to anyone?
Ultimately I think this will be quite good for QT/kde in the long term. Gnome/GTK gets a lot of corporate support, especially from red hat, but seeing the issues pop OS had with GTK makes me hopeful that more companies will adopt QT.
KDE does not seem to have an equivalent behemoth behind them, even though Qt enjoys a lot of heavyweight corporate support.
“Big likes big.”
What I cannot understand is how Canonical, Red Hat, or some rich SV person hasn’t thrown money at the problem and hired a big wig design firm or person to overhaul it all. Johnny Ive is now even available (if he’d take the project). But even going thru a site like dribbble there are so many amazing designers out there. To me it would be a more impressive portfolio piece for a young designer to properly design GTK/Gnome and put it out there for the world. What is stopping this? It can’t be caring with the history of people sharing their themes. Is it just taste / money?
I’m not even saying that that’s a bad thing. As it happens, Android has been generalized and generalized from its original use-case until it is today a quite-workable desktop PC OS.
It'd be great if it could be solved with just one pass of design work and then it's done, but I'm afraid the task is much bigger than that, and "big wig design firms" are expensive, so are design people as well. Not to mention the other problems around that.
For example, style guides written and enforced by a small team can allow open contributions for the UI design.
I think it's mostly that not many have tried to figure out how to organize and actually run large-scale open source design work for UI/UX and that's why we haven't figured it out, I don't think it's "inherently" impossible.
> good software design (as in programming)
That's the second problem. Most programmers probably know about about how good software design works, but have poor taste and prefer designs that aren't suitable for software that is to be used by non-programmers that want sane defaults that work and don't overwhelm them.
Just look at the theming debate. People in software developer forums are mad about it. Most users probably don't even know it exists. They just want settings and a UI that's simple enough for them to understand and allow for some basic settings.
So you would have to force volunteers to implement a design that they feel is bad. And you see how a lot of people react to it in the Gnome project where people leave because of it. But at the same time Gnome is a good example of how to do UI/UX for a big open source software project (even if you don't agree with their design decisions).
To make a more general point: top down leadership is not inherently bad. But in order for this to work well, people need to have the ability to enter and exit a project or polity at will.
(See eg how McDonald's doesn't let customers vote what to put on their menu, but customers are free to eat at a competitor or make their own food at home.
And compare that with North Korea also not letting citizens vote on their menu. But also taking steps to keep people from switching to a competing provider of government services, like South Korea. Similar also for the Berlin Wall.)
which hear me out here... was the whole point of having a standardized widget set and UI library.
Someone is putting together standard HIGs for Gnome, writing these standard themes, designing the base apps, etc. So you can't just say it's all decentralized and so there's no hope -- there's a ton of collaboration and top-down work happening with Gnome. Pulling in great UX/UI design talent should be prioritized.
They do employ designers, including for GNOME. You might not like their designs. But to call them anything but proper is pretty mean spirited.
Professional designers seem to be the ones creating these problems. Back when it was just programmers you could tell a button was a button, a tab was a tab and we didn't hide basic functionality behind a swipe gesture or long press that users were supposed to just know.
Now everything is pretty but harder to use.
Keep in mind that programmers also gave us this: http://www.martin-achern.de/wgetgui/images/linux_wgetgui.jpg
People across all disciplines are capable of making poor design choices
You're basically proving the point. That is so much clearer and obvious to use than the screenshots in the original article, and it doesn't treat you like an idiot.
This application still has an absolutely crap design.
* How do I specify where the downloaded data goes? Why are there onscreen options for literally everything else, but not that?
* Which text entry fields are disabled, and which ones are enabled? This is something Win95 got right.
* What even is "force directories"? And it looks like checkboxes are used for both it and "no directories", so what happens if I check both?
* What's the difference between Spider and Recursive? Those sound like the same thing to me, and I know I'm in a pretty elite club just knowing what web spiders are at all.
* Are jpeg/gif/etc only used when Reject is turned on, or are they also used when Accept is turned on?
* Is the wget-list input field connected to the Input file checkbox? It's right underneath it, and presumably I have to specify the input file somewhere, but the spacing implies it's not.
* What's the difference between "quiet" and "non verbose"? What happens if both are turned on?
* The rest of the buttons are pretty well labeled, but what's AG?
* Does it really need its own quit button? The window manager already provides one.
I didn’t stop listing problems because I ran out. I stopped because I got bored. Now you got me going again:
* Why does input-file have no “Browse” button?
* Why does log file have no “Browse” button?
* What is the point of showing the command line flags? I’ve seen a few GUI apps that let me “export CLI” commands that match what I configured in the GUI. That would be a much better way to do this.
* Why does nothing indicate that the exclude/include lists are only used for recursive fetching?
* Extra Params can potentially be very long, yet the box is tiny.
* I assume quota=0 turns the feature off. Why no check mark?
* Why do the exclude lists have check marks, when leaving them empty should be equivalent to turning them off, if quota has none.
Wget’s CLI is better than that thing.
> but it's better than the "small mysterious monochrome hieroglyphics floating in a sea of white/darkness" that "modern" UIs seem to be gravitating towards. At least textual labels are searchable.
I did intentionally start my post by saying I agree with this part. iOS 7 was a mistake.
Ah, I can just feel it failing to pop up a tooltip when I mouse over the "spider" option!
I can also feel the entire window disappearing when I click "START wget." Is that what happens? Maybe not, but that was par for the course on a lot of those motif GUIs.
And I can definitely feel how the growing information density was even frustrating the poor dev. "Load sett.", "Save sett.", ah fuck it... "AG"
And again, feeling the disappointment as I mouse over "AG" and get nothing...
Essentially, this is not even a GUI application, this is a printed cheat sheet for console program with interactivity, like HyperCard or '90s context help systems, but with “callbacks” affecting the program state. It is made for people who know and understand the console version, and just want to choose options with the mouse. Of course, it may be advertised as something made for regular people, but that's a honest false belief. It's more of a convenient shell alias transferred into 2D, something which is not expected to be super nice, or handle all corner cases if it helps you in general.
I think it is, actually, something to be encouraged. There are some tools that people made in Flash for their own use or some fan group because that's what they “programmed” in, not to mention big examples like (Visual) Basic, etc. A user is not just a consumer of what comes to the dumb personal device, a user is someone who can make it work in some unique way, because that's what computers are made for.
Those conventions were created by usability experts after years of research. It wasn't simply programmers building them back then.
1. Developers with a wide range of understanding of UI from negligible to acceptable.
2. UI experts who actually understand code.
3. UI "experts" in industry whose only skills are image editors.
4. Academics who did said research.
Seems like the entire problem is the ascendancy of Camp 3 which decision makers who being ignorant of technical matters themselves can't tell from camp 2.
Meanwhile everyone is ignoring camp 4.
Meanwhile, camp 1 mostly won't break anything by themselves (developers do usually learn enough UX for that), but also are unable to fix anything.
I'll just add that camp 4 didn't exist only in universities by the time those things got developed. But they almost only exist there now.
Even beyond that, the world is changing. New needs, new expectations, new styles in design. Just like we wouldn't expect cars to be frozen in time in the 1950s, we shouldn't expect UI/UX to be either.
Linux DE's have never had a particularly well thought out, well designed look. There's been a lot of themes that people create to mimic other commercial systems out there, but not a lot of very high quality original work going on. Yet we can see plenty of good work technologically. For a long time when it was largely grey beards most people didn't mind so much, but now people expect good design across all products. The standards have risen, and the FOSS world should meet that challenge head on.
The article focus on the settings control panel. What new needs and expectations does the new settings control panel in 2022 have compared to 2010?
Settings panes are still largely confusing on all platforms, commercial included, as you broaden your user base. They've also grown in utility as iOS has pushed the idea of a centralized place for settings for all aspects of the system (apps included), which you're starting to see elements of on other platforms as well. There's plenty of room for improvement, including simplifying everything down so that few settings can make big differences where the heavy lifting is done for you. Linux in particular suffers from this, from a legacy of a million .conf files everywhere that many people blindly copy-pasta'd random configurations they found online (I'm looking at you XFree86).
I think a lot of this is influenced by modern MacOS and iOS settings management (much like, to my recollection, Gnome 2 settings panels were very influenced by how Windows was doing things). It's not like it's 100% better, but for my usage it's felt nicer.
There are also a lot more work in this idea that there are many different ways to get to a settings pane. That way it's easier for people to get to a thing even if they have different ideas of where it "should" be
I think your example points to a peculiarity of UI/UX: cars have changed a lot since the 1950s, but their interface has remained surprisingly constant.
I think there is a point to be made that an interface can reach a point at which it cannot be improved, or at least not without a whole paradigm change.
If you’re focused simply on the steering wheel itself that’s like saying there’s still a mouse and keyboard. Yes, that’s true — and even that will likely be disrupted over time. But everything else has changed.
Push button shift considered in 1913. Push button starting actually predates keys.
A touch screen UI is indeed new but its a UI horror story for something that is expected to be operated while driving down the road at 60 mph.
[1] https://lunduke.substack.com/p/elementary-os-is-imploding?s=...
I love ElementaryOS, it's great, everything just works, I didn't have to tweak a single thing or mess with drivers earlier this year when I installed it on a new laptop that even Mint was having issues with.
Going off to read that link now.
Oh, Lunduke is misgendering people now? I'm sure that isn't on purpose.
Is that still the case? It would be a huge disincentive for other distros to contribute to the commons when ubuntu just parasite from it to a big market share.
Fact check, Gnome was filled of memory leaks and performance issues until some competent Canonical developer started working back on GNOME and fixing them.
So while Ubunut was not using GNOME the RH could have safely put their money into GNOME and it would not have benefited Canonical but the reality is that Canonical had to pay competent people to fix GNOME bugs, but probably Canonical can't change the desinger dictator so they usewd for a while a fixed theme and not the shity GNOME default.
I disconnected myself from Linux news so I don't know what drama happened in latest 2-3 years.
https://www.omgubuntu.co.uk/2019/10/ubuntu-improves-gnome-sh... you can google the dev "Daniel Van Vugt" and check his work on GNOME, or you can google "GNOME shell memory leak" , as I said I stopped following Linux stuff (I am still a Linux users) and I have no idea what happened in recent years except the major things like GNOME's reset triggering a new fracture in it's community.
Anway, Canonical was not using GNOME so RH did not avoided paying for better developers because Canonical would benefit. Later when Canonical decided to use GNOME they fixed the major performance issues and memory leaks and put back some of the features the users wanted but designers refused to provide.
Instead we get a very rapid iteration with a 6 month release cycle that continually pulls in new tech prior to it actually being ready while it still has massive issues with end user experience including but certainly not limited to gnome 3, pulseaudio, gnome 3, wayland by default in 2016 which is now 6 years later supposedly almost fully ready for prime time.
My experience running Fedora for 7 years is that each release was a chance to play with new tech and fix new broken things. In place upgrades were also extremely dicey making a fresh install of the new version necessary every 6-9 months.
This is great for a toy less great great for something you intend to use. I'm sure current proponents say its great now but they literally have been saying the same thing forever.
Microsoft isn't actually responsible for this nonsense. Metro did get rid of bevels, but it didn't get rid of obvious buttons: they simply turned into trivial colored rectangles.
I'm not entirely sure who "refined" it, but Microsoft did eventually end up copying a bad iteration of their own good idea.
Windows 2.0 - 3.1: 2D
Windows 95 - 7: 3D
Windows 8 - 10: 2D
MacOS 6 - 7: 2D
MacOS 8 - 10: 3D
MacOS 11: 2D
Much, much easier to style based on whatever the surroundings are. Also easier to maintain a good look if you switch to a completely different theme, and for third party icons to mesh with the OS set of icons (only so many ways you can mess up the sillouette of the shape).
Oh, and they scale to basically infinite proportions without looking weird, which cannot be said for color vector icons.
Check Haiku OS.
Eventually it'll mutate into cuneiform and no one will realize they've learned an ancient script.
edit: #dyac
I don't remember if that's enabled by default, or you have to install some gnome tweaks to do it, but it is nice.
In the past, I used to disable title bars entirely even on full-sized monitors. These days it's not so easy to do that, though.
> The design even works very well on Linux phone formfactors.
The author must mean something very different when they say "works very well" than I do when I say that. As much as I want it to, nothing about GTK works well in a phone form factor, IME. I look forward to continued improvement that will make that statement incorrect.
I don't think so, touch targets are a lot bigger. Using the default theme for both a KDE App with equivalent functionality will take a fair bit less space than a similar gnome app. Of course I think plasma mobile uses a theme that makes the touch targets bigger...
KDE also manages to get a lot more functionality into their similarily sized windows. Take a look at this page showing comparisons:
https://www.linuxadictos.com/en/aplicaciones-de-gnome-y-apli...
I'll go as far as to say that the desktop experience hasn't received much love by major software companies; since the late 2000s the money has gone toward smartphones, tablets, and the Web. Since those platforms get the attention, the desktop is increasingly getting populated with ports of smartphone and Web apps; hence, Windows Metro/UWP, Catalyst, Electron, and the like.
This is because GTK4 enables pixel/scaling-independent fractional vertical positioning, even with hinting enabled. There's a long (somewhat ongoing) discussion at https://gitlab.gnome.org/GNOME/gtk/-/issues/3787, though I haven't followed the last few months of discussion.
Even though GTK4 aims to achieve scale-independent layout, the 4 horizontal/vertical positions still produce a bit of judder, and fonts do not scale smoothly (even with bilinear interpolation) with hinting enabled, and (unless fixed) there are rendering issues due to failing to clear the texture atlas properly: https://gitlab.gnome.org/GNOME/gtk/-/issues/4322
Interestingly there's a proposal to switch GTK4 fonts to SDF-style rendering. This is somewhat like what Qt Quick 2 implemented already (and KDE turns off and reverts to FreeType rendering, to make QML apps mimic Qt Widgets font rendering more): https://blogs.gnome.org/chergert/2022/03/20/rendering-text-w... However, I looked at https://github.com/behdad/glyphy and it seems to implement vector-based SDFs, instead of earlier texture-based SDF/MSDFs used by Valve games and Qt Quick.
The maintainer responded that "[c]hanges to the rounding behavior of glyph positions really belong into pango, though". I understand, but I don't know whether he's suggesting fractional layout but integer-rounded rendering, or integer-rounded line heights and layout and rendering. And I don't know how to change Pango, and lost interest in digging further.
With font rendering, I think there is hope. Horizontal subpixel positioning with vertical hinting seems like a good tradeoff to me. Grid fitting vertically is not too jarring, and grid fitting horizontally to subpixels instead of pixels looks pretty good too, on low resolution displays.
But it really is a son of a bitch elsewhere. For example, if you want a crisp 1px border on 96 dpi, you could specify it to be a 1px border at 96 dpi… but then what happens at 1.5x or 1.75x scale? From a purely logical position, the blurry line is actually the general case, and the integer scale case is actually an edge case. That desktop UIs aren’t blurry basically always is because we define them in terms of 96 DPI displays.
It gets worse for APIs, because APIs that want to present a resolution-independent world will cause difficult to tolerate bugs. The VS Code terminal will often be blurry at non-integer scales because it is using HTML canvas. If the canvas width or height is not a multiple of the size of a CSS pixel, it will cause the internal buffer to be scaled horridly. The fix might be a new API that reveals true coordinates… very, very nasty.
Apple’s solution was extreme: dump all font hacks, always render apps at 2x, then scale the whole framebuffer for different scale factors. It’s somewhat blurry, but avoids many ugly pitfalls in the common case, and makes apps simpler.
Unfortunately, the rest of the world is just stuck with really bad scaling and more often blurring on 96 DPI displays, the worst of both worlds.
The border width should get snapped to the physical (sub-)pixel resolution as part of rendering. Typically, this should come with changes in contrast too, such that if a line is forced to become thinner it also gets drawn with higher contrast wrt. the surroundings, and vice versa. All of this stuff can be made to work.
Also, if you are forced to render a canvas at a resampled resolution because existing APIs give you no other choice, at least do it right using a proper Lanczos-style resampling. This might end up with a quaint "watercolor" effect but guess what, that's a lot better than a blurry, eye-fatiguing mess.
We’ve tolerated a great degree of complexity just to make fonts look good at 96 DPI. Looks like we’re able to tolerate a bit more complexity to enable GPU rendering. However, many years into having high DPI displays, it’s not obvious people are willing to take the complexity to make low DPI and high DPI screens look good simultaneously.
The thing is, with fonts, we already bear the burden of font rendering being complex because that was needed for 96 DPI displays. But, we won’t need much of this magic or complexity when a vast majority of people are using higher DPI displays, because at >200 PPI the difference between a blurry line and a sharp line is basically nil. That is obvious enough on Apple platforms, where many are perfectly happy with the scaling even though it uses 2x as a base for all scales.
I think the future is simply pain. People want cleaner graphics pipelines, and only high DPI displays will get them anywhere.
The font rasterizer already exists (unless it is a bitmap font UI, but those aren't common any more).
How does adding additional mechanisms make for a simpler or cleaner rendering pipeline?
Then there’s compositing. Normal layers can be composited using alpha blending, assuming some sane format like premultiplied alpha RGBA. But not subpixel rendered text, because alpha blending the components will fuck up the subpixel rendering.
And it goes on, because if you want to handle text like everything else, you need special cases for it to look right. Rotation? Need to render the vectors rotated; can’t rotate in raster. If you need to render to a surface then transform that surface, you’re SOL; it can’t go to rasters until the end.
Normal surfaces can also be rendered at subpixel positions, and of course this does not work for surfaces containing text, because again, it will destroy the subpixel rendering.
OK. So you can get rid of the subpixel rendering and render slightly blurrier glyphs instead. (R.I.P. anyone trying to tell hanzi/kanji apart.) It’s still going to murder legibility if you move it over by a subpixel value because text is already on the edge of readability at 96 DPI.
I haven’t considered gamma correction, hinting, blending different colors, different blending modes, GPU acceleration, etc. because I simply don’t have the brain power to try to reconcile it all. It’s a nightmare.
We already did some of this for text. Which is a herculean effort. We use a freakin virtual machine to power font hinting, and ugly, complex, slow special casing at many layers of already ridiculously complex vector graphics stacks (I mean if you disagree with that assessment, you may just be smarter than I am, but I have serious trouble following the Skia codebase and I doubt Cairo is really that much better.) And speaking of which, there only really seems to be a handful of them out there: there’s Skia, used by most web browsers; Cairo, used by GTK; Direct2D, in Windows; Whatever modern macOS uses that isn’t QuickDraw anymore; and I guess there’s Mozilla’s pathfinder, a promising Rust-based vector graphics engine that was built as part of Servo and seemingly mostly abandoned, much to the world’s detriment. This work is hard. It can be done, but it’s not something I think a single engineer can do, if you want to build one that competes with the big boys even disregarding a few things like performance. I’d love to be wrong, but I have a sinking feeling I’m not.
Even text isn’t done being overcomplicated. As nyanpasu has mentioned above, some software have started implementing SDFs for font scaling. We do this because text legibility is really that important, whereas a line in the UI being slightly blurry for users on older screens is really just not that important. Some languages flat out can’t be read with crappy font rendering, and any of them will give you eyestrain if it’s ugly enough. As much as it sucks, a blurry border on a button doesn’t have an accessibility issue. And rendering at 1x and making the compositor upscale is not a great solution either because again, it’s already hard enough to read text in some languages; the added blurriness of scaling text and ruining subpixels is basically intolerable.
These hacks aren’t free, and with high DPI displays, they’re not needed. There’s a reason Apple did what they did.
As I understand it, all that's needed is a vector renderer, and you keep everything (even text) in vector format as long as possible. RGBA then becomes a special case, as it must be for any DPI independent rendering pipeline.
Trying to compose rendered vectors using pixel based operations is madness, so... don't?
That means you can't have a bitmap-based compositor. So what? GPU's are great at rendering vectors. Composite those instead of bitmaps.
Or, just don't composite at all. A decade later, Linux desktop compositors are still an ergonomic regression vs. existing display drivers with vsync and double buffering support.
Yes. Driving ~1024x768 framebuffers, on single core processors, with far less demanding workloads, but still, yes. (They still badly needed good glyph caching to accomplish this.) (I’m assuming a Windows XP-tier machine since that was the era most people started using ClearType/subpixel rendering.)
(Single core processors are obviously slower than multicore processors, all else equals, but exploiting multi-core processors effectively is harder and often leads to code that is at least a bit slower in the single-core case…)
> As I understand it, all that's needed is a vector renderer, and you keep everything (even text) in vector format as long as possible. RGBA then becomes a special case, as it must be for any DPI independent rendering pipeline.
I don’t want to sound like I’m being patronizing, but I get the feeling that you may not be grasping the problem.
We can’t just use text rendering logic to power other vector graphics. For many reasons. Text is not just rendered like vectors, as that would simply be too blurry at 96 DPI. Old computers used bitmap fonts or aggressive hinting, and newer computers use anti-aliasing, often with subpixel anti-aliasing. Doing that with every line on screen isn’t feasible even if you wanted to write the code. Here’s an attempt to enumerate just the obvious reasons why:
- It’s slow. Yes, old 32 bit computers could do it, yadda yadda ya. But they did it for text. At the glyph level. And then cached it. They were most certainly not rendering anything near the entire size of the framebuffer at once.
- It’s difficult to GPU—accelerate. GPUs can do vector graphics and alpha blending fast, but subpixel rendering as its done with text is not something that can be done using typical GPU rendering paths. It could still be made to exploit GPUs, but it requires more work and is slower.
- Fonts achieve better crispness on lower DPI displays using hinting VMs. Without them, many glyphs would be quite blurry. Hinting VMs allow typographers making font outlines to make specific decisions about when and how vectors should be adjusted to look good on raster displays. In case it isn’t obvious, the problem here is that doing this for every line on the screen requires you to write special casing for every line on the screen. Maybe you could come up with a general rule that makes everything look good and doesn’t wind up with uneven looking margins or outlines ever (you really can’t, but…) — you have to run this logic for every line. That’s an increase in complexity.
- Glyphs only need to care about their relationships with eachother. UI elements on screen have arbitrary concerns. They have relationships with other things on screen; they line up with other shapes and the whitespace between them is significant. Glyphs only care about other glyphs horizontally adjacent to them (or vertically in some scripts, perhaps) but other UI elements care about their relationship with potentially any neighboring UI elements.
- UI rendering code does not exist in a vacuum. At some point, apps will need to do something that requires them to know the size of something on screen either in physical or logical dimensions. Normally, this isn’t a problem, but if all vector rendering was as complex as text, it would absolutely be an issue. The naive way of handling it would seem correct in many cases, but it would be wrong in many others, just like how old APIs that expose pixels instead of logical units tend to lead to apps with subtle scaling issues.
> Trying to compose rendered vectors using pixel based operations is madness, so... don't?
Yes, of course.
Except that, too, is hard. Think about web browsers: they need to support arbitrarily large layers for compositi...
A similar concern is the demand for arbitrary subpixel positioning of screen content, that basically only matters in the context of on-screen animations. Nobody really cares if an animation looks blurry, but it's somewhat more important for static content to look right. Trying to have one's cake and eat it too will always be harder than just focusing on what's actually important for good UX.
This is exactly what I was “hinting” at when I said coming up with a universal function that would work for anything. You can’t just snap some/all things to a pixel grid; it would look absolutely terrible because it would make lines and whitespace uneven. Even font autohinting, which does exist, is more sophisticated than just aligning key control points to a pixel grid.
> Much of the complexity you point out only arises because we now insist on having physically sized rendering for "mixed-DPI" graphics, like a single window spanning both a low- and a high-resolution display. That's not necessarily a very sensible goal, and it's not something that would've been insisted on back when achieving "pixel perfect" rendering was in fact a major concern, regardless of display resolution.
It’s not. Even under Wayland, which can achieve this, the application would only render one surface at a specific resolution at any given time. Nothing I’ve been talking about is related to being able to split a window across different DPI screens.
> A similar concern is the demand for arbitrary subpixel positioning of screen content, that basically only matters in the context of on-screen animations. Nobody really cares if an animation looks blurry, but it's somewhat more important for static content to look right. Trying to have one's cake and eat it too will always be harder than just focusing on what's actually important for good UX.
If you scale a UI that was designed for 96 DPI pixels to a screen that is around 160 DPI, you already have subpixels. If you then attempt to snap to a pixel grid instead of rendering elements at subpixel positions, then you have uneven, ugly looking UI elements.
This unevenness is arguably more tolerable for text than it is for UI elements, but Microsoft actually took the approach of not having it for text regardless; to make text look cleaner, text uses more aggressive gridfitting in Microsoft UIs, resulting in each glyph being gridfit. This is exactly why old Windows UI scaling lead to cut off text and other text oddities; it’s because the grid fitting lead to text that had different logical widths when rendered at different resolutions!
You can’t just wish away subpixels. Numbers that just happen to be whole numbers are the real edge cases in a world with arbitrary scale factors.
Are we talking about single-pixel rounding errors, or something else? The former are already practically undetectable at 1080p, and nearly-so at 768p. Given a high standard of "pixel-perfect" rendering, there's basically zero reason to push resolution any higher!
Of course one can even make pure subpixel-based rendering (no fitting-to-pixels at all) look correct, by starting either from pure vectors or from a higher-resolution raster and then using a Lanczos-style filter to preserve perceived sharpness near the resolution limit of the display. This gets us as near as practicable to something that's almost "pixel perfect", without distorting spatial positions to make them precisely fit a pixel grid.
My "wip/chergert/glyphy" branch of GTK 4 does rendering using https://github.com/behdad/glyphy which uses fields to create encoded arc lists and are uploaded to the GPU in texture atlases. The shaders then use that data to render the glyph at any scale/offset.
Some work is still needed to land this in GTK 4, particularly around path simplification (mostly done) and slight hinting (probably will land in harfbuzz).
My eyesight isn’t the greatest so to run 1440p I need to run 1.5x which makes a lot of things work really badly.
Edit: I think modern web browsers implement ctrl-+ and ctrl-- the same way, except X11 apps kept separate directories of icons rendered for different DPIs, because 1GHz single core still seemed luxurious. Web browsers scale the bitmaps using some reasonable algorithm. Other than that, arbitrary zooms work with zero blur.
For what it's worth, PostScript also got this right back in the 80s.
Old old X11 apps used X11 drawing commands. These sucked, and nobody liked them. If you think you liked them, please show me your clean Xlib codebases for proof :P As far as I can recall, these still dealt with pixels, so clients were on the hook for dealing with scaling, though in theory it wasn’t too bad. They don’t really solve any of the pixel perfection issues that I am discussing, though.
More modern apps (— early 2000s should be “modern” enough by X11 standards, but my memory is foggy and I’m too young to really be an expert here —) instead blit pixmaps sent over shmem, defeating both network transparency and the inherent “vector” nature of many of the old drawing commands. X11 didn’t really handle anything other than knowing the DPI (… that you told it …)
At that point, up to GTK+2 and Qt 3, which is to say, even quite a while After 2001, you had at best limited scalability. If you had your CRT cranked up to around 150 PPI, everything was OK — you could get text scaling and the disparity wasn’t so bad. However, GTK+2 and Qt 3, and their ancestors, were not built with DPI independence. At best, they could adjust vector text sizes according to DPI and scaling preferences. Again, this looks OK for nvidia-xsettings and a modest PPI increase, but it’s absolutely terrible for anything more. Margins don’t adjust, padding doesn’t adjust, icon sizes don’t adjust, nothing. There’s no blur or jankiness because there’s no true scaling.
(Just as a quick note, this is literally the reality of GIMP today, right now. It’s still on GTK+2, and so the best you can get is text scaling, or flat out nothing.)
And that’s to say nothing about what happens if the DPI changes, which requires you to effectively restart everything. And that also doesn’t help people who have two different displays with different PPIs. The ever common case of the high DPI laptop with a cheap LCD plugged in. Have fun with that crap.
Modern Linux can do better. The Wayland protocol comes with DPI negotiation that allows naive clients to get blurry upscaling, “simple” clients to pick a set of scales they can support and have the server adjust for whatever one they decide to render to, and advanced clients can render at any DPI, in response to the server advertising what DPI the current display is. With atomicity of configuration changes that allows a properly written client and server to never render an “intermediate” incorrect frame, and scaling that ensures that surfaces across multiple displays display at the correct DPI on all of them (albeit with either upscaling or downscaling on some of them.)
And that still does absolutely nothing to solve the fact that pixel perfect layouts are inherently not perfectly “scalable.” Because truly scaling some vector drawing commands that just happen to be pixel perfect at one resolution will not always result in pixel perfect rendering in another. You would need code that compensates for the scaling. Old X11 apps did not do this.
Of course I could be completely wrong and old X11 could’ve had some amazing DPI scaling technology that I somehow missed for decades. I don’t think so. My memory is that when I finally hooked up a high DPI display to Linux, I experienced tiny Skype, Pidgin (GAIM) with tiny icons and large text, and nvidia-xsettings with weird hinting/kerning. I’d like to move on from that kind of scaling.
P.S.: PostScript doesn’t do anything magic either. Everyone’s graphics systems were PostScript inspired, and yet macOS wound up with the same DPI scaling conundrums as anyone else. Most people wouldn’t tolerate desktop apps as blurry as a PDF at 96 DPI.
This is entirely untrue. Did you even try ? Qt even at version 6 still supports rendering through X11 commands, and afaik does that by default when ssh'ing on Debian distros.
And I can set my Xft.dpi to, say, 144, ssh -X somewhere and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will so far all use the correct local DPI. Which other remote UI technology supports that ?
When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network. Not all X11 clients continue to work properly if XShm can’t be established, and hardware acceleration is basically a no-go despite OpenGL/glx theoretically being a client/server ordeal.
> And I can set my Xft.dpi to, say, 144, ssh -X somewhere and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will so far all use the correct local DPI. Which other remote UI technology supports that ?
Waypipe. Unlike X11, Wayland doesn’t start with network transparency as a principle, but it is completely possible to proxy it. Other than not being able to get a hardware-accelerated OpenGL or Vulkan context, a client connected over Waypipe is very similar to a local client. The proxy can handle things like serializing data sent over shared memory, so UI toolkits and other client code doesn’t need to behave any differently over the network; it just needs to use synchronization primitives correctly.
no, this is false. Here's a video of dolphin, KDE's Qt 5 file manager, run over ssh on another computer: does that look like it's blitting pixmaps over the network ?
https://www.veed.io/view/d822f1b3-305a-4af1-8df6-61439515ccc...
When checking nload, this uses ~8 megabyte/second, I can let you imagine how much it would be to blit a constantly scrolling UI at 140 fps - I can assure you that even gigabit ethernet does not cut it unless compressing a lot :-)
It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.
it is minuscule, and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less. And it's while running a moderately image-heavy app with most likely room for optimization. One I often use is pavucontrol-qt: this one gives me less than 1MiB/s of network traffic when resizing it madly.
> It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.
when I set Xft.dpi to 144 on my machine and run the same thing over ssh I see this: https://i.imgur.com/JQhEcvG.png
icons are scaled, images are scaled, text is scaled... what is missing ?
Also, regarding zlib: I took a screenshot of this window and compressed it as png (which uses zlib if I'm not mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So more than twice as much as what X11 manages (and that is raw X11, IIRC there are X11 protocol extensions which also pass the X11 messages through gz, but I've never felt the need for that as things are already perfectly fast).
If you can show me any video-compression-based implementation that allows me to get this close to zero latency with zero image degradation (especially for text, you really don't want subpixel font AA to be video-compressed) and as little network overhead as what Qt gives over X11 I'll be super happy, but I really think it is unrealistic.
If 70% of the pixels are the same shade of gray, that’s not impressive at all. If you are serializing image data and storing it over the network, you can do better than uncompressed with virtually no CPU load increase. Even moreso if you’re doing multiple correlated frames.
> when I set Xft.dpi to 144 on my machine and run the same thing over ssh I see this: https://i.imgur.com/JQhEcvG.png icons are scaled, images are scaled, text is scaled... what is missing ?
Nothing.
That scaling is done by Qt, and has all of the aforementioned issues with regards to scale factor. That’s why we’re talking about X11; there is no “X11” way of handling scaling. X11 clients are responsible to scale things. Even events do not get their coordinate spaces scaled, either.
The point of this thread is not that you can’t scale UIs. It is that GTK+4 looks bad on low DPI monitors because it has stopped attempting to do pixel perfect UI and instead uses truly scalable layout and rendering. In the truly scalable world, 96 DPI is as blurry as 200+, only you don’t see it when there are more pixels.
That said, Qt has plenty of UI scaling bugs.
> Also, regarding zlib: I took a screenshot of this window and compressed it as png (which uses zlib if I'm not mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So more than twice as much as what X11 manages (and that is raw X11, IIRC there are X11 protocol extensions which also pass the X11 messages through gz, but I've never felt the need for that as things are already perfectly fast).
Yeah, because even raw X11 with pixmaps won’t redraw the whole screen at once. It will use dirty rects. When scrolling this could still be a substantial amount of data, but nonetheless.
As I suspected, as far as I can ascertain, it really is just shipping pixmaps. 8 MiB/s sounds very consistent with what bug reports are saying;
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...
This was changed in Qt 4.8, exactly like I remember it. But what I didn’t know was that XRender rendering was reintroduced in 5.10, because of this exact problem.
(Just to be clear, that means you get efficient SSH for most Qt apps, which have native mode enabled, from Qt 4.0 to 4.8, then 5.10 onward. A substantial slice of history to be sure, but more limited than it seems people think.)
If you’re on 5.10+, you should be able to get dramatically better performance with `-graphicssystem native`
> If you can show me any video-compression-based implementation that allows me to get this close to zero latency with zero image degradation (especially for text, you really don't want subpixel font AA to be video-compressed) and as little network overhead as what Qt gives over X11 I'll be super happy, but I really think it is unrealistic.
What can do better? Yes, it’s true, compressing text with lossy algorithms could pose a prob...
Here's how tigervnc looks on the exact same situation:
https://www.veed.io/view/0ca6898a-a535-4f0a-accb-b22e2e184b0...
Sure, it uses less bandwidth (between 2 and 2.5 MiB for the busy part of this video) but it is also full of artifacts (https://i.imgur.com/4QrV9xl.png), super slow compared to X11 and does not respect my local settings. no thanks !
Here's a snippet of my 2256x1504 screen, uncompressed:
https://files.catbox.moe/9k6cnm.png
Here's a snippet of my 2256x1504 screen from an OBS recording:
https://files.catbox.moe/va46ze.png
This is using x264 at just 0.5 MiB/s. Not even pegging a CPU core.
If you move really fast, then there are some artifacts during motion (same recording):
https://files.catbox.moe/myhnc7.png
...But they are not really noticeable in motion, and it clears up quickly.
I don't have a high framerate, high DPI display to test, but I'm guessing most people will only strongly care about one or the other since displays that do both are pretty expensive.
And yeah, chroma subsampling on subpixel rendering should impact legibility, but in practice it's difficult for me to tell any difference.
I've played around for a bit and I don't go above 1 MiB/s so far. I probably would need to play a video for that.
I wouldn't be able to stand something like this at all, it looks horrible to me. The text is all smudged.
And h264 is old, and I’m using software x264 with fairly modest settings. More modern general video codecs like h265, VP9, perhaps even AV1 can eek out slightly better fidelity at similar bitrates, at the cost of higher complexity. (But if it can be hardware accelerated at both ends, it basically doesn’t matter.)
And these codecs are designed for general video content… it would be instructive to see exactly what kind of performance could be achieved if using lossless codecs or codecs designed for screen capture like ffv1 or TSC2.
It would be… but honestly, there’s no point, because all I was trying to illustrate is that I sincerely doubt 8 MiB/s is the best that can ever be done for a decent desktop experience. Judging by Qt issue reports, it’s worse than what Qt used to be able to accomplish. If you really like your X11 setup, there’s no reason to change it, because it isn’t going to become unusable any time soon. Even if you switch to Wayland in the future, you should still be able to use `ssh -X` with Xwayland as if nothing ever really changed.
This is all a serious tangent. The actual point was that again, X11 doesn’t have any built-in scaling. All along, it was Qt 4+, GTK 3+, and other X11 clients that have been handling all of the details. And traditionally, it wasn’t good. And even contemporarily, it still has issues. Beckoning to the “way X11 did it” makes no sense because 1. X11 as a protocol or server never did anything 2. Even then, historically toolkits have had a lot of trouble dealing with it. The fact that you set the DPI for Xft specifically, which is just a font rendering library, hints at the reality: what oldschool X11 “scaling” amounted to in the 2000s was changing how font sizes were calculated. Modern toolkits just read this value to infer the setting, and it still isn’t good enough for many modern setups that Linux desktops want to support.
Web browsers scale bitmats if no other version is available but you can provide different bitmaps for different pixel ratios to avoid any blurryness [0]. Resolution independence is one thing that the modern web stack gets right - even 1-pixel borders/lines and space between elements generally works as expected for different scales.
Of couse *mobile* browsers made the IMO stupid decision of only activating these scaling features when you add a special tag to your HTML header.
[0] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
We already have this with `ResizeObserver` using the `device-pixel-content-box` option. [1]
[1]: https://developer.mozilla.org/en-US/docs/Web/API/ResizeObser...
Lol so make it look like crap the 99% of the time you’re not animating or transforming the text.
I'm not sure I follow the upstream reasoning, in either gtk/qt/firefox/chrome... I'm reading text all day. The UI is still built around 90%+ text, except in very few edge cases.
I'm using 4k monitors, and I'm still a minority. Despite this, at 4k, we're still several years away from the point where we can turn off hinting. Probably a decade away for universal support. A lot more if we include existing monitors.
Between 92 and 270 dpi text still looks bad without proper grid fitting. Under 120dpi we're talking about garbage-level quality. And between 250-300 the difference is still noticeable to make it worth it.
I'm not sure what these people are smoking.
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
There is a reason why Apple backpedaled on all that flat insanity for MacOS and iOS. Graphic designers and trendsetters usually know very little about usability, these are 2 completely different disciplines, and the Flat style was imposed by graphic designers, not UX people.
I’m sure it has something to do with them needing to justify their existence. No reason to have a designer if nothing has changed in the world of design. Programmers learn new languages (or go back to old ones), designers do the same with interface design principles.
It's not just programmers who complain about modern UI/UX trends. The Nielsen Norman Group, a UI/UX consulting group that was founded by HCI legends Don Norman and Jakob Nielsen, have written articles against the overuse of flat design (https://www.nngroup.com/articles/flat-design/).
Platform developers were incentivized to go flat because it lowered the cost of development and development time if developers were using fewer, simpler custom assets. At this time, both Apple and Google were bragging about how many apps were on their stores, and how fast they were growing, and neither wanted to fall behind the other.
But admittedly, my perspective was that of a third-party developer. I have no direct knowledge of why Microsoft, Google, and Apple all embraced this trend, and I have only anecdotal evidence that it made things more difficult for novice users. There could be a treasure trove of research showing that flat is better, but I have never seen it presented.
Is there any way to vote for keeping it? Does 'high contrast' mode possibly bring it back?
I find the Breeze theme really well done and its GTK port, Brise, is also very nice, to the point Gnome looks good in it.
There was just the KDE 4 era where I didn't like Oxygen at all (and indeed I used to change the theme to Fusion there) but that's over. KDE 3 was fine and KDE 5 is great. At this point, most things that are not Breeze don't look great to me now.
As for the customization and theme support, that's supported and it works well, they prove that it's nothing insurmountable too. KDE comes with themes that look like Windows 95, Motif, Adwaita, GTK 2 and other things and you can download more if you want.
I'd be curious to have a review of Breeze / KDE by Martijn.
[1] https://pointieststick.com/
I was a happy GNOME user before the version 3 fiasco. It took years to have a usable GNOME desktop again.
That's false, examine Strawberry 1.0.2 running in KDE 5. The menus have the wrong background colour. The font size is wrong.
By the way, qt6ct exists <https://github.com/trialuser02/qt6ct>, and it's even in Arch's repositories right now. The main issue is that it's useless, because there are simply no Qt6 themes out there yet and KDE still does not support Qt6 so you have to force qt6ct manually.
There must be some way to make this work on other Plasma Mobile distributions.
[edit]
Can confirm keyboard works in FF on Manjaro, but it has other jankiness (e.g. it seems to think it is much wider than the screen).
https://bugzilla.mozilla.org/show_bug.cgi?id=1579348
There's some minimul visual elements, eg if you choose the tabbed layout.
So the comparison for XMonad wouldn't be all of KDE or Gnome, but just how those two choose to decorate their windows. Eg their 'minimize' and 'close' buttons and window borders.
To be slightly more serious than my original comment was:
If you can rethink your UI in such a way that some things can become invisible, that can be a very ergonomic choice.
To give a better example: look at the bad old days of C and memory management via malloc and free.
One direction you can go into is Rust. Compared to C, Rust has a greatly improved user interface [0] for handling memory allocation.
Another direction you can go into is Python. Compared to C, memory management is basically invisible in Python. It just works.
Now, of course, Python gets to simplify its UI by essentially removing control from the user. But for many programming tasks, that's a good trade-off to make.
Similarly, iOS gets to drop the UI elements associated with manipulating windows, because it puts every app in full screen. (And XMonad greatly discourages you from fiddling with Window placement and layout manually; but has some less-intuitive less-discoverable means to do that manual fiddling, if you need it.)
[0] The user of Rust being typically called a 'programmer'.
That's false, see https://news.ycombinator.com/item?id=26582009
Also in System Settings 5.24:
• switch to sidebar view and examine the buttons at the top of the sidebar
• go Workspace → Workspace Behaviour → Desktop Effects and examine the buttons at the right
• go Workspace → Workspace Behaviour → Virtual Desktops and examine the buttons at the right
• go Workspace → Workspace Behaviour → Activities → Activities and examine the buttons at the right
• go Workspace → Window Management → Window Rules and examine the buttons at the right
• go Workspace → Startup and Shutdown → Autostart and examine the buttons at the right
• the most egregious example: go Personalisation → Regional Settings → Formats and examine the whole dialogue, it is entirely made of frobable regions
• go Network → Connections and examine the buttons at the bottom of the connections list
• go Hardware → Printers and examine the buttons at the top of the dialogue
I do not understand what goes on in the responsible programmers' heads. Why does the implementer reinvent buttons badly, instead of using a standard button? Is there no one reviewing? Is there no one saying "no, we cannot burden a KDE user with this bad usability, I will not merge this code"?
I abandoned KDE during the KDE-3 (edit: to 4) migration apocalypse, when nothing worked as it did before, or at all, and everything looked like it needed at least another year of refinement.
Is this settled and past now? Is KDE still adament on making virtually every other pixel configurable?
Now the world seems more mature: Cinnamon, KDE and The Ubuntu favor of Gnome seem to work very well (Each time I see Ubuntu Gnome I think "wow, that looks good!"). Xfce have been rock stable and reliable for years and years for people who like it. Still looks the same as when I discovered it 17 years ago. I've heard people like the current versions of Gnome and that the latest versions are better.
And yes of course everything is still highly customizable in KDE. There are people who make it look like old Windows, some who make it look like Mac and both work quite well. But you are not forced to customize, the default are top notch and that's what I use. They've been working on the settings center which was a mess and which is still not perfect, but it's gone to the point where it is one of the best I've seen. In comparison, the Windows' several setting centers are a huge mess and the Gnome settings are lacking, and you need to install Gnome Tweaks to have some useful stuff and now you have two settings panels.
I used KDE 4 from the first alpha versions (~2007) and never quit using it. However, I had friends who didn't like the mess that KDE 4 was in the beginning and who were very verbose about the good KDE 3 features they were missing and the new behavior they didn't like.
However, at some point they saw that the very few things they were still missing were neglectable compared to the good things that KDE 4 brought with it.
Nevertheless, 2007 to 2012 were 5 years during which it wasn't easy to be a KDE user ;-)
He mentions KDE in the blog post:
> The feedback I get is that I should move to QT/KDE, but I think that theming has had the same issues for way longer already and I do really like the Gnome HIG.
Every time I see a comment like that, I try again KDE, only to leave it 15 minutes later because it is a huge mess. Everytime I try configuring the panel to my liking nothing goes where I want to and I end up with widgets everywhere.