Libadwaita: Splitting GTK and Design Language
tesk.page
tesk.page
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.
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.
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.
>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.
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.
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.
>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.
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.
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?
If the toolkit supported this automatically, it would be easier to achieve this
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.
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.
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.
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?
You keep misrephrasing me and others. That's clearly not helping you understand. Or helping you not understand.
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.
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.
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...
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.
Looking at the examples I think that it works in some contexts, but is a personal feel that I have.
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.
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.
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...
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.
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.
>learning from mistakes
pick one, and only one. They are the most stubborn bunch in existence.
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.
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.
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.
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.
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.
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.
- KIO
- KParts
- KHTML
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.
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.
[1] I hope... , ...for all I care, Overall I truly believe....
>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?
You need to work on your reading comprehension because you're twisting everyone's words in your comments, not just mine.
> 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.
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.
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.
If things have changed, then that's great! Trust will start to get rebuilt. But it doesn't happen instantly after one announcement.
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.
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....
We could have had an open source apps platform that was source code compatible with macOS!
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.
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.
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.
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.
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?
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.
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.
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.
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."
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.
>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.
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.
>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.
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.
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.
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.)
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.
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.
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.
E.g. there was never any need for Apple to talk about their "design language."
for VERY different reasons.
Apple is providing this so that others may benefit from their success. GNOME, again, making excuses for their failure.
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.
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.
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.
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.
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.
>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.
#define GtkHBox(x) GtkBox(x, GTK_ORIENTATION_HORIZONTAL)
#define GtkVBox(x) GtkBox(x, GTK_ORIENTATION_VERTICAL)
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.
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.
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.
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.
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.
I'm never going to use a toolkit that can't guarantee a modal is modal.
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.
The big deal for GtkDialog used to be gtk_dialog_run(), which is a bad idea.
And put Okay/Cancel to the bottom right like any other UI toolkit in existence
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.
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.
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.
Some are and some are not. Have you even tried to understand the complaint before getting snarky? ;-)
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.
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.
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.
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.
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.
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
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.
>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.
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.
C.f. Motif/BSD.
In which GNOME finally realizes that they are not, and never will be, a Steve Jobs.
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.
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.
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.
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.
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.
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.
> 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.
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.