Libadwaita: Splitting GTK and Design Language(tesk.page)

118 pointsby butzvor 2 Jahren187 comments

Libadwaita: Splitting GTK and Design Language

https://tesk.page/2024/06/03/libadwaita-splitting-gtk-and-design-language/

192 comments

kelnosvor 2 Jahren

The funny thing about all this is it's just history repeating itself. Back in the days of GTK2, there were a handful or two of "libgnome"-prefixed libraries that GNOME apps tended to use, but non-GNOME apps (that used GTK) tried to stay away from, in order to avoid depending on large bits of the GNOME desktop. The problem with that, of course, was that people in that position either got by with reduced functionality, or had to write their own code to do things that many people considered should be a part of the toolkit.

The GTK developers did recognize that a lot of this stuff was integral to a UI toolkit, and so most of the functionality in the various libgnome libraries was moved into GTK for GTK3.

And now apparently we're going backward again. No, I get, it's not the same situation. They are focusing more on "design language" than functionality: for example, the printing functionality that was moved from libgnomeprint (or whatever it was called) into GTK3 is staying (which makes sense), but menu bars (which have been in GTK since the beginning) are going away because GNOME doesn't use them anymore.

But that's a part of the problem; it seems like their rubric is "if GNOME doesn't need it, then it should be deleted"[0], coupled with the idea that many new design language elements should be GNOME-only and live in libadwaita, even if a more general audience would benefit from those elements.

As a developer of GTK-based applications for a good 20 years now, I honestly can't recommend GTK for new projects outside the GNOME umbrella. The problem is I'm not really sure what to use instead. Qt is really the only other major cross-platform toolkit, and does seem like a more stable base, but I don't want to do C++, and bindings for other languages aren't very ergonomic. (And toolkits like wxWidgets are just abstractions on top of other platform libraries.)

What I really want is a Rust-native UI toolkit library that does its own drawing, but can consume GTK3 themes. To me, the big issue is that of "native look", and I don't want Yet Another UI Toolkit that allows people to build apps that don't fit into my desktop at all.

[0] Note that quite a few things, like GtkDialog as a notable example, didn't get removed for GTK4, but have been deprecated and will be removed in GTK5.

grumpyprolevor 2 Jahren

Are they really deleting menu bars? Wow. Maybe in ten years time they'll figure out that two hamburgers is better than one; and that they'll need names like "File" and "Edit".

sameerdsvor 2 Jahren

No they are not. The GtkMenuBar widget got dropped because a replacement already exists. Another comment below provided the reference:

https://docs.gtk.org/gtk4/migrating-3to4.html#gtkmenu-gtkmen...

I wish the GP would clarify this particular confusion in their comment! The way it stands, the comment makes these projects sound outright whimsical, which is clearly not true.

AlienRobotvor 2 Jahren

Why does everyone have to make it so hard? All I want is literally the widgets Windows had 20 years ago in all platforms. That's all.

I don't even need the ribbon.

And now GTK has sliding tabs with animation effects I have to install tweaks to turn off. To begin with, why is tweaks even a thing? This should all be in the normal control panel! I can't believe I used to hear criticisms about the windows registry when in linux I need to install 2 different regedits to make the GUI look bearable.

This is why people use electron.

crashdancervor 2 Jahren

It is in the normal control panel, see "Reduce Animation" in the accessibility page.

>All I want is literally the widgets Windows had 20 years ago in all platforms.

This seems to me a very bizarre request. I mean, you can literally do that already: write Windows apps using the old user32 APIs and run them in Wine. But then they will look and behave really out-of-place on non-Windows platforms when all your other apps are using the native toolkit.

AlienRobotvor 2 Jahren

>write Windows apps using the old user32 APIs and run them in Wine

Honestly, to me this is the actual choice. I've tried using graphics gale (a win32 app) and fire alpaca (a qt app) on linux. Fire alpaca didn't work. Neither the app image nor the windows version on Wine. But graphics gale worked flawlessly.

The future of crossplatform is just everyone writing Win32 API apps, just like every language communicates by a C api.

crashdancervor 2 Jahren

I can't agree with that, Wine has been around for a long time and it never really took off for that use. IMO the future of cross-platform is still the web, because "cross-platform" also includes smartphones now.

>Neither the app image nor the windows version on Wine.

That is more the developer's fault. AppImage is a very broken distribution method and IMO it should never be used.

M95Dvor 2 Jahren

I'm doing exactly this. To me, most native apps look out-of-place and I avoid if possible. I just wish running apps in wine wasn't so slow compared to windows.

crashdancervor 2 Jahren

>To me, most native apps look out-of-place and I avoid if possible

That doesn't make sense, "out-of-place" here means with respect to the rest of the system and the shell. Doing things that way is guaranteed to result in an inconsistent desktop, so maybe you can understand why that won't really be a supported thing.

For a while I actually used to do something similar to what you're doing. In the early 2000s when OS X was the new thing, I had gotten used to the Mac. So for a while I would only use Qt apps with a Mac-style theme and I would get really upset if something didn't work with it. But I stopped eventually because I realized I was being unreasonable and frustrating my own computer usage for no benefit. IMO it's helpful to recognize when you're in a harmful thought process and break out of it.

sameerdsvor 2 Jahren

> for example, the printing functionality that was moved from libgnomeprint (or whatever it was called) into GTK3 is staying (which makes sense), but menu bars (which have been in GTK since the beginning) are going away because GNOME doesn't use them anymore.

You make it sound like menu bars are removed from GTK4. But I read the article multiple times to find where it says so. From what I understood, menu bars will stay in GTK4 but will not be represented in libadwaita because GNOME doesn't need them.

HumanOstrichvor 2 Jahren

I was with you until you suggested rewriting everything in Rust.

[deleted]vor 2 Jahren

crashdancervor 2 Jahren

>menu bars are going away because GNOME doesn't use them anymore.

Where did you hear this? This is misinformation, menu bars aren't going away. The API is just changed in GTK4: https://docs.gtk.org/gtk4/migrating-3to4.html#gtkmenu-gtkmen...

>GtkDialog as a notable example

GtkDialog was deprecated because other changes made it now trivial for any app to re-implement dialogs with just a few CSS classes, and it's more flexible that way too.

>a Rust-native UI toolkit library that does its own drawing, but can consume GTK3 themes

This is never going to happen unless you re-implement nearly all of GTK3 in Rust with the exact same widget hierarchies and all the quirks of its (outdated) rendering model. Why would you want this anyway? GTK themes aren't particularly special, it's just CSS.

nextaccounticvor 2 Jahren

> Why would you want this anyway? GTK themes aren't particularly special, it's just CSS.

So that non-gnome apps can blend reasonably well in Gnome (at least the colors)

But, if it's just CSS, then at least an electron or tauri app can make use of it I guess?

crashdancervor 2 Jahren

You don't need a full CSS stylesheet just to change some colors. And no, you can't take CSS from a GTK app and use it with a web app or vice versa, the layout system and the elements/classes aren't compatible.

nextaccounticvor 2 Jahren

The trouble is that I don't want to hardcode the colors in the app, but to learn which theme the user is using and adapt the application to use the colors of that theme (and other features if possible)

If the toolkit supported this automatically, it would be easier to achieve this

crashdancervor 2 Jahren

That isn't possible in any scalable way in any toolkit. There's a good reason all the major commercial operating systems basically only support light/dark mode and maybe a couple other theme variants/options and that's it. I think you are underestimating just how complex the style is for a non-trivial framework/toolkit/application and how it's full of interdependencies and platform quirks.

brntvor 2 Jahren

Yet in the Gtk2 days this was trivial and universal. What changed?

crashdancervor 2 Jahren

I have no idea what you're referring to. Nothing changed, because it didn't actually work in the GTK2 days either. Actually it was worse then. Themes would break apps constantly. I remember always having to edit gtkrc when something broke, and sometimes that wouldn't even work or the app would just crash entirely. It was even more "fun" if a theme crashed the window manager or the panel and then you had to switch out to a VT to fix it.

brntvor 2 Jahren

You say you have no idea what I'm referring to, and then proceed to talk exactly about the feature I was refering to.

This together with your other inconsistent comments here make me doubt your sincerity. You seem to be either tracking Gtk/Gnome Dev closely or are a Dev, but then pretend to speak for users of Gnome and ask others not to speak for users of Gnome. You seem to be in some sort of damage control.

Gnome 2 came with themes, that worked really well, and rarely broke. Denying it only makes you look silly.

crashdancervor 2 Jahren

The themes didn't work well for me and I've talked to lots of other users who had the same experience. It was a broken feature and it was correct to remove it. If you're denying my experiences and telling me they're not real then you are the one who is pretending to speak for other users of GNOME. So please cut that out.

I don't follow development closer than anyone else, I just periodically read the dev blogs and changelogs like any user should. The difference is I don't assume that developers are hostile entities that are apparently spending all their spare time being passionate about their open source project just to annoy some users? Come now, think about it, isn't that a ridiculous notion? I mean really, I'm complaining about a broken feature and you're saying that's damage control. Wouldn't it be more "damage control" to insist that GNOME 2 somehow fixed all its theming bugs by doing something mysterious and unexplainable that no one can figure out 20 years later?

When I comment I try to counter the negativity and focus on making constructive comments, I strongly urge you to do the same. It's not like the developers are aliens that can't be understood by mortal humans, if you really need something explained you can just go in the Matrix channel and (respectfully) ask them questions.

brntvor 2 Jahren

This thread is full of people trying to share experiences that you seem to not allow, Gnome 2 themes working well (for them) being one of them. Sharing the observation of a downward trend _is_ constructive. Trying to invalidate such observations is not.

Considering Mate and Cinnamon still exist and are healthy projects would indicate there's many developers who share this sentiment. Nobody maintains older versions of KDE, apart from a single distro using Trinity (KDE3). That's quite a contrast as well.

I wasn't, and very few are, treating developers hostilely, we are just sharing whatever experience we have. That this isn't altogether positive, is not our fault or responsibility. That's the 'risk' you run creating products for end users who just use it. Nobody forces anyone to code for them.

Please stop putting words in my mouth, nowhere did I write that Gnome2 was bug free.

I suggest you take your constructive criticism to hand yourself.

bonzinivor 2 Jahren

> Gnome 2 themes working well (for them) being one of them

For some definition of working well. What I remember was debugging a case where the KDE theme for GTK (that is, to make GTK look like KDE) wanted to fork() and exec(), and that caused bugs if you initialized GTK at a slightly different place in main() than what most programs did. I had to add a special case to QEMU just for that...

Proof: https://gitlab.com/qemu-project/qemu/-/commit/a59629fcc6f603...

Even if something "works well" for some people, it does not mean it is not (in retrospect - no offense intended to the original authors) a steaming pile of crap.

crashdancervor 2 Jahren

>This thread is full of people trying to share experiences that you seem to not allow, Gnome 2 themes working well (for them) being one of them.

The mistake you are making here is that someone not experiencing a bug does not invalidate the existence of that bug. You can be using a feature and it can be working okay for you but if it causes bad problems for lots of other people or causes maintenance issues then it will get the axe. This is not to disallow your experiences, but to say there are reasons the developers may not consider your experiences to be representative of a typical experience, or ones that are even worth acknowledging. Because ultimately the developers are the ones who have to listen to all the complaints from everybody and decide which ones are valid -- users can't and don't do that, if they did then they would be developers.

>Considering Mate and Cinnamon still exist and are healthy projects would indicate there's many developers who share this sentiment.

That doesn't indicate it though, Mate and Cinnamon don't use GTK2.

>Nobody maintains older versions of KDE, apart from a single distro using Trinity (KDE3).

But you just disproved your own assertion with an example! If there's one even example then that means a certain percentage of users aren't happy.

>I wasn't, and very few are, treating developers hostilely,

I can't agree with this, I have read several hostile comments in this thread accusing GNOME developers of "sabotage" and things like that. I apologize if you aren't doing that.

>is not our fault or responsibility.

I can't agree with this either, if you aren't even using GNOME but you continue to complain about it then that is completely your responsibility. At some point you have to accept responsibility for your own choices. If that means you have to pick up GTK2 and fork it then that's what you have to do. You can't fault GNOME for not doing that just to please MATE users or whatever it is, when those users would probably still be unhappy with modern GNOME anyway.

>nowhere did I write that Gnome2 was bug free.

But that seems to be exactly what you were suggesting in regards to themes? What am I missing here?

tristan957vor 2 Jahren

GtkDialog is just a GtkWindow with a few things done for you. It wasn't exactly a pleasant API to use either.

fngjdflmdflgvor 2 Jahren

>As a result, GTK and GNOME’s design language clashed together. Instead of being as general-purpose as possible, GTK as a cross-platform toolkit contained an entire design language intended to be used only by a specific desktop, thus defeating the purpose of a cross-platform toolkit.

This is one of the things I like about Flutter. It supports both Material and iOS UI guidelines. There is also an ongoing effort called Blank Canvas[0] to provide easier support for creating arbitrary UI themes (although you can already do this albeit more difficultly). Being that Material looks awful to me (as an Android user, even) I'm glad that they support different UI Designs/guides.

[0] design doc: https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXF...

fl0kivor 2 Jahren

The only thing worse than modern Material is when there was a multi-year (?) period where Google didn't think buttons needed any affordance indicating they were buttons, not in shape, contrast, color, etc. and with touch UIs you don't even get hover feedback like you would on the web.

Reading between the lines, I can see that Google was inspired by the post-skeumorphic minimalism of iOS, but took the wrong lessons away from it. Some of that has been walked back, but far from enough.

fngjdflmdflgvor 2 Jahren

To me Material looks like Google looked at iOS and compared it to their then rectangle-box based UI and said "Our UI is too bland compared to Apple. We must need tons of border radius and padding. And big splash animations when you touch a button!" Some people used to look down on Apple's UI as "fisher price" but Google has long taken that crown in my book. When I make flutter apps for side projects I just use the Apple based widgets (called Cupertino [0]).

[0] https://docs.flutter.dev/ui/widgets/cupertino

pentagramavor 2 Jahren

I remember being annoyed by those text buttons, looking at the latest iteration of Material, it looks like they keep the "text" button style but as a secondary option https://m3.material.io/components/all-buttons

Looking at the examples I think that it works in some contexts, but is a personal feel that I have.

arghwhatvor 2 Jahren

Well, there are caveats to flutter. One, the packages are clearly Material first, with Cupertino not having the same coverage and integration. There's a lot of common iOS UI constructs that are missing or incomplete, and Material is the base-type: There's Scaffold, which is material, and CupertinoPageScaffold, which is the iOS version. Widgets also don't necessarily mix - in cupertino land you need to use cupertino scaffold and page with their transitions, as they have hardcodes dependencies on each other.

Second, cupertino is glitchy and just... wrong in so many aspects. Sizes, placement/paddings, animations... Placing an icon-only button in the trailer of an app bar doesn't align it with anything, and something as simple as a page animation is completely wrong: Click on a note in the Notes app, and the title and content of the new page follows each other - in a flutter app, they're on completely independent trajectories. Not to mention that mimicking a photo gallery with pinch zoom, dismiss and swipe to navigate is borderline impossible with flutters gesture stack, and existing packages and built-in Widgets don't get close[0]. Its handling of the screen rotation animation is also horrendous as it just stretches whatever widgets were present with no control.

In my opinion, cupertino is just a weak lookalike used to lure developers in, but isn't really good enough to convince users in a "real" app. The real utility of cupertino and its packages are in adding necessary iOS widgets to material or custom UI apps, like share panes.

[0]: Apple gets that one a bit wrong too though. Try to zoom in in the right edge of a picture in the Photos app, and start a swipe left from the middle of the screen. When the next image starts to show on the right side of the screen, change direction to swiping right. The previous image will come in from the left, but with a completely glitched out transition. Flutter is way worse though.

fngjdflmdflgvor 2 Jahren

I appreciate you writing this. These are all valid criticisms of Flutter. Especially the bit about pinch-zoom. Proper zooming is a long missing feature from flutter. There is InteractiveViewer[0] but it does not actually cause a re layout of it's children and it also doesn't respect the ScrollBehavior of the platform. There is also Two Dimensional Scrollables[1] which is a new official Flutter package which could theoretically be used to create a better zoom widget, although this hasn't been done AFAIK. There are some packages that can do this though.

As for Cupertino being a bad reproduction of the real iOS behavior, is it really that noticeable to non-developers? If so, that is very sad to here. I actually found out about Flutter via an open source app that was using Cupertino. I really liked the feel of the UI so I looked at the source and found out it was using Flutter. I feel like most Android users do not care about apps feeling "native" as the definition of a native UI feel has changed so drastically over the past decade or so on Android, with major apps like WhatsApp, Youtube, Gmail and stock Samsung apps each having almost completely different UI designs. If there are behaviors in Flutter Cupertino that would confuse iOS users (not just look slightly different) that does in fact sound really bad.

>Its handling of the screen rotation animation is also horrendous as it just stretches whatever widgets were present with no control.

FWIW I can't reproduce this in my own Cupertino app. For example a 3 column grid becomes a 6 column grid when rotated.

[0] https://api.flutter.dev/flutter/widgets/InteractiveViewer-cl...

[1] https://pub.dev/packages/two_dimensional_scrollables

arghwhatvor 2 Jahren

> There is InteractiveViewer[0] but it does not actually cause a re layout of it's children and it also doesn't respect the ScrollBehavior of the platform. There is also Two Dimensional Scrollables[1] which is a new official Flutter package which could theoretically be used to create a better zoom widget, although this hasn't been done AFAIK. There are some packages that can do this though.

I have played with InteractiveViewer, but you can't easily get BoxFit to behave right (if you zoom in on a widget having letter-/pillar-boxing, the letter-/pillar-boxing shouldn't be part of the content you're zooming into!), and it does not stack well with pages and dismissables. There are packages that try to hack around this (poorly) by monitoring position and toggling the activity of parent widgets, and there are some that have their own custom version of the whole thing (with usually quite primitive zoom behavior as a result), but I haven't found any that work well.

My test for this was that even though I could navigate a gallery page with zoom and dismiss reasonably well, my wife's much faster paced zoom/swipe navigation basically never worked. I also tried going the fully custom approach, with my own scrollables, gesture handling and transforms, but it was too much work in the end...

It would definitely be interesting to see if the two_dimensional_scrollables thing sorts it out. I'm not sure all the issues can be fully fixed without a change to flutters Gesture system though - being unable to distinguish pan from

> As for Cupertino being a bad reproduction of the real iOS behavior, is it really that noticeable to non-developers?

I recall showing a cupertino based app to a friend, and the moment he saw the app bar transition he just went "ew what is wrong with that", and the app bar blur looking different didn't help either.

For many of the other things, it just puts more work on the developer - like the trailer thing, where I ended up having offset the widgets pixel by pixel until it aligned with other apps and looked right.

The more consistent UX on iOS (note: "more", not "fully") makes it pretty easy to see when something sticks out, and transitions and their tracking in particular is something that has always been a few notches above the average on Apple devices.

Another thing that sticks out a lot are hero transitions. Native iOS apps tend to have content nicely expand from e.g. a small grid to a larger page. In Flutter, this is a pain because you might need to transition between both aspect ratios and fitments (e.g., BoxFit.cover to BoxFit.contain), while the Hero widget doesn't really give you an easy way to know both the source and target dimensions ahead of time to calculate the intermediate geometry and fitment, only the source and current dimensions. The best I have managed gets it mooostly right when the aspect ratio of the content ends up matching the aspect ratio of the screen, but it's visibly wonky when that's not the case - the image first expanding, then contracting again to obtain the right borders. The same goes in the other direction, with the widget dancing too much when dismissed.

I feel that a lot of things just bail out to a more material-style crossfade, which is not very Apple-esque.

> FWIW I can't reproduce this in my own Cupertino app. For example a 3 column grid becomes a 6 column grid when rotated.

Look at the widgets during the rotation. If you rotate from portrait to landscape, the widgets will first be stretched as flutter is transforming a render from the "before" position towards the new dimensions. Then, slightly past halfway it snaps to instead transforming an "after" render with the GridView relayout, which starts slightly too narrow and grows to the proper dimensions. Leaving the app in one orientation and returning in another can also lead to cursed frames. :)

While bailing out to a cross-fade for heros is bad, I wish Flutter would just only cross-fade for the rotation. Stretching is just... Cursed. At the same time, we should have more control so we can do things like the iOS camera app and react by just rotating some widgets in-place...

---

Disclaimer: It's been a year or so since I played with flutter last, and I am not currently during UI work so I might be slightly out of date and there might have been improvements since I looked at it last. I should also note that I have personally now also started to be able to pick apart many first-party Apple apps, breaking them horribly in numerous ways because I have gotten familiar with the problems. It's just that they usually don't break for regular end-users.

infotainmentvor 2 Jahren

Ehh… “supports” is a strong word when talking about Flutter’s iOS theme.

The last time I tried it, it fell into some kind of UI uncanny valley — it looked mostly like iOS, but there were enough little things off that it just felt wrong.

BoredPositronvor 2 Jahren

I hope cosmic puts an end to this neverending discussions about bad decisions from the gnome foundation. They can go under for all I care. Overall I truly believe they did a disservice to the whole Linux Desktop and the community over the last 15 years.

w4rh4wk5vor 2 Jahren

Completely agree.

The fact that there are still apps where the hamburger menu cannot be used properly without a mouse caused me to switch to KDE. Having certain menus accessible via Alt + Letter shortcuts is an accessibility requirement for me.

pantalaimonvor 2 Jahren

The article sounds more like Gnome has learned from their mistakes and makes Gtk4 more general purpose with the Gnome specific bits contained in libadwaita

Xelbairvor 2 Jahren

>gnome devs

>learning from mistakes

pick one, and only one. They are the most stubborn bunch in existence.

BoredPositronvor 2 Jahren

Looks rather like rhyme... https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui

crashdancervor 2 Jahren

>bad decisions from the gnome foundation. They can go under for all I care.

This won't help anything. GNOME Foundation doesn't really have anything to do with the development of GNOME or GTK. The Foundation is just the financial entity that does fundraising and owns the hosting. Actual development is decided by developers, i.e. the volunteers who show up to maintain it.

>Overall I truly believe they did a disservice to the whole Linux Desktop and the community over the last 15 years.

Speak for yourself please, personally I've enjoyed GNOME for the last 15 years. There's no need to make these kind of normative statements.

BoredPositronvor 2 Jahren

I did speak for myself[1], but it's nice that you can have your opinion, while mine is considered void. If the gnome foundation is useless as you described it doesn´t really matter to you if they go under or not right? Your reaction is a repeating pattern when interacting with the gnome dev community, so you're just reinforcing my frustration. ¯\_(ツ)_/¯

[1] I hope... , ...for all I care, Overall I truly believe....

crashdancervor 2 Jahren

If their funding source went under then I imagine they would start another one or try to get picked up by some larger organization like Linux Foundation or SPI. So no I don't think it would be that much of a problem.

>but it's nice that you can have your opinion, while mine is considered void.

It's perfectly fine to not like GNOME but wishing for them to be destroyed is a hostile and destructive opinion. If you don't want negative reactions then please try to recognize when that happens and just don't say those things. I don't wish that your preferred desktop get destroyed, is it too much to ask for you to stop wishing that upon me?

I mean, come on. Of course there is a repeating pattern if you insist on saying nasty things and then you find people always get upset at you. What did you expect would happen?

BoredPositronvor 2 Jahren

Fifteen years ago, I wasn't hostile and I am not hostile now. However, now I really don't care about Gnome at all. As I mentioned, I wouldn't mind if they went under. That's not wishing for their downfall; it's simply indifference.

You need to work on your reading comprehension because you're twisting everyone's words in your comments, not just mine.

crashdancervor 2 Jahren

(1)

[deleted]vor 2 Jahren

cl3mischvor 2 Jahren

Isn't Cosmic based on Gnome? If yes, at least they did a service to enable the Cosmic DE.

supercheetahvor 2 Jahren

They take some aesthetic inspiration from Gnome, but Cosmic inherits none of its code since it's being written in Rust.

NoGravitasvor 2 Jahren

Oh good, another toolkit that won't have usable bindings for less popular languages, meaning another toolkit that I won't be able/willing to use.

davet91vor 2 Jahren

The new Cosmic is written from scratch in Rust with the iced GUI library.

cl3mischvor 2 Jahren

Good to know. I was going of a sibling comment with a link to their Github repo, in which Cosmic is described as a Gnome skin.

pid-1vor 2 Jahren

What's cosmic?

thesuperbigfrogvor 2 Jahren

A desktop environment that System 76 is making: https://blog.system76.com/post/cosmic-the-road-to-alpha

ianlevesquevor 2 Jahren

Yet another desktop environment https://github.com/pop-os/cosmic

9devvor 2 Jahren

Looks like yet another uncanny clone of MacOS UI

erikpukinskisvor 2 Jahren

What disservice?

jeroenhdvor 2 Jahren

Yet another GUI library won't fix anything. It'll just add one more platform that other desktop environments need to theme to look normal.

Gnome was right to take a uniform design, the same way KDE did. Gnome applications look weird on KDE, the same way KDE apps look weird on Gnome, but that's such a non-issue. Every Gnome application has an alternative in almost any other widget style.

The "damage" they have done seems to mostly be people who don't like Gnome being agitated by Gnome's success, forcing them to use Gnome applications because their ecosystem of choice doesn't have a native alternative. If Gnome were as bad as some people think, it would've already shrunk to irrelevance to the point the complains would go away.

BoredPositronvor 2 Jahren

Being responsible for fragmenting the entire desktop environment and causing the creation of forks like Cinnamon, Unity, Mate, Pantheon, Budgie, Deepin, and Cosmic is not the kind of success story I want to be associated with. The amount of development time wasted is appalling besides that I wouldn't consider my human interface guidelines a success when 8 out of the top 10 most downloaded extensions are created to get rid of them making the system bearable for normal users.

jeroenhdvor 2 Jahren

Why would development time be wasted? Most of these forks are "I like the basis, but I want to tweak it a bit". To each their own.

I suppose Unity was a bit of a waste now that it's been mostly abandoned for standard Gnome these days. Then again, Canonical has a history of starting forks and alternatives and releasing them early, eventually ending up replaced by competitor projects that learned from their mistakes.

The fact KDE's design hasn't inspired much in terms of forks seems like negative signal to me. Very few people who want to implement things their own way seem to be using KDE as a basis. I don't know if that's because KDE is more difficult to work with or if KDE people just aren't the ones that like to experiment with their own vision, but nobody forking the project is not necessarily a good sign.

That said, KDE did just finish a complete redesign, with a Gnome-like desktop switcher, a Gnome-style (or rather, macOS-style) dock, altered default behaviour for mouse clicks, touchpad taps, and the way scrollbars work. Perhaps it'll inspire the next generation of tinkerers now that the redesign is out.

BoredPositronvor 2 Jahren

KDE gives you the freedom to do whatever you want with it that's why they don't need to be forked. They actually learned from their community after the backlash they got for kde2. Oh and also gnome has no dock...

That said you seem to misunderstand the gnome "workflow" if you think the new KDE features are copies or similar to the gnome workflow™. I give you that they are visually similar but most of the concepts you described were shaped by xerox.

c-hendricksvor 2 Jahren

I wasn't around for KDE2, what was the backlash? Looking at Wikipedia, it looks like it introduced a lot of my favourite parts of KDE:

- KIO

- KParts

- KHTML

fl0kivor 2 Jahren

Valve chose KDE for SteamOS, including as the desktop mode on the Steam Deck, a device sold to be so user-friendly that it can compete with home consoles including the Nintendo Switch. (Not saying that desktop mode itself is as foolproof as a console interface, just that it can't be a total usability disaster for people who bought a Steam Deck for gaming and not as a Linux desktop)

Emphasis on chose KDE, not forked KDE. I agree with people who say that KDE has gone to great lengths to be customizable enough that you can mostly set it up the way you want without forks, extensions, or even registry editors.

I can't speak to how difficult Valve found it to work with KDE, but it says a lot that they still chose it overall. It's not often we get such a clear positive signal from a company that invests so heavily in user experience.

tristan957vor 2 Jahren

Every single desktop you listed has a completely different user experience than the next, except for maybe Cinnamon and MATE. They are solving different problems. Just because a desktop uses GTK doesn't mean it is a fork of GNOME.

BoredPositronvor 2 Jahren

But they are literally a fork of gnome.

sitkackvor 2 Jahren

The GUI fckshtry on Linux is exactly "The Tyranny of Structurelessness". Linux spent billions copying windows poorly when it could have spent 1/1000th of that being better than Windows by not copying it in the first place.

talldayovor 2 Jahren

This is what the cathedral versus the bazaar is all about. You either make everyone angry by rejecting common-sense changes because you insist on being different (GNOME) or make everyone angry by accepting every kitchen-sink patch available until your desktop breaks (KDE).

I guess people perceive it as fuckshittery because there's no advertising or marketing team to help assuage the missing features. Comparatively, Microsoft Windows struggles to maintain any less than a dozen GUI frameworks despite being a centrally managed product sold by one company. When you look at it that way, it's kinda miraculous that Linux ends up having it's cake and eating it too.

anthkvor 2 Jahren

The C# UI of the week :D

LeFantomevor 2 Jahren

This is both a fair comment and a little misleading at the same time. It is more of a communication problem really.

For desktop apps, there has been Windows Forms, WPF, WinRT, UWP, and now WinUI. You could even argue that MAUI is the latest.

Sounds like a lot! And it is.

That said, it is more of a naming and communication problem than a technology one.

Things like Qt and GTK have undergone similar or even worse disruption but it does not seem as bad because of the naming.

Take WinUi. It is really the exact same GUI API as UWP. Mostly a namespace change. And UWP was just an attempt to bring the WinRT API to more platforms. The Open Source UNO Project allows you to use WinUI cross-platform.

And even in MAUI, it uses WinUI on Windows.

Really, the C# GUI API for desktop apps has not changed since 2012 ( Windows 8 ).

And the core UI concept is XAML with bindings and MVVM. Those were all introduced with WPF way back in 2006. While WinUI and WPF are not the same API, they are not so different from a dev perspective ( use not architecture ).

And of course WPF is still supported. In fact, Windows Forms is not only fully supported but gets updates now and then. Windows Forms was released in 2002. You can start a new app in Visual Studio today on the latest .NET that uses the same GUI framework as an app in 2002! That is actually some pretty damn impressive UI framework stability when you think about it.

Now detractors may be screaming. What about Silverlight? Or Xamarin Forms, or Blazor? Or Web Forms?

Well, I am not going to make this longer going through web frameworks. I hope we can all agree there has been a lot of churn there on every stack. That said, Web Forms, introduced in 2001 are still supported! ( on .NET Full Framework ).

And on mobile, Xamarin Forms is just the old name for MAUI. This also uses XAML, so it has a lot in common with everything from WPF to WinUI.

Anyway, I wish it was all better too. But it is not as bad as it seems. Mostly, Microsoft just sucks at naming and messaging.

anthkvor 2 Jahren

Gnome never tried to copy Windows except for Bonobo/Corba.

KDE OTOH tried to combine every GUI into a single place, making it usable to any user.

Mac OS? RiscOS? Be? Die-hard Unix with Motif? KDE1 (and more 2 and 3) allowed that into widgets/window decorations and much more.

But I prefer stuff like IceWM+XFE if I had to choose a desktop like environment.

No desktop icons, the menu has shortcut entries and a subdir navigator allowing you to open anything with either the file-manager or xdg-open. It has a virtual desktop switcher, a task switcher, a systay and a clock.

fnalelalvor 2 Jahren

Good. What Linux needs is libwidgets, i.e. GTK, to have widgets for desktop applications. And, separately, libwankery, where the GNOME geniuses can implement whatever nonsensical "design language" they want for their 0.003% of the market user base.

mseepgoodvor 2 Jahren

So is it a new kind of libgnomeui? https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui

c0l0vor 2 Jahren

Ouch, there's some bitter irony in all of this. See https://wiki.gnome.org/Attic/ProjectRidley for an explanation of the goals of this project, which now seems to be what GTK is trying to get away from again.

cardanomevor 2 Jahren

Not really?

> As Owen said in a recent GTK+ meeting, when looking over the list of APIs that we are discussing here, there are basically three categories:

> A) Cross-platform API - things that make sense on Windows / OS X

> B) X / freedesktop.org-specific API

> C) GNOME-specific API

> APIs in category A. are clearly suitable for moving to GTK+, APIs in category B. may or may not be suitable, and things in category C. are better off in a GNOME-specific library.

So even back then the official stance was that GNOME specific stuff belongs in external libs.

tristan957vor 2 Jahren

I find the lack of relevant discussion on the article pretty disturbing. Everyone is focused on things that the article never even brought up. Many comments can simply be summarized as "I hate GNOME," which is not at all useful to the discussion.

Because the design language got split up from GTK, that enables desktops like Cinnamon, MATE, and XFCE to work together on a libxapp which implements the design language common to those desktops. Unfortunately no work has started on that yet, but I hope to see it soon, similar to xdg-desktop-portal-xapp.

How people don't see this as a complete win is very strange to me. GTK can't be a dumping ground for every widget pattern that has ever existed. It would be unmaintainable. The people that work on libadwaita is almost entirely, if not entirely, separate from those that work on GTK. This enables GTK developers to focus on the core widgets and toolkit, while implementing the various design languages can be left to others.

zozbot234vor 2 Jahren

libadwaita used to be purely about supporting "responsive" applications that would seamlessly switch to a more compact layout when displayed in a smaller window/screen size. There's nothing about this that is 'GNOME design language' specific, so why should other desktop environments work on a different 'design language' library? That's just a pointless duplication of effort. If the GNOME folks want to better support separate design languages, they should start out by reintroducing proper theming support to libadwaita. Right now you can only switch to a different theme by manually overwriting the "adwaita" theme configuration, which is a huge regression compared to what GTK+3 supported.

crashdancervor 2 Jahren

>why should other desktop environments work on a different 'design language' library?

The responsive widgets are only a small part of libadwaita. Part of the reason those widgets are still there is because they're still being iterated on -- once a widget gets into GTK it has to be maintained for a long time and GTK developers got burned before by adding a lot of random widgets without iterating first. So the bar is understandably a lot higher for adding new GTK widgets than it is for adding widgets into one of these "design language" libraries.

I could see some responsive widgets getting merged into GTK but only if they become stable enough and everybody (not just GNOME) likes the API wants them in GTK.

>reintroducing proper theming support to libadwaita

It does have proper theming support if you're using it as an app developer. If you mean allowing users to add arbitrary themes to arbitrary applications, that isn't going to happen. It can't be done without breaking applications, and arbitrary theming ruins the whole purpose of it anyway which is to enable all GNOME apps to have a consistent UX and theme.

tristan957vor 2 Jahren

You are thinking of libhandy, which had similar goals but not the same, hence why libadwaita is not named libhandy.

jsnellvor 2 Jahren

What's being described does look like a strict improvement over the current state. But Gnome has been burning user and developer trust for more than a decade (both with Gnome 3 and the mismanagement of GTK), so maybe people don't actually trust the description? "It must actually be some attempt to fuck over the the ecosystem again, I just don't see how yet".

If things have changed, then that's great! Trust will start to get rebuilt. But it doesn't happen instantly after one announcement.

crashdancervor 2 Jahren

>But Gnome has been burning user and developer trust for more than a decade

People complained in the exact same way when GTK2 and GNOME 2 were released. There really isn't anything different this time around as to how they approach changes and incremental improvements. It's the same minority of loud complainers blaming GNOME for everything when they could just use something else. It's not like there's a lack of forks and alternatives. And hey, a certain percentage of KDE users complain and fork stuff whenever a new version of KDE comes out too. That's just what happens.

As with anything open source, you get what you put in: if you don't contribute anything upstream, and you're not willing to maintain a fork, and you don't want to compromise, and you expect someone else to always "manage" everything to your liking all the time, then you're setting yourself up for disappointment.

paradox460vor 2 Jahren

I will forever find it the pinnacle of missed opportunities that Linux wound up with it's own ux system, rather than using the systems that came out of NeXT via OpenSTEP/GNUstep

linguaevor 2 Jahren

I feel the exact same way. I wish FOSS desktop advocates in the 1990s either rallied behind the development of GNUstep, or I wish that during the time when Qt had a non-FOSS license, the Harmony project (https://en.wikipedia.org/wiki/Harmony_(toolkit)) had gotten greater attention as a workaround against Qt's licensing issues. Even standardizing on Win32/Wine might have been a better outcome. Unfortunately we ended up with the Qt/GTK split and everything that resulted from that.

Don't get me wrong. KDE, GNOME, and other leading FOSS desktops aren't bad, and it's quite remarkable what they achieved over the past 25+ years. However, I feel we could've ended up with something better, something that would amaze even Mac users. I could imagine a few alternative timelines where the FOSS desktop community rallied behind GNUstep, or perhaps some of the more research-minded people in the community would've gone all the way and came up with some sort of radical GUI inspired by the Smalltalk and Lisp machines of old, as well as some of Apple's 1990s experiments. (Given RMS's affinity for Lisp and his Lisp machine roots, this wouldn't have been too crazy.) I have many thoughts (http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-...) about what my ideal desktop environment would be like, but I haven't had the time to work on them. Maybe if I win the lottery....

anthkvor 2 Jahren

Gnome 1.4 had Sawfish, a window manager expandable with Lisp.

LeFantomevor 2 Jahren

I am with you. The NeXT APIs were so good for the time. The real missed opportunity was that macOS essentially uses those same APIs to this day.

We could have had an open source apps platform that was source code compatible with macOS!

anthkvor 2 Jahren

Pikopixel and such work in both OSes.

LocutusOfBorgesvor 2 Jahren

This seems to quite deliberately miss the point of why so many find the effect libadwaita has had on the desktop experience to be so frustrating.

Really, it doesn’t matter whether the underlying motivations were supposedly to create a cleaner separation between projects at the abstract level - the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops.

That decision was theirs to make, and they were entirely free to do so - but squirming around the point to avoid talking about responsibility for the actual consequences of the decision re further fracturing the Linux desktop ecosystem is absurd.

NekkoDroidvor 2 Jahren

> the consequences have been to introduce a situation where, for the first time in quite a long period, large swathes of significant, widely-used programs are no longer capable of fitting in on non-GNOME desktops.

I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop. Like, not matter how much you theme, the UX is going to be different and that can't really be changed without rewriting the entire app in a different toolkit with the target UX in mind.

GNOME and KDE UX are completely different. One gives you the bare necessaties of options mostly behind a hamburger menu and a nice amount of padding, while the other throws every option and the kitchen sink at you with a relativly high dencity of content. They target different people, which is fine as no size fits all.

simion314vor 2 Jahren

>I still am looking for this magical theme that makes QT apps feel like it fits on a GNOME desktop.

Qt does the work to integrate with Windows and OSX, by this I do not mean that it paints the exact shame of border colors on the buttons but more deeper integration, like integrating with the native System Tray, desktop APIs, the correct order of OK/Cancel buttons.

For linux the Qt devs are aware that each distribution has it's own colors,, fonts and crap so it would be a waste to target only a distro say Red Hat.

KDE did the work to make GTK apps integrate as much as possible but I think GNOME did zero work to integrate Qt or KDE apps and they tried sabotaging everyone else by removing the Tray or the server decoration.

I am not that type of user that needs all apps to have the exact same buttons otherwise my brain segfaults, I use KDE apps, GTK apps, Java apps, Electron apps. What I want from this apps is to use same Open File Dialogs and not be like GTK where the native GTK file picker has a weird sorting option for files and folders that do not match any other popular and sane system.

Also I remember GNOME guys claiming that you do not need thumbnails in the File Picker, that you are doing it wrong and the reality was that it was not easy to add the feature so they preferred to push that excuse that you are doing it wrong.

NekkoDroidvor 2 Jahren

> KDE did the work to make GTK apps integrate as much as possible but I think GNOME did zero work to integrate Qt or KDE apps and they tried sabotaging everyone else by removing the Tray or the server decoration.

Sure it's nice I guess if they have their own theme for GTK apps, but if their own QT Kirigami apps look like this[1] on other desktop they should probably focus more on that than on apps not made with their UI framework.

> What I want from this apps is to use same Open File Dialogs

From what I remember it uses the xdg-portal for opening the file dialog, so either this has been fixed a while ago or the portal was misconfigured to use the GTK dialog (on the DE side).

> Also I remember GNOME guys claiming that you do not need thumbnails in the File Picker, that you are doing it wrong and the reality was that it was not easy to add the feature so they preferred to push that excuse that you are doing it wrong.

All I remember is that there were multiple times over the years when patches were sent and when changes were requested each time the submitter just vanished but I might be misremembering.

[1] https://imgur.com/a/dolphin-on-PUvU0ze

josefxvor 2 Jahren

> All I remember is that their were multiple times over the years when patches were sent and when changes were requested each time the submitter just vanished but I might be misremembering.

The original bug report contained multiple comments pointing out that a file chooser is not a full blown file browser and that it either should not display or cause the creation of new thumbnails.

> and when changes were requested each time the submitter just vanished but I might be misremembering.

Like the guy who stopped responding after only a year of complete radio silence from the GNOME devs?

https://bugzilla.gnome.org/show_bug.cgi?id=141154&

crashdancervor 2 Jahren

>The original bug report contained multiple comments pointing out that a file chooser is not a full blown file browser and that it either should not display or cause the creation of new thumbnails.

I think you're misunderstanding those comments, the point is that an external service needs to generate the thumbnails. If the file chooser needs them it will have to call out to that external service. There isn't any desire to build all the complex system-specific behavior around thumbnail creation into GTK itself.

>Like the guy who stopped responding after only a year of complete radio silence from the GNOME devs?

All open source maintainers I know are overworked. You shouldn't take it personally or make negative assumptions if someone doesn't get around to your pull request. This is especially true of large PRs that can be overwhelming to review.

josefxvor 2 Jahren

> . You shouldn't take it personally or make negative assumptions if someone doesn't get around to your pull request.

Wether the submitter took it personally or not is not even apparent and it does not change the fact that progress was blocked on GNOMEs side of the process and not by the submitters disappearing after changes where requested as the previous comment claims.

crashdancervor 2 Jahren

Yeah and I'm saying that's not a bad thing or even a rare occurrence. Sometimes PRs can be de-prioritized or forgotten for reasons that are outside of anyone's control, developers are human beings so that just happens. I've seen it in lots of open source projects.

jeroenhdvor 2 Jahren

Qt on Windows looks pretty out of place. Qt copied Windows Vista pretty accurately, but I haven't seen any fluent design yet. The Vista style also looks a little off now that Microsoft has tweaked the native controls in Windows 11.

KDE applications look out of place in Gnome. Some Gnome distros pack GTK-like themes for Qt applications, but Dolphin looks like ass on Gnome. Depending on your theme/night mode settings, it's also broken (black labels on dark grey backgrounds broken). Gnome apps may look out of place elsewhere, but at least they're functional.

I, too, can't deal with different behaviour, but KDE is no better than Gnome when it comes to integration. The core application UI design approaches differ, so I doubt good UI integration can even be done; cross platform applications would need complete UI overhauls for every platform they target, ruining the whole point of cross platform UI toolkits.

Thankfully, Linux applications using XDG portals will invoke native controls for features like file pickers, limiting the damage both ways. I expect something similar to happen on macOS and Windows.

crashdancervor 2 Jahren

>sabotaging everyone else by removing the Tray or the server decoration

Please avoid this narrative. I personally never liked the tray or server decorations and I don't use them other platforms. If you talk to other happy GNOME users you'll see they feel the same. It works fine for me, there's no "sabotage."

simion314vor 2 Jahren

>Please avoid this narrative. I personally never liked the tray or server decorations and I don't use them other platforms. If you talk to other happy GNOME users you'll see they feel the same. It works fine for me, there's no "sabotage."

It is sabotage, most people need to use non GNOME apps, like Slack, Thunderbird that need a Tray.

So the solution is super simple, you do not use non GNOME apps then your brain is not affected by a Tray, you do not use non GNOMe apps then your eyes are not bothered by server side decorations, what GNOME did was to try and force everyone to use the GNOME was and they failled, I no longer follow Linux drama closely so I do not know in how many groups did GNOME users fractured? there were 3-4 new DEs based on GTK.

crashdancervor 2 Jahren

None of those apps need a tray though. Personally I have no problem using chat and email apps with only notifications. Something not being to your liking does not mean it's sabotage.

>what GNOME did was to try and force everyone to use the GNOME

I would be very interested to know if you could give a source for this accusation. Just show me one comment from a GNOME maintainer saying they are trying to "force" everyone and how they planned to do it. If they were going into homes and offices holding people at gunpoint forcing them to install GNOME then I think everyone would have heard about that by now.

simion314vor 2 Jahren

>None of those apps need a tray though.

What do you mean?

That each time I get of my deska nd then I go back I should either get a stack of notifications or just check each app to see how many emails or messages I missed?

Sure those apps won't crash if soem evil person makes the Tray stuff go to /dev/null.

The idea is if you listen to the users that restored the Tray,a nd the big distros that also restored it or forked GNOME you would be forced to accept the reality, but GNOME designers pretend the reality is wrong and their fantasy is real, somehow reading a book or watching a video about UX makes those guys experts and a big bunch of the community stupid.

Also , stop pretending you are stupid, we all know the big issue with CSD vs SSD , GNOME refusing to make non GNOME apps work on their desktop, check how many forks GNOME vs KDE community had and use logic to understand the real world and non the fantasy in GNOME blogs.

rleighvor 2 Jahren

No. Why should anyone avoid discussing what happened?

We can all see with our own eyes how much GNOME cares about collaboration and interoperability with others. It's zero. It's been this way for a very, very long time. And that disdain for everyone else has consequences.

I used to develop GTK+ applications. I no longer do. Because it was an absolutely miserable experience, working with a toolkit which repeatedly requires every application developer to down tools and do a lot of busy work rewriting perfectly working code when APIs are changed or deleted. No other GUI toolkit causes so much pain and disruption to their userbase. It's quite clear that there is no regard for the actual needs of real application developers, and people like yourself aren't helping. You can't defend the indefensible.

crashdancervor 2 Jahren

You shouldn't avoid discussing what happened, I'm saying you should avoid making unfounded bad faith accusations.

>We can all see with our own eyes how much GNOME cares about collaboration and interoperability with others. It's zero

I mean, the blog post disproves this entire accusation by listing a bunch of projects they collaborate with. This is what I mean: please be more careful with your words. You're disrespecting yourself and the readers of your comments by making these kind of hyperbolic statements.

>which repeatedly requires every application developer to down tools and do a lot of busy work rewriting perfectly working code when APIs are changed or deleted. No other GUI toolkit causes so much pain and disruption to their userbase

GTK isn't the first or only project to deprecate and remove APIs, Qt does is it in every new version too. And you don't have to do this unless you're upgrading to new versions. Some projects are still using forked versions of old Qt and GTK for these reasons. That's totally something you can do.

guerrillavor 2 Jahren

Yeah, but now there are three, not just two. GTK, GNOME and Qt, rather than just Qt and GTK.

NekkoDroidvor 2 Jahren

By that logic you also forgot iced, libcosmic, libxfceui4, kirigami, xapps, flutter, .NET Avalonia, electron/html, sdl/raw rendering, and probably alot more that I don't know or can think of. This really has been just GTK and QT for ages.

anthkvor 2 Jahren

GTK was not always tied to Gnome. It was born with Gimp; and XFCE was remade into GTK making it faster than Gnome itself.

shrimp_emojivor 2 Jahren

Gimp Tool Kit!

I wonder when Gimp will upgrade to GTK 4, and realize GNOME has twisted the GTK framework into a draconian railway to making a mobile app with rounded corners, and give up and switch to Qt like so many other apps have.

tristan957vor 2 Jahren

Inkscape was ported to GTK 4, and LibreOffice is in the works. Please read the article before commenting.

Cu3PO42vor 2 Jahren

It is relatively easy to patch libadwaita to apply non-Adwaita themes. On the AUR, there's libadwaita-without-adwaita. I have applied the same patch on NixOS. It works just about as well as theming does in standard Gtk3 or 4. No complaints really.

red_admiralvor 2 Jahren

I know, but that still leaves a sour taste in the mouth.

On Windows, the first thing I do after setting up a new PC is disable the adware, uninstall default apps, turn off as much telemetry as I can, and very soon that'll include turning off the creepy AI too. They say I should use linux instead ...

And on a standard gnome/GTK/adwaita setup, apparently the first thing you have to do is patch the UI library to remove the hardcoded default theme. The free software world wasn't meant to be like this, where you have to fight the OS/distro to get things to work the way you want.

(Meanwhile Mint, as the original article alluded to, is still trying to do good by its users. Long may this continue.)

okanatvor 2 Jahren

> The free software world wasn't meant to be like this, where you have to fight the OS/distro to get things to work the way you want.

I think the actual history says something different. The free software world is created by people who think the source code is the ultimate end, however basic it is. Actually combined with the common Unix convention of implementing the most basic and barebones piece of software to maximize text based interaction, I think it is fundamentally against democratizing computers for regular people.

It doesn't have to be this way but many founders thought and still think that barely useful but libre software is better.

red_admiralvor 2 Jahren

The thing here is - around the era of GTK2, when themes (and widgets) were mostly bitmaps, there were a few things you couldn't do that adwaita is great at, but changing your accent color? Hell yes, just set the accent color in a .rc file and you're good, because that just changes the color at a particular index in the palette of the bitmaps used to draw a window.

Earlier still, there was a lot you could do with `~/.Xresources`.

Theming back then was much more a negotiation between "designers" and "users": if I like someone's general style of buttons but I'd like them in red instead of blue, I can easily do that, no coding required. You didn't even have to edit the bitmaps by hand most of the time. Want the widgets from this theme but the window decorations from that theme, but with a different font? Config file, or a few clicks in the settings GUI.

The code of the window manager/desktop environment was written to make this kind of thing possible.

In theory, you could develop a CSS-based theming where you can still factor out some key settings like "accent color" or "roundedness of corners" into variables that are easy to set or edit. Then the OS/DE would ship a default theme that works well, and if the user wants to change those settings to something that works better for them, it's on them not to mess it up.

It seems to me though that adwaita is doing everything short of DRM to make it maximally hard to disagree with their design choices.

franga2000vor 2 Jahren

I think the best way to solve this iis having an easy way to set the theme per-app. Any time an app is broken because of a theme, I have to either switch back to the default or submit a bug report and hope it's fixed / fix it myself. If I could just, let's say, right click on the window in the taskbar and click "use theme > default > always for this app", incompatibility with a theme wouldn't be a real problem, just mildly annoying.

Cu3PO42vor 2 Jahren

> The free software world wasn't meant to be like this, where you have to fight the OS/distro to get things to work the way you want.

I'm of two minds about this. I get where you're coming from, but I also understand the reasoning behind this default behavior. I've seen a lot of UIs in visually broken or even dysfunctional states due to bad themes. I get why app developers want to prevent that. You and I both, and probably most everyone here, know to turn the theme off first and see if we can reproduce the issue before reporting a bug, but does everyone?

In my mind, if we want the Linux desktop to be appealing to the broader masses (and I really want this), we need a desktop environment or two that makes some concessions in this direction (e.g. making things more user-proof) without compromising on its values. To me, themeability is nice and something I want personally, but it's not a core value that needs to be upheld.

red_admiralvor 2 Jahren

It is a core value once accessibility gets involved. Color-blind or partially sighted users, or dyslexic or highly sensory-sensitive users, may want to make choices that would seem weird if not painful on the eyes to most people, but that work well for them.

[deleted]vor 2 Jahren

jrm4vor 2 Jahren

I find the attempt to define "design language" amusing -- feels like if you have to devote that many words to what you're trying to do with design you've already failed hard.

tristan957vor 2 Jahren

Every successful OS or application has a design language. All Microsoft Office applications look similar because they all use the same design language. Why do you diminish what you don't understand?

jrm4vor 2 Jahren

It's not that the language exists, it's that GNOME's is so bad that they have to write about it.

E.g. there was never any need for Apple to talk about their "design language."

tristan957vor 2 Jahren

Yes, they do: https://developer.apple.com/design/.

jrm4vor 2 Jahren

sigh

for VERY different reasons.

tristan957vor 2 Jahren

State the different reasons.

jrm4vor 2 Jahren

Apple is showing off their success, GNOME is making excuse for failure. This is obvious.

bonzinivor 2 Jahren

Unfortunately https://developer.apple.com/design/human-interface-guideline... is down so I cannot show, but it is absolutely not showing off. It's an extremely detailed document showing how to place widgets on the screen down to the pixel.

jrm4vor 2 Jahren

Sure, I'll revise.

Apple is providing this so that others may benefit from their success. GNOME, again, making excuses for their failure.

jandresevor 2 Jahren

Wait, GtkDialog is considered a GNOME thing and is now depricated? They article claims "These aforementioned widgets only benefited GNOME apps, as they were strictly designed to provide widgets that conformed to the GNOME HIG.", but GtkDialog is the primary way to provide a modal dialog in GTK. That seems like a fairly general problem.

the_biotvor 2 Jahren

It's entirely logical for the Gnome folks to do this. They've been removing features and widgets from all kinds of programs for literally decades; Gnome is fundamentally a destructive project. Outright sabotaging GTK (which predates and inspired Gnome) is just the logical way forward on this multi-decade orgy of destruction.

crashdancervor 2 Jahren

It's odd you say those things because I've been enjoying GNOME for years and I find they make great additions all the time. For me GTK4 has been a massive improvement over GTK3. There aren't actually any GNOME developers who enjoy removing things just to annoy users -- human beings have limited time and sometimes tough decisions have to be made about what's going to make it in and what isn't.

rleighvor 2 Jahren

Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it.

Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable.

Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions.

There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.

jandresevor 2 Jahren

Couldn't you just make your own macros?

    #define GtkHBox(x) GtkBox(x, GTK_ORIENTATION_HORIZONTAL)
    #define GtkVBox(x) GtkBox(x, GTK_ORIENTATION_VERTICAL)

I thought the change to a standard GtkBox made sense given the way the system was built. This made both kinds of boxes the same class, avoiding an unnecessary layer of inheritance.

rleighvor 2 Jahren

Yes, you could.

But this needs doing in every single downstream user of GTK. Far more efficient to do it once, in the toolkit itself.

This is why sane people don't use GTK. The maintainers literally couldn't care less that their 2 hours of "work" doing the removal causes hundreds of thousands of man-hours of refactoring on the part of others, plus the testing and validation work to prove that every part of their applications are still working correctly.

crashdancervor 2 Jahren

No, that's incorrect. It's not more efficient at all, and even if it was it would still be less efficient to do it in the toolkit instead of in a separate shim. I explained this in detail in my other comment.

Also the testing and validation always needs to happen irrespective of where the shim layer is shipped, because this is still a new major release of a relatively large library. Having a shim for one widget out of many isn't going to meaningfully reduce the need for testing.

If you could mention what these programs are that are somehow completing the rest of their GTK4 ports in a small amount of time, refactoring everything to use the new improved widgets and rendering system at incredible speed, but are taking hundreds of thousands of man hours to replace the word HBox with Box, maybe someone can look at them and advise them on how to do that faster.

rleighvor 2 Jahren

You're trying to argue that water is not wet. This is seriously bad-faith argumentation.

Having a compatibility shim in GTK and testing that, once, would save any downstream user from having to do any work at all for this change. This is obvious and self-evident. Yet you seem to think that it's acceptable to impose this upon every user. It's this disrespect for end-users' time and resources which lead to people such as myself abandoning GTK entirely, when it was abundantly clear that it would not, and could not, ever be fit for purpose when you have this type of attitude prevail. Professional library maintainers do not break backward compatibility in such a cavalier manner, particularly when there is zero material net benefit of any sort arising from the change. Why would a project deliberately cause such breakage when it didn't have to. It's because it cared more about making a "cleanup" than it did about breaking it's entire userbase. It's cosmetic at best, and it could have been implemented without any break at all with a bare minimum of effort. That's the real kicker. The change could have been made without any compatibility break. And that just shows a complete lack of care.

Bear in mind also that Gtk*Box are foundational container widgets. Every application of any serious size will likely use hundreds or thousands of them. And no upgrade path for Glade/GtkBuilder XML either. That all needs hand-updating too. And this is just one example of breakage. You have to multiply it by all of the others, too. The ongoing burden of unnecessary and unproductive work repairing breakage arising from API churn is extraordinarily costly. Plus, it also breaks compatibiity of our application code with older GTK versions, which we might well also need to support in parallel for years. None of this adds value to our application, it's all cost.

You've spent pretty much all of your comments here deflecting and prevaricating. You've not once shown any concern of any sort for the actual real-world problems which have been imposed upon others, and which are genuine deal-breakers for actual application developers who have tried to use GTK for serious commercial work. The exact same lack of concern and understanding which the GTK and GNOME developers have shown all along. And I'm not new to this. I've used GNOME since pre-1.0 and developed with GTK+ since the 1.x and 2.x days. I was using GTK+ for commercial products two decades ago. It was barely viable then, and it's many times worse now. The primary concerns of these libraries should be API stability and implementation quality, and they have repeatedly failed at both.

If GTK wants to be considered seriously, it needs to behave seriously. And you need to actually listen and understand what people are telling you.

crashdancervor 2 Jahren

I just realized I forgot to mention this before: that shim actually did exist for about 10 years. It was deprecated in GTK3 and then finally removed in GTK4. If 10 years is too short a warning to give for removing a deprecated API, and this offense is apparently so bad that it ruins the credibility of the whole project, then I really don't know what could be expected of the maintainers.

crashdancervor 2 Jahren

>Having a compatibility shim in GTK and testing that, once, would save any downstream user from having to do any work at all for this change.

No it wouldn't, the downstream users would still have to test. Because in practice there are a lot more changes that need to be made than just the names of those widgets. This is one of those spherical cow situations. It would theoretically save time if apps only used the box containers and never called any methods on them but that's not how real apps are actually built.

>Why would a project deliberately cause such breakage when it didn't have to. It's because it cared more about making a "cleanup" than it did about breaking it's entire userbase. It's cosmetic at best, and it could have been implemented without any break at all with a bare minimum of effort. That's the real kicker. The change could have been made without any compatibility break. And that just shows a complete lack of care.

No, this is all wrong. The container widgets were refactored and heavily simplified in GTK4 to make the API easier to use and maintain because the class hierarchy was getting too deep and complex. Along with that they changed the names because there was a break in the underlying APIs anyway so it was a perfect opportunity to simplify the naming as well. It would not have helped at all to make such a tiny shim, that wouldn't even cover the most basic use cases. Like I already said the shim would have to be much larger to be anywhere close to being useful.

>And no upgrade path for Glade/GtkBuilder XML either.

No, there is an automated converter for the XML.

>And this is just one example of breakage. You have to multiply it by all of the others, too. The ongoing burden of unnecessary and unproductive work repairing breakage arising from API churn is extraordinarily costly. Plus, it also breaks compatibiity of our application code with older GTK versions, which we might well also need to support in parallel for years. None of this adds value to our application, it's all cost.

Then by all means, don't update the GTK version. The reason to upgrade is if you want the new features in the new version.

>You've not once shown any concern of any sort for the actual real-world problems which have been imposed upon others

Actually I just asked for some examples of real-world programs that are having this problem, if you could post the repositories then we can talk about them.

>And I'm not new to this. I've used GNOME since pre-1.0 and developed with GTK+ since the 1.x and 2.x days. I was using GTK+ for commercial products two decades ago. It was barely viable then, and it's many times worse now.

Unclear to me why you've been using GTK for 20 years if it's really that bad.

>The primary concerns of these libraries should be API stability and implementation quality

No not really. The developers can choose that concern but they don't have to. Some projects focus on stability, some focus on getting more features out the door, some focus on other things. I can't explain everything about GTK's decisions but I know that like most open source projects they have to make decisions that encourage certain types of contributions, sometimes that means they have to trade stability. And that also means if you see something that's low quality that you can fix easily then you should start contributing or fork the project, instead of demanding that the maintainers do it for you.

>If GTK wants to be considered seriously, it needs to behave seriously. And you need to actually listen and understand what people are telling you.

I'm not a GTK maintainer so I'm not even the person you would need to convince here. But I am listening to what you have to say, that's why I can tell you with confidence that it wouldn't have helped to make that type of shim.

crashdancervor 2 Jahren

Sorry but that's a really poor example and IMO not a valid complaint. I don't think they made the wrong decision there. There are quite a lot of other API changes in GTK4 so some tiny shims for only a couple APIs wouldn't help in porting at all. It would only create confusion because there would be two APIs for the same thing but now it's even more unclear when the old API is going to be removed. The argument you're essentially making here is "keep deprecated APIs around forever" which isn't realistic. They're deprecated for a reason, if you never remove them then deprecation isn't meaningful anymore.

Also you're incorrect that it would be "just a few lines of code." Those things are GObject classes which can be referred to in various ways through the runtime system or by language bindings, it's not just a matter of creating some aliases for C symbols. If you only use those in such limited ways that a tiny shim would do the job, then it would be just as easy and more beneficial to create a small script that does search and replace on your entire project.

It would be entirely possible to create a larger shim to ease porting, and keep it outside the main project so it doesn't cause confusion. But for it to be truly useful, someone would have to put a lot of thought and effort into making it work for a good portion of the APIs that changed. Then it would have to be tested thoroughly with all the language bindings. It's a way bigger project than just shipping a couple of #defines in a header. And if it did exist, it too would get deprecated and obsolete at some point when all the apps finish their ports to the new version. None of this is a new idea -- all this I'm taking about is exactly what Qt already did with Qt5Compat. It could be done in GTK as well but some interested party needs to make it happen. So far, no one has cared enough to put their money where their mouth is and actually do it.

BTW even the Linux kernel does a thing now where they don't use deprecation attributes in the code at all anymore. If a kernel developer intends to remove an API then they just delete it and fix the build. Because in practice it's actually much worse to keep an API around for long past its expiration date and annoy everyone with deprecation warnings.

gapanvor 2 Jahren

Your comments show that you have a close understanding of technical details and processes used in the Gnome project. I believe you should come clean about what your relationship with the Gnome project is. As other have hinted, you do not seem like the impartial external only-just-a-user you claim to be. You clearly have an agenda.

You only registered an account yesterday and have only commented in this thread. Most of your replies include comments like the following:

* This seems to me a very bizarre request.

* That doesn't make sense.

* See, I think now you are being too overly dramatic.

* Perhaps that's proof that it isn't as bad as the vocal minority says it is?

* It's odd you say those things...

* Sorry but that's a really poor example and IMO not a valid complaint.

* Please avoid this narrative.

* You're disrespecting yourself and the readers of your comments by making these kind of hyperbolic statements.

* The issues you mention here are mostly not relevant anymore...

* Speak for yourself please...

That shows a pattern. You seem to dismiss everything everyone else is saying. Considering the history of attitude of Gnome developers towards users and their requests, this leaves little doubt of your connection.

crashdancervor 2 Jahren

I don't have any relationship or agenda. If you really want to know, I had an account here long ago but I received some very rude, hateful and harassing comments so I stopped posting and then lost the password. Is it that much of a stretch for you to believe there's a GNOME user who isn't angry at the developers and doesn't share your opinion? I don't get my FOSS news from social media. I read the developer's blogs and announcements directly and I don't assume they're lying or trying to hide some secret evil agenda, perhaps that's why you see contrasts between my attitude and the attitudes of others?

>You seem to dismiss everything everyone else is saying.

But disagreeing with something is not a dismissal. In cases where I disagree I'm careful to state the exact reasons why and discuss, or present some facts or explanations that someone may have overlooked. That's how to keep the discussion engaging even if you disagree. I'll only dismiss someone if they're intentionally rude. And this comment is against this part of the guidelines: "Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken." I don't have any way to advance the discussion when you do that, it's personally attacking and putting me on the defense when I haven't done anything but state my opinion. Can't you see how that becomes a way to systematically shut down discussions and make them hostile, when someone constantly throws those accusations at strangers?

>Considering the history of attitude of Gnome developers towards users and their requests

There is no free software project anywhere that is obligated to honor any user's requests. If you have a problem with this, you should not use FOSS. But if you absolutely need someone to honor your requests, you need to pay them and get the contract in writing so they're legally required to do so.

the_biotvor 2 Jahren

The Linux kernel changes internal APIs, and whoever changes it gets to fix the kernel code that relies on it. The end user of the kernel -- user space -- never sees any of this, and the userspace API never breaks.

You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not. Frankly it's a bad faith argument.

crashdancervor 2 Jahren

>The end user of the kernel -- user space -- never sees any of this

I mentioned it because despite that difference I don't think it's practically much different from a developer perspective. Big changes are still about as organizationally difficult for kernel developers to do. If someone wants to deprecate something that a lot of other people are using and it's a lot of work, then they still have to convince everyone to go along with it, get them onboard with the new API and help out with removing the old API, etc. That's the actual hard part, sometimes it can be made easier by providing a shim but often it's not.

>the userspace API never breaks

This is an aspirational statement, not a rule. It has been broken lots of times. The userspace API in Linux is not just the syscalls. Effectively it encompasses every single thing a driver does and exposes in some fashion to userspace and a number of other things as well. Whether that be ioctls or other non-standard interfaces exposed by block devices, sysfs entries, procfs entries, other pseudo filesystems, netlink events, configuration files, low level userspace libraries like libselinux and libseccomp et al that technically aren't part of the kernel but the kernel developers encourage everyone to use them anyway, util-linux and other utilities of that nature, you get the picture. This stuff changes all the time and it's not even possible to keep it all stable forever because it's such a massive amount of code.

>You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not.

Yes you're correct that it's not exactly the same but I'm implying the exact opposite: The GTK and GNOME changes are actually much less of a problem! You can have many versions of those libraries installed at the same time. You can't easily use many different kernel versions at the same time.

>Frankly it's a bad faith argument.

It's against the guidelines of this site to make this kind of statement. And quite frankly it's very uninteresting to respond to. You can make your point without this.

bonzinivor 2 Jahren

There is gtk_window_set_transient_for() and gtk_window_set_modal(), and GtkDialog is basically a synchronous wrapper for those two + a nested event loop. But nested event loops are very easy to get wrong, so my guess is that, these days, you want to write the code for modal dialogs as if they were not modal, even if to the user they prevent interaction with other parts of the program.

EDIT: yep, the nested event loop part is not found in AdwDialog either (https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/cla...) so that's probably why GtkDialog is considered deprecated.

There is also GtkAlertDialog which is a replacement for GtkMessageDialog but has a better design (for example it does not inherit from GtkWindow, which was a very 90s OOP thing to do) and it uses a callback instead of a synchronous, nested event loop.

AlienRobotvor 2 Jahren

>these days, you want to write the code for modal dialogs as if they were not modal, even if to the user they prevent interaction with other parts of the program

I'm never going to use a toolkit that can't guarantee a modal is modal.

bonzinivor 2 Jahren

It is modal. https://docs.gtk.org/gtk4/method.Window.set_modal.html The user can't interact with the parent until you close it.

The problem with nested event loops is that there can always be timers or idle callbacks that fire while the nested event loop is running. Back in the day where windows were rendered on demand, you could also get expose events just because the user moved another window around.

So at the code level, "modal" windows are fiction and have always been. Getting rid of nested event loops is cleaner because it forces you to get to grips with the fact that (for the programmer, not the user) everything is asynchronous in an event-driven architecture. Plus these days programming languages have better tools to deal with the asynchronicity.

jandresevor 2 Jahren

GtkDialog also includes code for integrated buttons like OK, Cancel, and/or whatever you want.

bonzinivor 2 Jahren

So basically GtkDialog's utility boils down to gtk_dialog_new_with_buttons(). That's like five line of code saved per dialog box, or zero if you use Glade to build the UI.

The big deal for GtkDialog used to be gtk_dialog_run(), which is a bad idea.

tristan957vor 2 Jahren

GtkDialog is just a GtkWindow with a slightly different API.

whalesaladvor 2 Jahren

adwaita is the quintessential example of how the hardest programming concepts are naming things and cache invalidation.

ginkovor 2 Jahren

Just give me back normal window headers already.

And put Okay/Cancel to the bottom right like any other UI toolkit in existence

red_admiralvor 2 Jahren

I would personally like the title bar of the active window, and only the active window, to be my preferred accent color. Not a 1px colored border, an actual title bar.

phkahlervor 2 Jahren

And please keep widgets out of the title bar. Those make it very hard to drag windows around because you can't really be certain what can be clicked and dragged to move the window.

BTW MS windows does this even worse IMHO - I can't tell what app I'm using (think opening a document say .pdf or even an email in outlook), can't tell which is the active title bar, and not sure what I can drag it by.

bityardvor 2 Jahren

I just started using a Mac for work and this is pretty prevalent on Mac as well, possibly that is where it originated. Applications on Mac are a random assortment of regular apps with proper titlebars and apps which effectively have no titlebar.

Mac OS keyboard/mouse focus is also intensely weird and inconsistent. The rules for when a click brings a window into mouse and/or keyboard focus are basically unpredictable, as far as I can tell.

When you click a window to focus it, some applications use that click to put the keyboard/mouse focus on the widget you clicked on. Others "eat" the click before bringing the window to the foreground. So if you want to activate a specific text field or whatever for keyboard focus, you have to click _twice_ every time you switch focus back to a particular app.

But if you do that, you have to _space your clicks apart_ to prevent them from being interpreted as a double-click! Which might maximize the window if you clicked on the area that would otherwise have been the app's title bar!

It also throws me off at least once an hour that you use can the mouse scroll wheel and all mouse buttons except 1 and 2 in a window _without_ bringing it into focus.

After my work day is done, I am always so much happier to go back to Plasma for my personal stuff and hobbies.

red_admiralvor 2 Jahren

Joel Spolsky has an old post on this. Apparently, clicking in a window on the Mac brings that _process_ into the foreground, but not necessarily that window. If process A is in the foreground with window 1, and process B has windows 2 and 3 with 2 in front of 3, so the current window stacking order is 1,2,3 then the effect of clicking in window 3 is in fact to bring window 2 forwards, so the window stacking order is now 2,3,1.

Widgets, toolbars and other floating things that are separate windows as far as the window manager is concerned can also affect this. For example, GIMP or other programs that have palettes need to enforce that "the palette is always in front of the main window", which I imagine is handled differently on the Mac to other OSes.

tristan957vor 2 Jahren

Widgets in GTK header bars are draggable. Had you even tried it out before commenting?

phkahlervor 2 Jahren

>> Widgets in GTK header bars are draggable.

Some are and some are not. Have you even tried to understand the complaint before getting snarky? ;-)

tristan957vor 2 Jahren

Every application I have tried has draggable widgets.

preisschildvor 2 Jahren

Nah. CSDs are great and don't waste space.

kelnosvor 2 Jahren

In the days of large monitors, and even hidpi on smaller screens, wasting space is not really one of my concerns. I do all my work on a 2256x1504 laptop panel, and the 20px or so used up by my SSD titlebars is completely fine. I was similarly fine with it on my old laptop with a 1080p screen.

spookievor 2 Jahren

Agreed, its a understandable that they're choosing this path.

FOSS needs to stop having such quasi-religious positions like the ones mentioned at the start of the article, where very understandable decisions are taken as dabs against other projects.

jl6vor 2 Jahren

I’ve been a happy XFCE user for years, and although it uses GTK I’ve never run into whatever drama is going on here.

multanivor 2 Jahren

Xfce has libxfceui4, which should be equivalent to libadwaita (I never directly used it, but that was at least my understanding of it)

gapanvor 2 Jahren

Then I guess you missed the huge pile of mess that CSD made when they were first introduced to Xfce.

jl6vor 2 Jahren

I guess I did. I didn’t know what CSD was until just now. Is this something that using Xubuntu has shielded me from? I’ve been using it since around 2016, maybe a bit earlier, (using the default theme) and it’s never seemed to be a problem.

gapanvor 2 Jahren

I don't use xubuntu, but I don't think so. I don't see how xubuntu wouldn't be affected since this is a GTK+ issue. Starting any CSD application in Xfce will behave and look out of place and unfortunately, even some Xfce applications and tools used CSD (perhaps some still do).

themeronevor 2 Jahren

Are we in a state where GTK4 is the GNOME toolkit and non GNOME apps will be permanently stuck on GTK3?

kelnosvor 2 Jahren

Yes and no. The reality seems to be that GTK is a lot more desktop-agnostic, but in a way that means non-GNOME app developers (or non-GNOME desktop environment developers[0]) have to build a lot of functionality themselves that was removed from GTK4 (and/or has been deprecated and will be removed in GTK5).

To make matters worse, GTK4 "tightens up" some interfaces, making it harder to extend. So, for example, you can no longer "wrap" a native window handle on X11 with a GdkWindow (an interface that also no longer exists, in favor of a Wayland-centric GdkSurface interface) in order to integrate something "foreign" into the toolkit. They've also removed things like GtkSocket & GtkPlug, so you can't do cross-process embedding anymore[1].

I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3, and GTK5 will drive even further in that direction, if GTK4's deprecation list is any indication.

[0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me.

[1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.

crashdancervor 2 Jahren

>I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3

Your example shows the opposite though. GtkSocket & GtkPlug were removed because they were buggy and never worked on any non-X11 platforms. Removing platform-specific hacks and moving towards standard interfaces is the correct way to go if you want a generic "batteries included" toolkit and not just something that can be used to hack things together on specific Unix platforms using a specific outdated window system.

I doubt anyone has any actual interest in making it work in GTK4 because XEmbed is a pretty broken concept full of race conditions that was never fully implemented anyway. And design-wise XEmbed doesn't actually make any sense because you need to funnel everything through the X server just for one app to host another one. The proper way to do it is to have the Socket be a server and make the Plug a client that talks directly to it through its own socket. I imagine your Wayland solution does this by running a small pass-through Wayland server. That should get easier over time as Wayland libraries improve, which I can't say about XEmbed because X11 isn't being developed anymore. Doing something like that is also AFAIK the only way it would work on MacOS.

Regardless, the GTK developers probably won't merge any replacement for Socket/Plug unless it works on all supported platforms including Windows and Mac, and it actually fixes all the bugs that were in XEmbed. And you have to ask the question: why is this needed anyway? In my experience this isn't a general-purpose feature, the huge majority of apps work better when whatever embedded widget is put in a shared library, or uses RPC (i.e. D-Bus) calls to populate its own in-process views.

tristan957vor 2 Jahren

GTK development is almost entirely led by people involved in the GNOME project. From my understanding, members of other GTK-based desktop environments have not tried to become maintainers themselves to help drive the direction. Elementary as a consumer of GTK seems to be fine with most decisions. Inkscape and LibreOffice don't seem to care either.

All Cinnamon, MATE, and XFCE need is a libxapp similar to libadwaita which provides the design language that is common between those desktop environments. No one seems to have started on it though.

LeFantomevor 2 Jahren

Linux Mint did: https://github.com/linuxmint/xapp

bonzinivor 2 Jahren

The opposite: "GTK had the unique case of bundling GNOME’s design language into GTK, which made it far from generic [...] Thanks to the removal of GNOME widgets from GTK 4, [...] developers of cross-platform GTK 3 apps that rely exclusively on general-purpose widgets can be more confident that GTK 4 won’t remove these widgets, and hopefully enjoy the benefits that GTK 4 offers".

cookiengineervor 2 Jahren

It's kinda ironic that they realized (and admitted) this more than 15 years later.

Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter, mutter, unity, and several others that went into being hardforks at this point because they didn't agree with GNOME's Human Interface Guidelines.

It's also ironic that the only thing using GTK2 components on every system at this point is GIMP. The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project, making it impossible to rely upon.

A UI component framework should be reliable, stable in its API and scene graph, and not break with any second release every couple months.

kelnosvor 2 Jahren

> The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project

Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x release will work with software built around a previous release with the same major version.

You can argue that GTK breaks API/ABI and increments their major version too often (I'm not sure I'd agree with that, but you can certainly argue it), but, outside of bugs, I don't recall instances where apps had to be modified to continue to work with new releases in the same major version of GTK.

I do think it's notable that GIMP is still on GTK2, and the GTK3 porting effort has gone on for many years now. But I think it's also notable that GIMP is the exception, not the rule. On my system, for example, only GIMP requires GTK2, and I have over 100 binaries in /usr/bin/ that link to GTK3

IAmLiterallyABvor 2 Jahren

I remember GTK themes used to break every couple releases. Is that not an API break?

cookiengineervor 2 Jahren

GTK doesn't use semantic versioning.

Every uneven minor version is a development cycle, every even minor version is a stable cycle.

And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings).

See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...

I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK.

And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options.

Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins.

My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that.

(Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days)

I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.

crashdancervor 2 Jahren

The issues you mention here are mostly not relevant anymore or they're unrelated to GTK proper. The GIMP GTK3 port took forever because it's a giant app with lots of complex widgets and a tiny amount of developers. Most other apps didn't take that long to port. Also Vala isn't really used much in GNOME anymore. ElementaryOS is the main user of it now.

>Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins.

I honestly have no idea what you're referring to here. GNOME has never forked glibc. And GJS is periodically updated to the latest spidermonkey.

phkahlervor 2 Jahren

Which things are in libadwaita and not GTK? I thought the article said Dialog boxes, which would be incredibly bad for cross-platform apps if they need to be handled separately on a different OS.

bonzinivor 2 Jahren

It's not dialog boxes per se that are in libadwaita, it's things such as where to place buttons and in what order, and also what are the standard labels for the buttons (e.g. should the dialog have Yes/No/Cancel or Don't Save/Cancel/Save buttons? That's the difference between the Windows design language and the Apple design language).

phkahlervor 2 Jahren

OK, but does that mean I don't get cross platform dialogs with GTK?

bonzinivor 2 Jahren

You never did. There was never a widget that knew that "No" was in the middle on Windows and on the far left (but spelled differently) on macOS. I have no idea if/how Qt does it.

If you need to ask a question, GTK does provide both GtkMessageDialog (deprecated) and GtkAlertDialog (new). But they will look "off" on some platforms due to not respecting the native design language.

If you need a more complex dialog box, you don't need GtkDialog which was just a convenience over other APIs but, with over 25 years of hindsight, wasn't as good as it seemed to be.

Aerbil313vor 2 Jahren

GTK & GNOME are very successful projects in making me thankful to God that QT & KDE exist every time I have to use them.

postmodestvor 2 Jahren

If Qt had just made peace with the GPL back in the 90's, we wouldn't have this problem.

C.f. Motif/BSD.

jrm4vor 2 Jahren

Bahahaha.

In which GNOME finally realizes that they are not, and never will be, a Steve Jobs.

fl0kivor 2 Jahren

It's even worse than that. Choosing to copy another OS should have made the rest easy because it eliminates many design decisions and lets you focus on implementation. Somehow they still blew it, copying limitations rather than advantages.

It doesn't help that they think extensions are an excuse not to finish features in the DE itself, while leaving the extension experience so poorly conceived and implemented that you have more confidence installing a Skyrim mod than a GNOME extension.

crashdancervor 2 Jahren

If you have any better ideas and you'd like to step up to write and maintain a different extension API, then you should do that. If not, then welcome to the club with all the other open source maintainers where everyone is underpaid and overworked and no one has any time to work on all the things they want to do.

[deleted]vor 2 Jahren

anthkvor 2 Jahren

Gnome 1.4 borrowed a lot from OS8/9.

Then, Gnome 2 got a bit of inspiration of Copland and Mac OS9/halfway to 10.

Gnome 3 tries to badly copy OSX (and MacOS tries to do the same with some stuff from both iOS and Gnome).

Still, MacOS can dream about having something like QT and not-walled software repositories.

Raxelgrandevor 2 Jahren

I have been using GNOME as my primary desktop environment since version 38. To be honest, it got bad when Libadwaita/GTK4 released.

I did a forum post on the EndeavourOS Linux forum talking about this, back in late 2023 and i reposted it on GNOME's forums, without any success. From what i know they didn't work on the feedback i gave. https://forum.endeavouros.com/t/constructive-gnome-a-bit-of-...

GNOME on GTK3 was a lot more stable and quite faster, specially for the desktop effects and the design of the overview was a lot easier on mouse users (now you have to scroll all around the screen to just do things).

The focus of this is GTK but i want to quickly mention that GNOME is hostile to developers making extensions.

Recently they updated something in the Javascript they use for developing extensions, breaking all of them, and providing a porting guide very close to the deadline of the next GNOME release, barely giving developers working on their free time, time to port things, or they would get a storm of users complaining to port the program (don't believe me? browse GNOME's extension store for 5 minutes).

The first and most damaging thing i faced as a user was a very nasty bug in GTK4 that made scrolling impossible (the bug is still alive today when using touchpads) https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 .

The most crazy thing is that this critical bug for UX was detected in mid 2020, yet 4 years later it's still present on GTK. GNOME decided to break people's computers by shipping this critical bug. To me this is enough reason to not use it as a UI library. Imagine not having working scrolling... Oh wait, it's still going!

But the bugs don't stop there! GTK4 has had trouble with drag and drop support, since Nautilus' (the file manager) port to GTK4, it completely broke DnD support of File Roller (the archive manager). Now that File Roller got updated to GTK4 the problem surely got fixed, right? NO! In fact, now File Roller broke DnD for every program!

You really have to be bad to ship very broken features to an increasingly bigger user base. Even KDE's recent port to QT6 had less bugs!

Another thing that annoys me is the lack of customization. Back in GTK3 days all you needed was a GTK theme, even GNOME's Libhandy could get themed without problems. It got to a point where developers did a nothingburger note on customization https://stopthemingmy.app/ . That didn't stop anyone.

Now you need to know what themes support GTK4 and what theming hack to run on it, and don't get me started on theming Flatpak...

GTK4 never got proper support for theming, making the unreliable hacking methods the only way to theme it, without modifying the program's source. Now it ships in production with Ubuntu 24.04 (they did the right call to avoid GTK4 in 22.04 by rolling back some programs). The closest thing to an "official" theming is the Gradience program https://gradienceteam.github.io/

It's specially bad and annoying, with barely any good themes that support Libadwaita, it got to the point i developed a small program to simplify theming of Linux, called Iris https://github.com/Raxelgrande/Iris .

The other and probably most important roadblock for GTK is that it still lacks support for mobile devices, making the big strength of adaptable design it has go to waste. Nobody is going to buy a Linux phone.

Overall, GTK and GNOME are very lackluster and im pretty sure that i will avoid that toolkit like the plague. All that Libadwaita does is to lock people into GNOME's design, even if you don't like it. Good luck running programs as good as Bottles and having it look integrated in your desktop. All because they just can't be bothered to at least add a theming API so everyone stops using hacky, problem ridden approaches.

crashdancervor 2 Jahren

The reason you aren't getting any feedback from GNOME developers is because this is a huge long rant without any real new information in it. The developers are already aware of what bugs are present and what features are missing. If it was easy to fix all the bugs and replace the extension system, they would have done it already. If you don't like GNOME's design then just don't use it, it's not possible to change the entire design of the whole system every time one person has a problem with it.

There won't be any official theming where they support changing application themes to whatever you want. That is and will always be a nasty hack -- the entire idea is flawed and conflicts with the idea of GNOME, which is to have a complete platform with a consistent look and behavior. It's impossible to have that and also have full theming capability at the same time, those two ideas are the opposite. IMO you should give up on that or you will be more disappointed in the future. At one time I too used to think it was possible but I gave it up when I realized it just isn't technically feasible.

Raxelgrandevor 2 Jahren

Thank you, i will completely ditch GNOME and warn everyone who uses or is interested in Linux about it. Feedback to developers is useful, even if it's on a ranty way, with good reason, those bugs are nasty. They should use the accessibility funds to fix them as some can be considered accessibility problems (the scrolling one).

It's also easy for the developers and contributors to answer well, or at least give some kind of answer (what happened in my GNOME forums post, im just a bit sad it didn't get better). Every time i have a question regarding the upcoming COSMIC or something Pop!_OS related, someone at System76 answers and it feels very welcoming.

Regarding theming, every big OS has AT LEAST accent color selection, all but GNOME.

Edit: I did provide information, you can find sources for nearly everything i talked about. My post on EndeavourOS' forums has more information.

crashdancervor 2 Jahren

>warn everyone who uses or is interested in Linux about it

See, I think now you are being too overly dramatic. It's not that bad, I haven't encountered the scrolling bug in a long time. And let's not pretend that Cosmic or KDE or XFCE (or anything else) has no bugs or missing features.

>Feedback to developers is useful, even if it's on a ranty way,

No it really isn't. You can rant to your friends but please don't rant at developers, it's never wanted. Would you like it if someone came into your workplace and ranted at you while you're trying to work?

>It's also easy for the developers and contributors to answer well, or at least give some kind of answer

Not if your first interaction with them is to post a several page long essay full of rants and demands. For any open source project (not just GNOME) I recommend to be nice and talk about one issue at a time. Start with simple and short bug reports or questions. At the end always ask "is there anything I can do to help?" If there is already a bug report then be patient and don't nag them asking when it's going to be done. Do everything you can to make it easy and enjoyable for them to respond to your question. Do not blame anyone for being slow. Doing all these things greatly increases the chances of getting a response. If there is still no response, see this page for what to do: https://boyter.org/posts/the-three-f-s-of-open-source/

>Regarding theming, every big OS has AT LEAST accent color selection

Currently that's being worked on.

>I did provide information, you can find sources for nearly everything i talked about. My post on EndeavourOS' forums has more information.

I looked, it's all old information for the developers. They know all those things already. These bugs have already been discussed many times, they know users are unhappy with them.

fl0kivor 2 Jahren

I'm not GP but:

> If you don't like GNOME's design then just don't use it,

I don't, but for many years GNOME has been in a position where it can't use this excuse any more.

GNOME is most people's first experience of a Linux desktop. These days, more people than ever are giving Linux a try, for various reasons not relevant to this discussion. Most of those people will use GNOME first because it's the default for many distros, and often recommended for its simplicity even when people do have a choice.

Now GNOME could take the feedback from users that give it, and start to earn the position it takes in the ecosystem. Instead GNOME has been infamous for many years of actively dismissing user issues. If you have an issue with GNOME and you search for it online, not only are you likely to find it's a known and often long-standing issue, you're likely to find it being either closed or ignored so you know there's no point even trying to file it again.

An experienced Linux desktop user might just shrug and move on to something else. A first-time Linux desktop user can be forgiven for thinking that if this is the experience they have with the most famously user-friendly DE, then the Linux desktop as a whole just isn't for them.

GNOME's attitude towards user issue reports is hurting the Linux desktop as a whole, especially early in the adoption pipeline where the leverage of damage is greatest.

> The developers are already aware of what bugs are present and what features are missing.

Of course the developers are aware what bugs are present, users have been filing them for years, they just don't get resolved. In some cases features already existed and were actively removed with no adequate workaround; and no, extensions as they currently exist are NOT an adequate workaround. I'm not saying it's easy to fix, I'm saying when the state of extensions is so infamously poor and even GNOME developers can often admit that, GNOME developers cannot then turn around and use extensions as an excuse to actively remove working features or dismiss requests for features now standard to every modern DE.

Most people commenting are software developers too, we understand the pain of having to maintain a large project that has years of tech debt. Developers have every reason to be eager to purge old code and reluctant to add new code. But when user experience is on the line, especially in the one DE that most often forms a new user's first Linux experience, you have to actually listen to user feedback and make some tough calls that favor users. At the very least you can't blame the users for reporting the experience the users had, especially when GNOME has already made sure that filing issues constructively is a waste of time so venting on HN is all that's left.

In this HN thread you've told people to stop complaining or use something else or volunteer their own time to help GNOME fix its own mess. How many of those things would you say to a brand new Linux user who tried GNOME in earnest and filed a well-meaning bug trying to participate in the community constructively without being a developer? Never mind, from this thread and many GNOME issues and forum threads online, I already know exactly how the GNOME project and its advocates treat such reports and such users.

crashdancervor 2 Jahren

>GNOME is most people's first experience of a Linux desktop.

Perhaps that's proof that it isn't as bad as the vocal minority says it is? And if it was really that bad, wouldn't that be the distros' fault for continuing to ship something they know is bad? I don't think you can spin this in any way that makes it GNOME's fault, they didn't force any distros to make it the default.

>If you have an issue with GNOME and you search for it online, not only are you likely to find it's a known and often long-standing issue, you're likely to find it being either closed or ignored so you know there's no point even trying to file it again.

At that point the correct course of action is to fix it yourself or fork it. This is the same as any other open source project. I've had plenty of other open projects close or ignore my issues too, welcome to the club. I don't understand how you can be a developer yourself and still hold GNOME to this unrealistically high standard.

>GNOME developers cannot then turn around and use extensions as an excuse to actively remove working features or dismiss requests for features now standard to every modern DE.

Yes they can? It's their project, they can remove features or dismiss requests for any reason they feel like. You can also do the same in your projects.

>But when user experience is on the line, you have to actually listen to user feedback and make some tough calls that favor users.

No you don't? How many posts have we seen on HN about startups cancelling projects or shutting down because of management or money problems? Nobody likes to make those decisions, it makes the users very angry, but companies have to make them all the time because they have no choice. I know people like to fantasize about open source being different but it really isn't different. If the company employing the maintainers can't figure out how to profit from a feature then it most likely will get ignored or removed after a while. The Linux desktop is also notorious for being a pit of money that nobody can figure out how to profit from hence why a lot of user feedback is just noise. Look at Ubuntu Unity, that was beloved by its users and still it got abandoned because it wasn't profitable. I always found it weird that GNOME has this reputation for making radical changes when I find them to be quite conservative in some areas and reluctant to make changes that would result in the project totally dying off like that.

>At the very least you can't blame the users for reporting the experience the users had, especially when GNOME has already made sure that filing issues constructively is a waste of time so venting on HN is all that's left.

No, this is wrong. I'll say it again, you have the options to fix it yourself or fork the project. Venting is not the only option left and in fact venting is a completely useless option. I've seen so much venting about this on internet forums over the years, it's all the same comments about the same issues and none of it has changed anything in meaningful ways. The bugs that actually do get fixed were because somebody put in the work with the other maintainers and got it done, at no point were they ever helped by somebody ranting at them about how GNOME is bad.

>How many of those things would you say to a brand new Linux user who tried GNOME in earnest and filed a well-meaning bug trying to participate in the community constructively without being a developer?

I wouldn't, I only say these things on HN because the audience here is hackers. All the time I tell new Linux users to use Cinnamon or KDE because those are a bit more familiar to Windows users.

It's actually extremely disappointing to see developers on this forum repeating the same conspiratorial comments and unrealistic demands that you see elsewhere. Just so you know, at one time I made many of the same comments as you. I hated GNOME and refused to use it. Complainers have been saying the same things for decades now every time a new version of GNOME comes out. I was one of them. But still GNOME has lots of users that actually like it and swear by it. So what's going on here? Maybe it could be that the developers who hear feedback from a large sample of representative users on a daily basis might have a different perspective than everyone else? Maybe consider that your view is biased by only reading bugs that you noticed aren't fixed over long periods and are therefore difficult or unrewarding to fix? I know my view certainly was biased when I said those things.

sed3vor 2 Jahren

(1)