- We are focused solely on home computing devices.
- We are obsessed with providing sane out-of-the-box experiences and defaults, some which may run counter to their upstream counterparts (like GNOME).
- We are obsessed with providing a responsive, performant, and accessible platform for all users regardless of experience or skill level.
- We do not shy away from rethinking entire aspects of our architecture to continuously provide ourselves and our users a better experience, whether that’s driver management, Steam support, or software delivery.
#GNOME
While we have been consistent in this vision, though certainly not without flaws in its execution, we have seen a significant shift from GNOME's development efforts and vision being focused from their desktop experience, to a heavier focus on mobile-to-desktop application scalability and a more touch-oriented, almost iPadOS like user experience that does not (in our opinion) provide the most optimized experience for laptop and desktop users. This is something I have noticed over the years as the maintainer for the GNOME stack on Solus and has become especially apparent in the last few years while I have been the lead on Budgie. What used to be a community welcoming diverse ideas, focused on providing an equitable ecosystem for many members of the Linux community, has gradually turned into an isolated silo of thought that pays little mind to the concerns raised by its users.#A Bigger Problem
Linux users have long enjoyed the degree to which they are able to personalize their desktop apps and environments through theming, a tradition dating back to long before I even started using Linux. Reasonable expectations like these are being completely turned on their head by GNOME. This is being done by requiring vendors like Solus and System76 to develop their own libraries to handle styling of their own specific applications, fragmenting the look of GTK apps that either use a platform theme or don't use one at all. Through their enforcement of the Adwaita theme in their "platform library" libadwaita, which they pitch as more-or-less the blessed way of adopting their Human Interface Guidelines, they are eliminating both developer and user choice in the process. If you want to support and adopt the GNOME HIG via libadwaita but still offer third-parties the flexibility to make the app integrate well in their ecosystem, you cannot. This introduces a significant regression in the desktop Linux space. To make matters worse, when some improvements were proposed by an engineer at System76 to libadwaita's Recoloring API, which is their alternative to theming that is specific to recoloring various elements of GNOME apps and is app-specific (not system wide), these improvements were rejected on the basis that some of the GNOME developers disliked the opinions expressed by the engineer on social media. This proposed solution would allow developers to explicitly opt-in to supporting a range of GTK themes rather than just libadwaita, satisfying concerns by a vocal minority of GNOME application developers that non-Adwaita themes negatively impact the quality of their applications, and makes it harder to perform QA. This proposed solution would not fully accomplish the level of personalization end users desire, nor what operating systems like Pop_OS! and Solus expect. But it would create the foundation for a middle-ground between all parties, despite GNOME's insistence nowadays that external stylesheets / theming are more of a "hack" than something they want to invest on standardizing and improving. Instead of debating more on technical merits, these developers are instead trying to devalue and discredit the contributions by intentionally misconstruing the opinions expressed by the engineer, attributing malice where none existed, and claiming the individual was "flamebaiting" to get attention.
On social media, it has not been any better, with some GNOME developers dismissing concerns by just claiming that nobody from System76 ever engaged with GNOME on the matter, which is materially false, and made remarks that these developers "instead prefer to rant on twitter".
Source: @alexm_gnome
Other developers have opted to make remarks that more-or-less come down to "if you don't contribute, your opinion doesn't matter", which is incredibly dismissive of all the people that are passionate about open source, but have no technical means or capabilities to actually get involved.
Source: @tobias_bernard
This sort of behaviour and attitude from GNOME towards the broader community was reflected on by an Inkscape developer and clearly signifies a broader issue in GNOME's community.
#GTK4
Note: This is taken from my prior blog post which expresses problems in GTK4 in the context of many APIs I use in Budgie Desktop View as well as the audio manager I was building in GTK4, Koto.#Sub-classing
Previously, you were able to "sub-class" various Gtk widgets such as the GtkHeaderBar. Sub-classing allows you to more-or-less implement your own widget / logic on top of an existing one, leveraging its properties and signals to simplify your own widget or application logic. While this is less useful in the case of a GtkHeaderBar, GtkListBox was one of the widgets I wanted to sub-class for my KotoTrackList as well as the Koto artist listing. Unfortunately, in GTK4 these widgets were marked as "final", meaning they could no longer be sub-classed, and there has been no changes upstream in GTK4 to allow them again. Instead, you need your own class that sub-classes GObject + GObjectClass, hold a pointer to a GtkHeaderBar or GtkListBox, and make changes to the widgets referenced by the pointer. So still doable, but unnecessarily cumbersome.#Deprecated X11 APIs
One of the biggest reasons I haven't moved Budgie Desktop View over to GTK4 is the deprecation of numerous X11 APIs. These removals were done due to GNOME's belief that the window manager should be the only piece of software controlling the positioning of the window, and that these APIs would for that reason not be Wayland friendly. Since GNOME's focus has been promoting and pushing Wayland support, they have done so at the cost of support not just in X11, but also cross-platform support under macOS and Windows. I will get into more of the "cost" of lack of focus on X11 support in a bit. Budgie Desktop View uses the monitors-changed and sized-changed signals in GdkScreen and GdkX11Screen respectively to know when the number of our monitors has changed, primary has changed, or the size of the monitor has changed. This allows us to perform calculations for our GtkFlowbox layout to eliminate the possibility of undesired item overflow, hiding items where necessary, and ensuring Budgie Desktop View is always positioned starting at 0,0 (top left) of the primary monitory. For Koto, the desire would be to use these APIs to know when to adjust our default optimal size for Koto in an unminimized scenario (not maximized but not minimized), as well as APIs for centering Koto on the primary monitor. Since none of those APIs exist anymore, it simply is not possible. Applications lose these capabilities for the simple reason that GNOME no longer wants to provide it, not for any real technical reason. They could have put all of those APIs behind an X11 namespace or OS-specific ones. They opted not to. Linux is not the only thing affected. All platforms are. Instead of having simple GTK functions to set the positioning, now everyone has to write their own APIs that interface directly with X11 APIs (risky if the developer is not familiar with them), or Windows APIs likeSetWindowPos as another example, in order to achieve this. This makes the lives of developers that entrusted Gtk to be a solid cross-platform toolkit unnecessarily difficult, just resulting in more duplicate code everywhere, and increased maintenance in a place it should not be needed. This on top of all the changes they already need to make migrating from GTK3 to GTK4.
#More Major Issues
A couple major issues that I have had to deal with just in the development of Koto (not to even get into the issues other application developers have run into) have been related to the GtkListView and GtkPopovers. I have talked about this in the past, but I have been dealing with issues related to both of these widgets for so long now (as they are both fundamental to Koto's UX) that my frustration is basically at a boiling point. How can such ubiquitous widgets lack priority for the upstream GNOME developers? When it comes to the GtkListView, scrolling has been broken for over a year now, where the scroll position will suddenly jump to the end of the list. It happens whenever the GtkListView reaches the point where items start getting "recycled", but it completely breaks scrolling even semi-long lists (like a list of artists). Allegedly another GNOME developer has this on their "to-do"...for months now. Another more significant issue, at least in my case, causes your current workflow to completely grind to a halt and nowadays can even result in a session loss. This is the issue with GtkPopovers in GTK4 under X11 taking keyboard and mouse input and not giving them up even when the window is not in focus. This has been an issue for 8 months now and an issue I have run into a fair bit when streaming Koto development, particularly sections of the codebase like the Koto Equalizer that reside inside a GtkPopover. If you have a popover open and switch to another window, that popover will still be in focus and you cannot interact with any parts of window you are intending to. This has been a pretty common annoyance when jumping between Koto and writing code in Visual Studio Code during my stream, but it can conceivably happen with any GTK4-based application that uses a popover. You have to explicitly close the popover then switch back to the application you wanted to interact with originally, in order to work around the issue. In older releases of GTK4, the Koto window would effectively "disappear" during a segfault, with the popover remaining in the foreground and still taking keyboard and mouse input. To get around this and allow me to continue streaming development without having to always jump into TTY, kill the process, and disrupting my session, I started running Koto via gdb with a custom runner in Visual Studio Code. This was enough in this specific scenario, but now I'm back to the point where regardless, the popover remains and now not only do I have to swap to TTY to kill the process, but killing it and swapping back results in the Xorg server segfaulting. In my last Koto stream, this happened three times to the point that I just simply gave up and started messing with iced+Rust. It is these sorts of pain-points / frustrations that have been pervasive in development with GTK4, just with Koto alone, not to mention the sort of frustrations we would get when building out multiple applications and a desktop environment leveraging it.#General Disappointment
Since Beatrice and I became co-leaders of Solus, we have been consistent in our desire for Budgie 11 to leverage GNOME's "next major iteration" of its toolkit. Both her and I have a strong preference for C and generally prefer the aesthetic of many GTK-based applications. Sticking with GTK3 for Budgie 11, which would not only need to be developed, but also subsequently maintained for likely years to come, was recognized as not being sustainable long term. So we continued to support Budgie via its 10.x series, built on GTK3, and ensured it supported new GNOME releases while introducing quality-of-life improvements along the way. We were optimistic about GTK4's release and were excited by its release in December of 2020, which was long awaited after more than a few delays by GNOME. However, GTK4 has not lived up to our hopes and expectations. Regardless, I took the opportunity to experiment with GTK4 via Koto, to provide us a clear test case for broader use in Solus or software developed by Solus, with Beatrice closely following its development. While maybe unreasonable, our hope was that many of the improvements introduced by Purism in their libhandy library, such as HdyPreferenceGroup/Page/Row/Window, HdySqueezer and HdyViewSwitcher widgets - would have seen either inclusion as new widgets, or improvements built on top of existing widgets. Unfortunately, this was not the case, and these improvements never made their way into GTK4. Instead, GNOME has opted to effectively transform libhandy into libadwaita, providing a sub-optimal user experience for anyone that wants to provide GTK-based applications respecting the GNOME HIG without having to adopt libadwaita for these widgets. Expanding on this, we were disappointed with the removal of many APIs (e.g. many X11 APIs) that we believe should remain accessible, especially since our plans for Budgie 11 do not entail supporting Wayland (rather Budgie 11's architecture would merely result in the by-product that supporting Wayland could be done more easily). Maybe it was our fault for being hopeful that many improvements from others like elementary and Purism would have made their way into GTK itself, or that the capabilities of GTK would only be expanded to facilitate the next generation of Linux applications and desktop environments.#GTK5
For GTK5, the current proposals are to leave theme selection to platform libraries and remove the prefer-dark setting so dark theme preferences are done via platform libraries as well. If you are a desktop Linux user and want to have a consistent experience across all your apps, good luck with that once GNOME apps start adopting libadwaita and GTK5 becomes a thing. If you are building a desktop Linux application at this point and you want to provide flexibility for your users or allow operating systems to ship your app, with users being happy with how well it integrates with the rest of their Linux experience, using GTK4 and beyond is going to be shooting yourself in the foot.#What Is Next
If you read my last blog post, you would know I spent some time exploring alternatives to GTK, including: EFL, Qt, and iced. When I first began working on Koto, my choices were between going with GTK, or taking a chance with EFL. The decision ended up boiling down to two items:- The styling and positioning of widgets in EFL is done with their own declarative syntax rather than CSS, which would get compiled into an EDJ file and used in the application or a specific component.
- I wanted to follow the GNOME HIG more closely, such as popovers and headerbars. This obviously is easier when using GTK rather than EFL.
Outdated
No longer my views. Years have passed and a lot has changed. C++ is great, Qt is great and iced has matured significantly. I have since left Solus and founded Buddies of Budgie, which spearheads Budgie Desktop development.
- Statements asserting that EFL has been chosen as the future toolkit of Budgie Desktop should be considered outdated and may not align with plans for Budgie under Buddies of Budgie. Time will tell and we would rather show than say.
- Statements asserting that Budgie will not be written in Qt or iced should be considered outdated. The team, myself included, like C++ and Rust. Qt is a good option. iced has matured significantly.
- Statements related to KDE / Qt were made in the context of the time of writing and do not reflect current views on Qt's licensing.
- Statements asserting any plans for or by Solus should be considered outdated.
- The one thing that has not changed is that Budgie Desktop (11.x and beyond) will not be written in GTK4 or newer versions of GTK.
Rather than removing this content or the post entirely, I have chosen to keep it here for historical purposes.
#The Choice
It would not be in the best interest for Solus to invest in a future version of Budgie that leverages relevant software (GTK as an example) developed by GNOME. In fact, it would not be in the best interest for Solus to invest at all in developing any software leveraging GTK4 and beyond. It would put us in an undesired position of being progressively negatively impacted by conscious decisions by GNOME, not to mention implying to others that we support the direction GNOME is taking their software stack, when that reality couldn't be further from the truth.So for Solus, our alternatives to GTK would be:When it comes to Qt, neither myself nor Beatrice desire writing C++. I absolutely recognize that there are many language bindings, however the reality is the bindings for languages we would likely write in, Rust or Go, are not active. Expanding on this, the history between Qt and their commercial license, and the open source community plus KDE has made us hesitant to adopt it for an application even if the bindings were actively developed.While iced shows a lot of promise, at this moment in its early days it is cumbersome to implement your own custom widgets since you have to deal with the rendering / most of the drawing yourself. Additionally, you cannot overlap widgets due to its lack of Layers. This means "basic" functionality like popovers would not be feasible. Multi-window support is also problematic in iced, so at the moment it would not be a viable solution for Budgie. This is obviously disheartening, however I am really excited to see where iced goes from here, and will be following it closely.So this more-or-less leaves us with either writing our own toolkit, or adopting EFL. Given we do not have the resources to write our own toolkit at the moment, this choice is obvious: Adopt EFL. This will provide us the opportunity to write our software in C, at the very least before I write / update Rust bindings for it. This may even provide an opportunity for collaboration with others in the space, like Rust enthusiasts over at System76. I will certainly need to make a fancier EFL theme before we can seriously ship any software written in EFL.However, providing a cohesive and independent user experience is not limited to just Budgie itself, Budgie merely plays an important role in getting Linux in front of many users. To deliver this user experience, we must either ship existing alternatives to GNOME software, or build an alternative ecosystem of open source, distro-agnostic software.This is exactly what we will be doing.We looked at the problem from the following angles:- Which applications, regardless of complexity, can be more trivially swapped out for existing software not developed by GNOME, at least until we develop and ship alternatives.
- Which applications do not have any good alternatives and thus cannot yet be replaced.
- Which applications should we prioritize developing from scratch, or retaining temporary forks.
- When it comes to image viewers, the current one shipping is eog (Eye of GNOME). This is not an especially sophisticated type of software and can be trivially replaced with a solution written from scratch, or adopting an alternative such as viewnoir.
- For calculators, we ship GNOME Calculator. So long as we are able to leverage GMP (the GNU Multi Precision Arithmetic Library), writing an alternative should be trivial. "Worst" case is we ship an alternative such as mate-calc or one from another ecosystem.
- For our document (e.g. PDF) viewers, we ship Evince. This one is certainly more complex to solve, as it does not just display documents but also allows some form manipulation as well. For now, we will be continuing to ship Evince, however are open to alternatives.
- As a basic graphical text editor, we ship gedit. While shipping any ol' text editor would not be a problem, having near parity in its syntax highlighting (provided by gtksourceview) is a must. So this will either need to be an ol' GTK3 application or one written with EFL.
- The file manager we have shipped for many years has been Nautilus. Fortunately, there are many great alternatives such as Nemo, Caja, and Thunar. In the case of Nemo and Thunar, whose would need to be more thoroughly reviewed and packaged for inclusion in our repository, but they will serve our users well until I get around to writing an alternative, something I have committed to through support by my Patrons.
- Baobab, the GNOME disk usage analyzer, will simply be dropped as a pre-installed application. There are solid alternatives in the repository that users can instead install (or they can install baobab after the fact), like qdirstat.
- GNOME System Monitor: May use MATE's System Monitor or write an alternative.
#GNOME Edition
For the Solus GNOME Edition, I am no longer confident that I can continue to provide the necessary curated experience that many of our users expect from a Solus edition. In lieu of dropping the edition entirely, alienating people that want to use Solus while also happening to prefer GNOME Shell, we will cease shipping a curated GNOME Edition in the next Solus release, giving it a clear "non-curated" designation and demoting it to a separate section of our Downloads page. This messaging will make it clear that by using GNOME Edition via these new downloads, you are accepting the fact that you will receive stock GNOME Shell, with an extremely small set of defaults applied (wallpaper, some default settings for apps, etc.). Existing users will not be affected by these changes. Once Budgie 11 is released, we will evaluate it / its capabilities compared to GNOME Shell and decide whether to keep Solus GNOME Edition in its non-curated designation, or deprecate it entirely with a pathway for users to upgrade to a Budgie 11 experience.#Summary
So in summary:- GTK4 has not met our expectations since its release in December of 2020, nor have we been satisfied with its state as of the writing of this post.
- Current plans by GNOME for changes to how theming works is viewed as regressive for desktop Linux, developers, and user choice.
- We do not believe that GNOME is treating its community, from individual users to entire operating systems, in a manner that is equitable and respectful of their choice on how they want to curate their own experience.
- Budgie 11 will not be written in GTK4.
- For Budgie Edition: we will be working on replacing software developed by GNOME with that of alternative software developers as well as "in-house" solutions. These will not necessarily be under the GetSolus organization nor will they be associated with Budgie. Adopting Budgie going forward (at least until 11, when we have our own control center) does not and will not require using our own apps. This has even remained true even for Budgie Desktop View, we support alternatives like Desktop Folder as alternative "desktop" implementations in Budgie.
- GNOME Edition will be demoted to a non-curated edition and moved to a lesser position on our Downloads page in a future release of Solus.