System76 Reportedly Developing Their Own Rust-Written Desktop, Not Based On GNOME

[gnwiii]

I work with scientists in fields like ecology and oceanography. Many of them would have trouble explaining the difference between mass storage space and RAM ("my program says it needs more RAM, so I want to replace my drive with a bigger one"). Most employers require them to use Windows, but they need applications that are only available on linux or run numerical models using linux on HPC systems. Some teach courses using linux software in university computer labs. Many use macOS if their jobs allow that. Few of them know or care about Gnome versus KDE, themes, etc., and will use whatever disto spin they can get on a borrowed live installer flash device from colleague. They don't want to spend time tweaking configurations, but do expect that running "ls" on a remote linux system in a terminal on their desktop (Windows, macOS, or linux) will produce a legible display (many combinations produce dark/light text on a dark/light background). They also expect to install 3rd party software on whatever distro is available. There was a brief period when LSB was reasonably successful at allowing command-line binary applications to run on multiple distros, but those days are gone, so now those apps use containers and/or VM's.

Linux developers need to work together towards a common "out of the box" basic user experience, recognizing that many users will need to work with more than one distro in their careers.

[ssokolow]

What am I projecting? My hatred of GNOME?
No. It's pretty clear you just hate GNOME and take side in every conflict against them.

You clearly care about whether GNOME is right or wrong, so you're assuming I must too. I don't. I'm just making an observation about the effects of their behaviour on others.

You conveniently ignore areas where I'm "on GNOME's side" like how, despite being a KDE user, I'll readily say I think the GTK devs were right and Qt devs were wrong when it comes to technologies like GObject Introspection vs. QMetaObject.

Is this a honest and clear description? No. It intentionally made vague to look like there "must be fire". Here is clear description: they've rejected a patch which tried to reverse their strategic decision for fixing theming.

You keep trying to paint this as me pointing at that specific decision as some great sin... I'm not. I'm just saying "Oh, look. One more example to throw on the pile of times GNOME devs got people's backs up."

Have I read correctly? You've made a decision to switch a toolkit without considering your current users who may not want to install Qt or who liked gtk look and feel? Will you accept a patch reversing to last version, which uses gtk?

First, the GNOME devs are perfectly free to do whatever they want... they're just not entitled to be seen as the good guys if they yank the rug out from under people who they led to believe could trust them to provide infrastructure suitable to their needs.

Second, you have not read what I said correctly... though I admit it's my own vagueness in that case. I continue to maintain my GTK creations as GTK applications. I even ported gtkexcepthook for Python (not my creation but something I use) from PyGTK and GTK+ 2.x to PyGI and GTK 3.x before then porting it to PyQt5 for my own use.

When I say I switched, I mean for new projects. For existing GTK 2.x projects, I remain committed to the same thing my users had before:

A UI that either has no widgets (eg. QuickTile is purely controlled by global hotkeys) or feels native on KDE, LXDE/LXQt, and possibly Xfce. Even in the days of GNOME 2, feeling native on GNOME was a side-effect of actively supporting LXDE and casually supporting Xfce, not a design goal, and that hasn't changed.

From the beginning, the core motivation for choosing GTK 2.x over Qt 3.x was "Thanks to QGtkStyle, either one will feel native, but KDE users are much more likely to have GTK already installed than LXDE users to already have Qt".

However, I do acknowledge two caveats:

• Given that I've always targeted KDE and LXDE as my primary supported platforms, if GTK makes it too difficult to continue to feel native on them, then I'll follow LXDE's lead and do a major version bump with a rewrite to Qt to preserve the experience my target users (including myself) have come to expect. In fact, given that KDE was always Qt-based and LXDE is becoming LXQt, the solution that would make my users happiest is probably to port to Qt anyway.
• I may cease implementing new features on my GTK projects if I decide it's too onerous to reinvent things Qt gives me for free.

I've always targeted desktops that present the Win9x-style desktops GNOME devs explicitly declare to be dead so, if the choice is between remaining GTK based and preserving the end-user experience I and my users have come to expect on DEs I actually support, I'll switch toolkits... especially now that, with GNOME championing Flatpak as a way for downstream users to effortlessly get the experience upstream wants to deliver to them, it's easy for me to deliver Qt to my users.

[Khrundel]

You clearly care about whether GNOME is right or wrong, so you're assuming I must too. I don't. I'm just making an observation about the effects of their behaviour on others.

Well, maybe some other time I will say something stupid, but right now I'm suggesting to look at situation without bias, take facts into account and measure GNOME sins by a rule you would accept for yourself. Is it "pro GNOME bias" to suggest being just to them?

You conveniently ignore areas where I'm "on GNOME's side" like how, despite being a KDE user, I'll readily say I think the GTK devs were right and Qt devs were wrong when it comes to technologies like GObject Introspection vs. QMetaObject.

I don't know you. I see your behavior in this discussion and it can be digested as "I don't care about details, I'll avoid them, I know GNOME are always bad guys so lets find some formula which will confirm this".

You keep trying to paint this as me pointing at that specific decision as some great sin... I'm not. I'm just saying "Oh, look. One more example to throw on the pile of times GNOME devs got people's backs up."

And that is incorrect argument. You can't measure one action by overall "reputation" in your head. I'm pretty sure that reputation was created by other unjust verdicts from other time, when there were no GNOME advocates like me.

First, the GNOME devs are perfectly free to do whatever they want... they're just not entitled to be seen as the good guys if they yank the rug out from under people who they led to believe could trust them to provide infrastructure suitable to their needs.

OK, will you accept "bad guy" brand for yourself for doing the same?

Second, you have not read what I said correctly...
...

Thank you, I don't need all these details. I believe there are some "done" projects not worthy to rewrite with another toolkit. I'm speaking about single project which you've switched or plan to switch to Qt.

In fact, given that KDE was always Qt-based and LXDE is becoming LXQt, the solution that would make my users happiest is probably to port to Qt anyway.

Nice try, but you won't escape through this.
It doesn't matter what you've targeted. GNOME for at least 10 years repeated they don't support theming and there is adwaita and adwaita only. It is pretty clear what they've targetted. And still, you keep saying "they led to believe could trust them to provide infrastructure suitable to their needs" as if theming somehow relates to infrastructure.
So if there at least one gtk-only distro which used to ship your app or even some number of gtk-only users, who you "led to believe you will provide gtk-based app" you must be branded as a bad guy. By your own rule you trying to impose on GNOME. Will you accept this brand? Or, maybe we will throw away that rule as obviously unjust?

[Danielsan]

so european and out of reach for rh that second spot of patrons is taken by google
you can find same google(and stab in the back from suse btw) here https://foundation.gnome.org/
i thought it was largest "alternative desktop", i.e. i was trying to be generous with you

It is well known that a lot Gnome devs are paid RH employs, especially the most actives and the ones who are leading the latest Gnome development; and this is the reason why Gnome3 and systemd are tied together. Said that I don't recall many KDE devs that are RH employs paid to work on KDE, pretty sure them exist or existed but I am pretty sure they are always been a scarce minority.

KDE in the last year has been gaining traction as "moderate" resource hog, this is true if you log-in and keep in IDLE the desktop all day long, at the first application launched it comes back the usual memory and resources hog. However it is true that KDE has a large man power working on it hence is the only alternative to Gnome if you want a reliable and supported desktop; but as a matter of fact KDE is the default desktop in very few distributions, none one of the major Linux distro is shipped with KDE as default DE.

[Danielsan]

In this case, though, I'm just pointing out why other people, who maintain things that do depend on GTK are upset. The devs spent over a decade not disabusing people of their impression that GTK was meant to be common infrastructure, and now the GNOME team is saying "We don't want to maintain your use-case anymore!" when it's not cheap or easy to rewrite a big application on another toolkit or fork the toolkit.

This is nailing!

Actually they transformed the GTK from a toolkit to create open source applications from a toolkit to design Gnome only application. The most funny think is the former "Gimp ToolKit" are creating a lot of issues to Gimp since ended up that many widgets are unsuitable for its use cases.

[ssokolow]

Is it "pro GNOME bias" to suggest being just to them?

No... but we both believe we're being just to GNOME. We just disagree on what complaints they brought on themselves.

I don't know you. I see your behavior in this discussion and it can be digested as "I don't care about details, I'll avoid them, I know GNOME are always bad guys so lets find some formula which will confirm this".

It can be digested like that... that doesn't mean it's true to reality to do so. That said, this is the Internet. You're free to give yourself indigestion if you want.

And that is incorrect argument. You can't measure one action by overall "reputation" in your head. I'm pretty sure that reputation was created by other unjust verdicts from other time, when there were no GNOME advocates like me.

Believe what you will. You still seem to be acting as if I'm more than just a messenger and that arguing with me will somehow change the message.

OK, will you accept "bad guy" brand for yourself for doing the same?

I have yet to see a user upset due to my decisions, but sure. If someone from the GNOME side gets upset that I'm following the desktops which used GTK 2.x but were never particularly wedded to the GNOME HIG as GNOME hammers the wedge in deeper, I'll be "the bad guy".

I'm not the one hammering the wedge in, so why do I care if some people misattribute the blame?

Thank you, I don't need all these details. I believe there are some "done" projects not worthy to rewrite with another toolkit. I'm speaking about single project which you've switched or plan to switch to Qt.

None yet. So far, almost all my projects that use GTK and have been made public are utilities that don't rely on GTK widgets (only X11 bindings for XGrabKey in QuickTile's case, a Glib event loop, and non-GTK libraries accessible through GObject Introspection such as libwnck) and are easy to keep native-feeling on all desktops because of that).

I do have one GTK project I'm considering rewriting (since it's a GTK+ 2.x project that relies on some of the GDK stuff that got spun out into Cairo in 3.x)... but it's been effectively abandoned for over a decade and my vision for it has changed so much that it's basically a new project... not to mention that the planned features have always involved MVC widgetry, and Qt does a much nicer job of documenting that than GTK does.

Nice try, but you won't escape through this.

I'd love to see you walk up to people like PCMan (lead developer of LXDE and author of PCManFM) and try to argue that a GTK-based GNOME competitor is obligated to be subservient to GNOME design guidelines without getting laughed at.

Fundamentally, you're arguing that anyone who builds anything with GTK is obligated to obey GNOME design guidelines... unless you're arguing that only stuff that's officially part of the Xfce or LXDE projects are allowed to design with the intent to fit into them rather than GNOME.

It doesn't matter what you've targeted. GNOME for at least 10 years repeated they don't support theming and there is adwaita and adwaita only. It is pretty clear what they've targetted. And still, you keep saying "they led to believe could trust them to provide infrastructure suitable to their needs" as if theming somehow relates to infrastructure.

Xfce has existed since 1996 (25 years ago) and been GTK-based since 1999, one year after GTK's initial release. LXDE has existed since 2006 (15 years ago). I've been using Linux as my primary machine since 2001 (20 years ago). What right do some design newbies have to change the direction of the project years after everyone else had started depending on it?

Hell, the initial release of the XForms-based version of Xfce predates the initial release of GNOME by three years (1996 vs. 1999) and GIMP predates GNOME by one year (1998 vs. 1999) so, if we're talking seniority, GNOME should be listening to their needs when deciding what to do with GTK... especially given that GTK used to mean "GIMP Tool Kit", not "GNOME Tool Kit".

Also, it's not just about theming. It's also about changing the available widgets and common dialogs and how they behave.

A lot of people don't see it as "migrate from GTK 2.x to GTK 3.x" but "GIMP Toolkit 2.x has been end-of-lifed. Do I port to GNOME Toolkit 3.x, which happens to be a fork of it with a significantly different UI philosophy, or do I port to Qt, which seems more dedicated to providing a similar feature set and end-user experience?"

The fact that GIMP and GNOME have the same first letter hides a lot in that acronym.

So if there at least one gtk-only distro which used to ship your app or even some number of gtk-only users, who you "led to believe you will provide gtk-based app" you must be branded as a bad guy. By your own rule you trying to impose on GNOME. Will you accept this brand? Or, maybe we will throw away that rule as obviously unjust?

That's not as clever an argument as you think it is, given how things like the GTK+ 1.2 to 2.0 and 2.0 to 3.0 changes caused far more disruption of that nature.

By your own argument, the GNOME devs are "the bad guy" for not providing "GTK 1.2 API on top of 2.0" and "GTK 2.0 API on top of 3.0" compatibility shims akin to sdl12-compat to make up for how, due to lack of manpower, things like XMMS and BasiliskII took longer than distros were happy waiting to get GTK+ 2.x ports.

[Khrundel]

Actually they transformed the GTK from a toolkit to create open source applications from a toolkit to design Gnome only application. The most funny think is the former "Gimp ToolKit" are creating a lot of issues to Gimp since ended up that many widgets are unsuitable for its use cases.

This is factually incorrect. As usual, hatred toward GNOME comes from ignorance.
All this shitstorm started from their refusal to accept patch to, pay attention, libadwaita project. Doesn't this name tell you something?
There is still present GTK4, which support css themes as earlier. And there is libadwaita, additional library atop of GTK which was created to implement GNOME HIG and which disables external themes loading. So you can't blame they even for misleading anyone, no wonder libadwaita supports only adwaita, it is pretty obvious.

[Khrundel]

It can be digested like that... that doesn't mean it's true to reality to do so. That said, this is the Internet. You're free to give yourself indigestion if you want.

This is a factual description. It either correct or not. If it can be digested so, it should be. If you can give another, not some clever wording and vague philosophical stance, you are welcome to write it. But you avoiding any clarity.

I have yet to see a user upset due to my decisions

If your projects aren't so popular, that doesn't mean you are not guilty. You know you've broken your commandment.

If someone from the GNOME side gets upset that I'm following the desktops which used GTK 2.x but were never particularly wedded to the GNOME HIG as GNOME hammers the wedge in deeper, I'll be "the bad guy".

You've misrepresented what I've written.

I'm not the one hammering the wedge in, so why do I care if some people misattribute the blame?

No, it is fair to blame you. As long as you trying to judge GNOME for breaking arbitrary rule you've invented, you have to be judged by same rule. That would be fair.

I'd love to see you walk up to people like PCMan (lead developer of LXDE and author of PCManFM) and try to argue that a GTK-based GNOME competitor is obligated to be subservient to GNOME design guidelines without getting laughed at.

Why would I?

Fundamentally, you're arguing that anyone who builds anything with GTK is obligated to obey GNOME design guidelines... unless you're arguing that only stuff that's officially part of the Xfce or LXDE projects are allowed to design with the intent to fit into them rather than GNOME.

OMG.
Two GNOME haters (you and Danielsan) exchanging delusions within echo-chamber. It's libadwaita. Not GTK. To understand how stupid you both look, imagine someone would start to blame KDE team for implementing KDE-specific within kdelibs and after a week of arguments it becoming clear he believes changes were made within Qt.

Also, it's not just about theming. It's also about changing the available widgets and common dialogs and how they behave.

No, it is about theming only. You can't expect someone will filter and evaluate all your grudges.

By your own argument, the GNOME devs are "the bad guy" for not providing "GTK 1.2 API on top of 2.0" and "GTK 2.0 API on top of 3.0" compatibility shims akin to sdl12-compat to make up for how, due to lack of manpower, things like XMMS and BasiliskII took longer than distros were happy waiting to get GTK+ 2.x ports.

No, its by your own argument. I never accepted your rule about developer is not allowed to make major changes to their project or obliged to do something they don't need. I just explaining you that rule, you trying to impose on GNOME is impossible to follow.

I understand, being GNOME hater, it is difficult not to join fight. Just admit to yourself, these sleaky system76 guys have exploited you as unthinking ram while trying to force their interests. And next time spend 5 minutes to investigate issue.

[Khrundel]

By the way, lets imaging GNOME will do something to GTK. The whole point of opensource is that you always have a right to fork. So, even when your believe it is GTK theming was disabled, you can't seriously blame current maintainer, you should just fork and do as you wish.

[Danielsan]

Khrundel really don't care if you feel upset because someone is "hating" Gnome, which is not by the way.

What you would argue against us, gnome haters, has been kindly confirmed by Gnome itself:

Following these guidelines can be streamlined via a library offering tailored widgets and styles. This role has been filled by GTK because of its strong bonds with the GNOME project: Adwaita is both GNOME’s visual language and GTK’s default theme. This is somewhat problematic though, as GTK serves multiple audiences and platforms, and this favores GNOME over them.

(emphasis mine)

https://adrienplazas.com/blog/2021/0...ibadwaita.html

The rest of the article is unclear how about splitting libadwaita from GTK will benefit other projects (such as saying binding systemd on Gnome will help other init system), but who care? 5 of out of 7 core developers are from RH, while 6 out of 7 core developers are also Gnome Foundation Members and therefore projects that aren't affiliated with both are concerned because all of us already knew which will be the pattern.