XApp — Apps that work everywhere
11 points by rcalixte
11 points by rcalixte
The XApp Project promotes applications which are built with all distributions and desktop environments in mind.
What does that even mean? GTK/Gnome and KDE follow completely different paradigms, a Gnome app feels as foreign to a KDE user as the other way round.
What does that even mean? GTK/Gnome and KDE follow completely different paradigms, a Gnome app feels as foreign to a KDE user as the other way round.
There's a bit more nuance and complication to that statement than I think I can do justice. I would say both issues you've identified are actually a single one: GNOME will only implement support for GNOME's default toolkit and applications. Other Linux-based desktop environments, including KDE, have historically made efforts to support GNOME's applications in other environments and not only was that unwelcome from some GNOME developers, future developments to the default GNOME toolkit of GTK, namely GTK 4 (especially plus Adwaita), have only increased the effort required, so much that when combined with the typical GNOME developer attitude, many (many!) projects have abandoned those efforts of supporting GNOME-based applications. In short, GNOME applications work on GNOME and GNOME will only make efforts to support GNOME's applications.
As a slight tangent, both GNOME and KDE each have their own respective Human Interface Guidelines (HIG) regarding application development:
Specific to the quote you cited, XApp is aiming to support applications with all distributions and desktops in mind. There is not yet an official HIG but one of the goals of XApp is neutrality. That's why there isn't any branding specific to one desktop environment or Linux distribution. The goal is for the applications not to feel foreign while aiming to provide reasonable functionality. More advanced or niche use cases may not be guaranteed to be supported.
It’s not the toolkit alone, that can be styled to match better. For example Gnome’s philosophy emphasizes simplicity/cleanliness much more, with less controls visible at glance. So KDE apps in Gnome feel cluttered and crowded, while KDE users could see Gnome stuff as overly simple. Both are valid paradigms, and no styling or “keeping all DEs in mind“ will bridge that gap.
and no styling or “keeping all DEs in mind“ will bridge that gap.
This is why I stated that XApp does not currently have any official guidelines currently defined. What I would suggest instead is that applications are more than free to adopt patterns that can most certainly bridge that gap. Taking browsers, IDEs, or more specifically LibreOffice as an example, there are options in the UI that give users choice. End users can have as minimal or feature-packed interfaces as they desire. That is part of the spirit of XApp: users should be free to choose what works for them without having it strictly dictated to them or restricted by the software they are using. For many, this philosophy is paramount. For others, it's an afterthought.
But GNOME applications work on KDE already? And so do KDE applications on GNOME. What support is missing, exactly? I use a lot of GNOME applications and I don't notice any of them being broken at all.
This same discussion gets rehashed every year, and every single time it boils down to people being upset that GNOME (app-)developers don't like distributors changing the application's style.css. The actual applications work just fine though!
If anything, I'd consider framing https://stopthemingmy.app/ as "GNOME developers don't want applications to run in other environments" (or whatever "unwelcome" is supposed to mean) as incredibly uncharitable towards what that page is actually talking about. Do people actually interpret that applications that don't change their entire visual style based on the DE they run in to mean "unsupported"?
It boils down to the definition of "work" in this context. Are the applications still capable of serving their intended purpose? I believe that is mostly the case. For many users though, "work" also means respecting their choices. GNOME specifically does not and that is by design. You have your priorities and values for the applications you consume but that does not mean they are universally shared.
In an ecosystem where all but one party agree on standards, is it uncharitable if that behavior is not described as unwelcome? GNOME refuses to support a conventional system tray, which breaks some applications. GNOME refuses to support server-side decorations, which breaks some applications. For many applications and many consumers of those applications, things do not just "work" as you suggested.
For many users though, "work" also means respecting their choices.
What choices aren't respected by GNOME applications running on KDE (or elsewhere)? I'm curious since I haven't seen anything like that personally.
In an ecosystem where all but one party agree on standards, is it uncharitable if that behavior is not described as unwelcome?
I specifically meant that that reference to the "stop theming my app" page as being "unwelcoming" is uncharitable. Does your response mean there is a "standard" for theming apps that GNOME isn't following (but should be)? Because otherwise this sentence doesn't really make sense; what standards aren't being followed?
GNOME refuses to support a conventional system tray, which breaks some applications. GNOME refuses to support server-side decorations, which breaks some applications.
Those are true, yeah, fair enough. But that only answers the non-GNOME-applications-on-GNOME case, and doesn't mean anything for the opposite case of running GNOME applications elsewhere. What concrete issues are there with running GNOME applications in, say, KDE, that XApp supposedly fixes? Please don't say "theming".
Using GNOME Calendar as an example, without patching the software, it does not support full functionality outside of GNOME. For example, you can't connect to Google. Because it is made for GNOME, the application's expectation is that GNOME's services and backends are used to deliver that additional functionality. When used outside of that environment, once the expectation fails, so does the functionality. Worse, the menu item is still visible but non-functional. If you were to open a bug report about that issue, you would be told that the application is not meant to be run outside of GNOME. You are not welcome because you wanted to use the application in a way that benefit your use case (i.e. running it outside of GNOME for whatever reason you might have) rather than the intended use case. The scope of unwelcome behavior isn't limited to just theming. And to be clear, this behavior is fully within the rights of GNOME's developers. If consumers disagree or find it to be unwelcome behavior, there are other options. XApp is aiming to be one of those options.
Honestly, good example! Indeed it has a broken button that does nothing in the UI, and from what I can gather requires a fully functioning gnome-control-center and valid XDG_CURRENT_DESKTOP (very hacky to work around). You have a good point then, for some specific apps :)
If consumers disagree or find it to be unwelcome behavior, there are other options. XApp is aiming to be one of those options.
Best of luck to them then!
Indeed, I understand better now. I was a GNOME developer in a previous life but didn’t realize they went so far in the "being incompatible with the rest". There were signs (mandatory systemd, the whole dconf thing).
On the other hand, KDE has also always been like that: It’s just that it has always been clear. Try to install a KDE app and you will need to install gazillion of dependencies (basically the whole KDE desktop) just to run one app.
pure speculation, but I think these apps are loosely associated with XFCE (there's some projects on this page that integrate with XFCE specifically), i.e. UX is GNOME-like but maybe with fewer dependencies/less tightly integrated into the DE.
It is very unclear but it seems to be a kind of layer above Gtk and the website is promoting the apps using that layer (probably by the same group of people) .
I fail to see the real interest, it is really unclear.
Right - it’s the exact same thing when using electron apps - it’s a prettier version of Java apps “working everywhere” in the 90s, and just as then the apps look out of place, work differently, and don’t interact properly with the rest of the system.
Obviously in the case of Java apps or these apps you’re not carrying around a multi hundred meg operating system that also means your basic apps have the same attack surface and update requirements as a web browser.
I think “everywhere” should at least include Windows/MacOS. This is more of a “on most Linux distros” than “everywhere” situation