23 ms·

> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. Choose

by bhaak 5y ago

> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.

dleslie 5y ago
Gnome has a fairly negative rep now, thanks in part to its repeated spurning of feature requests from developers and users. I remember when the Gnome desktop was exciting; there were frequently new apps to try, things pushing niche workflows that the Gnome team didn't consider. That all stopped with Gnome3.
- Cloudef 5y ago
  Gnome developers actively hate their users and non-gnome developers. This issue takes the cake: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217
  - Karunamon 5y ago
    Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule. To borrow a term or two, it's developed in the bazaar, but run like the cathedral. Maybe an open-air cathedral. Firefox is another project that I'd put under this label. All the important discussions happen in the back rooms, and by the time something universally unpopular hits the bug tracker, it's too late for users or the wider dev community to have any say.
    - zxzax 5y ago
      >Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule. That's not been my experience at all. The outrage machine on social media tends to spread around the small handful of patches that do get rejected so they can get angry about it, but they never talk about the other thousands of patches that do get accepted. Go look through all the other MRs on the gitlab if you don't believe me. Yes sometimes patches get rejected, it happens in any open source project.
      - traverseda 5y ago
        As a programmer Gnome has really damaged their relationship with a lot of developers. For example take a look here: https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 >I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry. Gnome kind of goes off and does it's own thing without thinking about or cooperating with other open source developers. [Here's](https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217) an example where they make a technical decisions that massively inconveniences a bunch of well known open source projects like GLFW and SDL (low-level cross-platform GUI toolkits). Gnome are not good citizens of the open source commons, they do things that make it much harder to create cross-platform/cross-DE apps. GTK used to be fairly vendor neutral, it was the "GIMP ToolKit", not the Gnome toolkit. It worked with any desktop environment you chose to use. Since then they've been making the toolkit much more dependent on Gnome specific features and actively been making the lives of everyone else more difficult. Also there are a lot of controversial decisions that make developers lives annoying, like [refusing to implement classic typeahead](https://gitlab.gnome.org/GNOME/nautilus/-/issues/244 https://gitlab.gnome.org/GNOME/nautilus/-/issues/244) instead relying on their search daemon which is really annoying for a lot of developers, and of course makes running a GTK app in a non-gnome desktop much worse. There are a few outstanding issues that make it annoying for developers to work with file paths under Gnome. So yeah, they've burnt a lot of developer good will and seem intent on continuing that trend. LXDE even switched to QT instead. Really made it so that the linux desktop is less of a stable/reliable thing to develop for. --- https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linux-platform-1/ https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linu... By refusing to cooperate with other open source projects they're really making it harder for open source developers to get things done and make new apps. Instead of having a common platform we now have gnome and everyone else, and there really are a lot of very obvious examples of that happening over the years.
        zxzax 5y ago
        Your first link is an issue that was posted over 10 years ago and was long resolved in other areas. It's not an illustrative example. I really wish people would stop trying to revive these ancient flamewars without acknowledging the current state of things (not saying this is your fault, but a little diligence always helps). The second two links you're posting are again, the exception, not the rule. The vast majority of patches are accepted, you just happened to stumble across two of the contentious ones that got a big outrage response on reddit. Please go look at the other thousands of issues and MRs against GTK if you don't believe me, it's not just GNOME people filing those. I would say I thoroughly agree with the last article you posted. There has never been a "Linux platform." It was always Motif versus KDE versus GNOME versus Enlightenment versus all the rest. Historically they only cooperated with each other on certain things. If none of them refused to cooperate, we would still probably be using Motif. We can come up with various reasons for why this fragmentation happened but placing all the blame for that on GNOME for going its on way doesn't make many sense when this fragmentation always existed.
    - specialist 5y ago
      > "free in license only" Very interesting. Thanks. Are you familiar with Bryan Cantrill's "right to fork, but not the power" observation? It deeply influenced me. Alas, I didn't find his post-mortem until after I already joined an FOSS effort (kauli.org). Which failed. For so many reasons. Neutering us contributors probably being foremost. Copypasta: OpenSolaris challenges • That certain critical bits had to remain proprietary made forking the operating system technically difﬁcult... • And that virtually all Solaris implementation knowledge lived within Sunʼs walls made it a practical impossibility • The community had the right to fork, but not the power • This led down the primrose path to open source governance: governing boards, elections, constitutions • And because all development on the system realistically required copyright assignment to Sun, OpenSolaris (sadly) remained a Sun puppet • Worse, some among Sunʼs middle management fancied themselves puppeteers... https://www.usenix.org/legacy/events/lisa11/tech/slides/cantrill.pdf https://www.usenix.org/legacy/events/lisa11/tech/slides/cant...
  - zxzax 5y ago
    I don't see why you are saying that has something to do with some attitude from GNOME. There are several Wayland compositors that don't implement that feature.
    - Cloudef 5y ago
      >There are several Wayland compositors that don't implement that feature. Can you list some that aren't weston or dead projects?
      - zxzax 5y ago
        I don't follow all the Wayland compositors but Enlightenment doesn't, and Weston matters here. If somebody really wants this to become standard, implementing it in Weston should be priority. Every compositor library I've looked at also considers this optional, e.g. mir, qtwayland, wlroots.
        Cloudef 5y ago
        Considering it got xdg prefix and was included in wayland-protocols that should be as standard as it gets. Weston is barebones "reference" compositor. It's not for normal use. Mir is dead. The xdg-decoration is based on KDE's own protocol, it was later refined and pushed to wayland-protocols by wlroots devs. Now kde uses the xdg-decoration too. >Every compositor library I've looked at also considers this optional Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.
        zxzax 5y ago
        Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b... >application have to explicitly ask for compositor to decorate the window. My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
  - akvadrako 5y ago
    If that's your best argument against Gnome it seems like they are doing pretty well. Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
    - Cloudef 5y ago
      Sure you can do everything with a library, and that's how you end up with library hell, or dependencies that will be hard to get rid of or replaced later, because how big they become or how broken the API was (e.g. fontconfig). But being the only ecosystem where that's needed is pushing some heavy boilerplate on developers. Why would games, or non-gnome apps care about decoration? There's plenty of good examples of applications where the decoration being forced on them doesn't make sense. The protocol is also standardized and gnome is the only wayland compositor that refuses to implement it, this is not the only case where gnome devs just decide to be jerks. Things like these are why I think I'll never will be using wayland as it just breaks everyone's existing applications and workflows. wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". And I speak as someone who wrote one of the first wayland compositors, and one of the first wayland compositor libraries, which code partially still exists in wlroots.
      - zxzax 5y ago
        >Why would games, or non-gnome apps care about decoration? I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations. >this is not the only case where gnome devs just decide to be jerks. Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers. >wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.
  - dleslie 5y ago
    I love how that thread is full of well-intentioned, respectful responses with deep technical knowledge and details; and the Gnome developers just won't budge. When, finally, it becomes clear that the user demands cannot be met and Gnome is woefully inadequate as a modern desktop due to their design decisions, the final post is: > Enough spam for today. Locking the issue. Gnome is dead. It has been taken over by toxic developers.
- zxzax 5y ago
  I know it's fun for people to hate on GNOME but if you actually read the bug reports, the feature was not rejected. The patch was rejected in favor of a different way to implement the feature.
  - traverseda 5y ago
    Having observed this for a while that often seems to be just the way Gnome works. Patches that help non-Gnome projects are held to a much higher (sometimes unobtainable) standard than patches that help members of the Gnome foundation. It seems very insular, and if you want to "scratch your own itch" as an outsider expect to take 5-20x as much effort for the same feature. There will always be a reason why this patch isn't acceptable, despite the overall code-quality in gnome projects being... what it is. I'd bet if a Gnome app needed this feature that patch would have been quickly and quietly accepted.
    - zxzax 5y ago
      Again if you actually read the bug report, it contradicts what you're saying. This patch was rejected because it created unnecessary work for terminals outside the GNOME project. The favored solution would help all terminals using that widget.
      - traverseda 5y ago
        Did they ever implement that solution?
        zxzax 5y ago
        It doesn't look like it, I'm sure they would be open to patches to help out there.
        traverseda 5y ago
        I'm a lot less sure, and the lack of clear requirements makes me even less certain. Also things like >adding only hooks for you means that all the other terminals get no benefit. Makes me quite concerned since these hooks weren't just for termite, as evidenced by tilix showing interest in this patch set. >Implementing this in VTE would mean ruling out having any flexibility in the terminal using the library. [...] an implementation inside VTE won't satisfy the use case. I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having, and the maintainer responded with a simple "wontfix" and no more discussion. This is kind of the thing we're talking about. One project said they needed this, another project said they'd also appreciate this feature, and instead of discussing how to make this work, setting clear requirements and the like, it took 2 years to respond to the first patch submission and then the issue was just randomly closed in the middle of a discussion.
- CrazyPyroLinux 5y ago
  I've never understood all the love and excitement and attention that GNOME has gotten ever since Canonical got behind it and dropped Unity. All the cheerleading over what seem like really basic fixes that haven't been a problem on other DEs, like "now the single-threaded shell crashes to login less often! Horray!" That's only intensified with 3.40 (Now hailed as "40" like a pop star using only their first name.) Apparently the top hot new feature is "horizontal workspaces"...mind-blowing.
- rkangel 5y ago
  > things pushing niche workflows that the Gnome team didn't consider On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. The laptop my partner uses at home is a slightly old Thinkpad I put Fedora on last year and it took her about 20 minutes to work out to use everything (less time than she took on a Mac). I think the Gnome developers have been pretty hostile to outside input and could have done a better job. But the fact that they've had a clear direction and haven't implemented everybody's personal preference has resulted in a coherent result without unnecessary cruft.
  - dleslie 5y ago
    My non-power-user wife, father and mother all prefer MATE. It works like Windows, which they are accustomed to. Edit: I don't get why this was down-voted, but OK.
  - rthomas6 5y ago
    > On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. I think Plasma and Cinnamon also belong in this group.
    - codemac 5y ago
      Considering Cinnamon is a fork of Gnome 3, it seems to be significant evidence of Gnome 3's influence. And Plasma was first released in 2014, 3 years after Gnome 3. Gnome 3 had a HUGE affect on desktop environments, due to Gnome 2's popularity.
      - sangnoir 5y ago
        Plasma's predecessor (KDE 3) is closer to Gnome that Plasma itself. Plasma is as close to an antithesis of Gnome as you could get (outside of tiling window managers) - everything is customizable/extensible
      - barrkel 5y ago
        Cinnamon basically makes Gnome feel more like Windows.
agumonkey 5y ago
time agnostic rule #1: people are people
- dsr_ 5y ago
  And people form tribes, and tribal allegiance becomes very important to them. In this case, both tribes (GNOME and Wayland) have a vision of the perfect way for software to work. They have each captured enough weak allegiance/users to prove to themselves that they are right. Therefore, the other side is wrong.
  - turminal 5y ago
    The problem with this analogy is that nobody knows that Gnome != wayland. Not even gnome developers know gnome != wayland. As a result, a lot of people hate wayland because of gnome's failed switch to wayland. And a lot of people hate gnome for their pretentiousness.
thayne 5y ago
Sadly, I don't know of a good alternative to GTK. Qt, being C++ is more difficult to bind to from other languages, and doesn't seem to integrate quite as well with XDG/Linux standards, unless you use KDE which is a much heavier dependency.
- Cloudef 5y ago
  I wish blender's UI toolkit was separated into own library. It's pretty much the best UI I've used, and I like blender for other reasons too (it doesn't open multiple windows, popups or nags, everything's contained in it). Immediate mode UI framework that actually supports accessibility stuff would be neat too.
- edflsafoiewq 5y ago
  This is why people use electron.
matheusmoreira 5y ago
> don't make the mistake of thinking their libraries are meant for others to use I agree. This presentation convinced me: https://youtu.be/ON0A1dsQOV0?t=2468 https://youtu.be/ON0A1dsQOV0?t=2468 GTK+ is really just a toolkit for GNOME projects. All other users are secondary.
- zxzax 5y ago
  To give another perspective, that presentation is from 7 years ago and does not reflect the current state of things. The situation has improved and currently some GNOME functionality is being moved out of GTK into a new library, so GTK can focus on being its own library: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/introducing-libadwaita.html https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...
  - hitekker 5y ago
    Are you affiliated with GNOME?
    - zxzax 5y ago
      No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
      - j-james 5y ago
        Based on my personal interactions with GNOME developers and unresolved bugs, I suspect your experience is the exception, not the broad norm.
        zxzax 5y ago
        I don't meant to say it doesn't have bugs, of course it does. Every project has bugs. As with all open source, submitting patches to fix those bugs will usually go farther than patiently waiting and hoping that another volunteer will get frustrated enough by the bug to fix it eventually. The obvious segfault bugs that affect everyone badly will tend to get fixed pretty fast, the more obscure ones that arise from weird use of widgets (and need a lot of in-depth debugging) are a harder thing to ask a volunteer to spend their time on.
infogulch 5y ago
I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look: > In reply to Daniel Micay from comment #10: > > Implementing this in VTE would mean ruling out having any flexibility in the > > terminal using the library. I haven't responded any more here because an > > implementation inside VTE won't satisfy the use case. > > Implementing keyboard selection inside vte means that *every* terminal based > on vte benefits; adding only hooks for you means that all the other terminals > get *no* benefit. This seems like a pretty shallow argument. What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? Or, stated another way, why is gnome terminal entitled to receive all the features built on top of GTK component apis used by other projects? He's stating the conclusion that VTE is the correct layer to implement the end-user highlight/selection feature without actually making an explicit case for it, and without acknowledging that there's an argument that the layer above could actually be a better location to implement the feature. Thoughts? [1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12 https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12
- zxzax 5y ago
  >What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-289286939 https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
  - infogulch 5y ago
    Yes that's the case Christian was making (implicitly). Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.
nh2 5y ago
I was also disappointed by the recent removal of static linking support in GTK [1]. It worked for a long time and now was made impossible. The reason given was "don't want to support it". That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mind will link to internal symbols anyway. In my opinion, an application developer should be able to choose how to link their program; toolkit developers should not forbid one way if there isn't a good technical reason. [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_1099438 https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109943...
- zxzax 5y ago
  Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
  - nh2 5y ago
    Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).
    - zxzax 5y ago
      Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson. If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
      - nh2 5y ago

by bhaak 5y ago

dleslie 5y ago

Gnome has a fairly negative rep now, thanks in part to its repeated spurning of feature requests from developers and users. I remember when the Gnome desktop was exciting; there were frequently new apps to try, things pushing niche workflows that the Gnome team didn't consider. That all stopped with Gnome3.

Cloudef 5y ago
Gnome developers actively hate their users and non-gnome developers. This issue takes the cake: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217
- Karunamon 5y ago
  Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule. To borrow a term or two, it's developed in the bazaar, but run like the cathedral. Maybe an open-air cathedral. Firefox is another project that I'd put under this label. All the important discussions happen in the back rooms, and by the time something universally unpopular hits the bug tracker, it's too late for users or the wider dev community to have any say.
  - zxzax 5y ago
    >Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule. That's not been my experience at all. The outrage machine on social media tends to spread around the small handful of patches that do get rejected so they can get angry about it, but they never talk about the other thousands of patches that do get accepted. Go look through all the other MRs on the gitlab if you don't believe me. Yes sometimes patches get rejected, it happens in any open source project.
    - traverseda 5y ago
      As a programmer Gnome has really damaged their relationship with a lot of developers. For example take a look here: https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 >I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry. Gnome kind of goes off and does it's own thing without thinking about or cooperating with other open source developers. [Here's](https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217) an example where they make a technical decisions that massively inconveniences a bunch of well known open source projects like GLFW and SDL (low-level cross-platform GUI toolkits). Gnome are not good citizens of the open source commons, they do things that make it much harder to create cross-platform/cross-DE apps. GTK used to be fairly vendor neutral, it was the "GIMP ToolKit", not the Gnome toolkit. It worked with any desktop environment you chose to use. Since then they've been making the toolkit much more dependent on Gnome specific features and actively been making the lives of everyone else more difficult. Also there are a lot of controversial decisions that make developers lives annoying, like [refusing to implement classic typeahead](https://gitlab.gnome.org/GNOME/nautilus/-/issues/244 https://gitlab.gnome.org/GNOME/nautilus/-/issues/244) instead relying on their search daemon which is really annoying for a lot of developers, and of course makes running a GTK app in a non-gnome desktop much worse. There are a few outstanding issues that make it annoying for developers to work with file paths under Gnome. So yeah, they've burnt a lot of developer good will and seem intent on continuing that trend. LXDE even switched to QT instead. Really made it so that the linux desktop is less of a stable/reliable thing to develop for. --- https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linux-platform-1/ https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linu... By refusing to cooperate with other open source projects they're really making it harder for open source developers to get things done and make new apps. Instead of having a common platform we now have gnome and everyone else, and there really are a lot of very obvious examples of that happening over the years.
      - zxzax 5y ago
        Your first link is an issue that was posted over 10 years ago and was long resolved in other areas. It's not an illustrative example. I really wish people would stop trying to revive these ancient flamewars without acknowledging the current state of things (not saying this is your fault, but a little diligence always helps). The second two links you're posting are again, the exception, not the rule. The vast majority of patches are accepted, you just happened to stumble across two of the contentious ones that got a big outrage response on reddit. Please go look at the other thousands of issues and MRs against GTK if you don't believe me, it's not just GNOME people filing those. I would say I thoroughly agree with the last article you posted. There has never been a "Linux platform." It was always Motif versus KDE versus GNOME versus Enlightenment versus all the rest. Historically they only cooperated with each other on certain things. If none of them refused to cooperate, we would still probably be using Motif. We can come up with various reasons for why this fragmentation happened but placing all the blame for that on GNOME for going its on way doesn't make many sense when this fragmentation always existed.
  - specialist 5y ago
    > "free in license only" Very interesting. Thanks. Are you familiar with Bryan Cantrill's "right to fork, but not the power" observation? It deeply influenced me. Alas, I didn't find his post-mortem until after I already joined an FOSS effort (kauli.org). Which failed. For so many reasons. Neutering us contributors probably being foremost. Copypasta: OpenSolaris challenges • That certain critical bits had to remain proprietary made forking the operating system technically difﬁcult... • And that virtually all Solaris implementation knowledge lived within Sunʼs walls made it a practical impossibility • The community had the right to fork, but not the power • This led down the primrose path to open source governance: governing boards, elections, constitutions • And because all development on the system realistically required copyright assignment to Sun, OpenSolaris (sadly) remained a Sun puppet • Worse, some among Sunʼs middle management fancied themselves puppeteers... https://www.usenix.org/legacy/events/lisa11/tech/slides/cantrill.pdf https://www.usenix.org/legacy/events/lisa11/tech/slides/cant...
- zxzax 5y ago
  I don't see why you are saying that has something to do with some attitude from GNOME. There are several Wayland compositors that don't implement that feature.
  - Cloudef 5y ago
    >There are several Wayland compositors that don't implement that feature. Can you list some that aren't weston or dead projects?
    - zxzax 5y ago
      I don't follow all the Wayland compositors but Enlightenment doesn't, and Weston matters here. If somebody really wants this to become standard, implementing it in Weston should be priority. Every compositor library I've looked at also considers this optional, e.g. mir, qtwayland, wlroots.
      - Cloudef 5y ago
        Considering it got xdg prefix and was included in wayland-protocols that should be as standard as it gets. Weston is barebones "reference" compositor. It's not for normal use. Mir is dead. The xdg-decoration is based on KDE's own protocol, it was later refined and pushed to wayland-protocols by wlroots devs. Now kde uses the xdg-decoration too. >Every compositor library I've looked at also considers this optional Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.
        zxzax 5y ago
        Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b... >application have to explicitly ask for compositor to decorate the window. My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
- akvadrako 5y ago
  If that's your best argument against Gnome it seems like they are doing pretty well. Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
  - Cloudef 5y ago
    Sure you can do everything with a library, and that's how you end up with library hell, or dependencies that will be hard to get rid of or replaced later, because how big they become or how broken the API was (e.g. fontconfig). But being the only ecosystem where that's needed is pushing some heavy boilerplate on developers. Why would games, or non-gnome apps care about decoration? There's plenty of good examples of applications where the decoration being forced on them doesn't make sense. The protocol is also standardized and gnome is the only wayland compositor that refuses to implement it, this is not the only case where gnome devs just decide to be jerks. Things like these are why I think I'll never will be using wayland as it just breaks everyone's existing applications and workflows. wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". And I speak as someone who wrote one of the first wayland compositors, and one of the first wayland compositor libraries, which code partially still exists in wlroots.
    - zxzax 5y ago
      >Why would games, or non-gnome apps care about decoration? I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations. >this is not the only case where gnome devs just decide to be jerks. Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers. >wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.
- dleslie 5y ago
  I love how that thread is full of well-intentioned, respectful responses with deep technical knowledge and details; and the Gnome developers just won't budge. When, finally, it becomes clear that the user demands cannot be met and Gnome is woefully inadequate as a modern desktop due to their design decisions, the final post is: > Enough spam for today. Locking the issue. Gnome is dead. It has been taken over by toxic developers.
zxzax 5y ago
I know it's fun for people to hate on GNOME but if you actually read the bug reports, the feature was not rejected. The patch was rejected in favor of a different way to implement the feature.
- traverseda 5y ago
  Having observed this for a while that often seems to be just the way Gnome works. Patches that help non-Gnome projects are held to a much higher (sometimes unobtainable) standard than patches that help members of the Gnome foundation. It seems very insular, and if you want to "scratch your own itch" as an outsider expect to take 5-20x as much effort for the same feature. There will always be a reason why this patch isn't acceptable, despite the overall code-quality in gnome projects being... what it is. I'd bet if a Gnome app needed this feature that patch would have been quickly and quietly accepted.
  - zxzax 5y ago
    Again if you actually read the bug report, it contradicts what you're saying. This patch was rejected because it created unnecessary work for terminals outside the GNOME project. The favored solution would help all terminals using that widget.
    - traverseda 5y ago
      Did they ever implement that solution?
      - zxzax 5y ago
        It doesn't look like it, I'm sure they would be open to patches to help out there.
        traverseda 5y ago
        I'm a lot less sure, and the lack of clear requirements makes me even less certain. Also things like >adding only hooks for you means that all the other terminals get no benefit. Makes me quite concerned since these hooks weren't just for termite, as evidenced by tilix showing interest in this patch set. >Implementing this in VTE would mean ruling out having any flexibility in the terminal using the library. [...] an implementation inside VTE won't satisfy the use case. I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having, and the maintainer responded with a simple "wontfix" and no more discussion. This is kind of the thing we're talking about. One project said they needed this, another project said they'd also appreciate this feature, and instead of discussing how to make this work, setting clear requirements and the like, it took 2 years to respond to the first patch submission and then the issue was just randomly closed in the middle of a discussion.
CrazyPyroLinux 5y ago
I've never understood all the love and excitement and attention that GNOME has gotten ever since Canonical got behind it and dropped Unity. All the cheerleading over what seem like really basic fixes that haven't been a problem on other DEs, like "now the single-threaded shell crashes to login less often! Horray!" That's only intensified with 3.40 (Now hailed as "40" like a pop star using only their first name.) Apparently the top hot new feature is "horizontal workspaces"...mind-blowing.
rkangel 5y ago
> things pushing niche workflows that the Gnome team didn't consider On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. The laptop my partner uses at home is a slightly old Thinkpad I put Fedora on last year and it took her about 20 minutes to work out to use everything (less time than she took on a Mac). I think the Gnome developers have been pretty hostile to outside input and could have done a better job. But the fact that they've had a clear direction and haven't implemented everybody's personal preference has resulted in a coherent result without unnecessary cruft.
- dleslie 5y ago
  My non-power-user wife, father and mother all prefer MATE. It works like Windows, which they are accustomed to. Edit: I don't get why this was down-voted, but OK.
- rthomas6 5y ago
  > On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. I think Plasma and Cinnamon also belong in this group.
  - codemac 5y ago
    Considering Cinnamon is a fork of Gnome 3, it seems to be significant evidence of Gnome 3's influence. And Plasma was first released in 2014, 3 years after Gnome 3. Gnome 3 had a HUGE affect on desktop environments, due to Gnome 2's popularity.
    - sangnoir 5y ago
      Plasma's predecessor (KDE 3) is closer to Gnome that Plasma itself. Plasma is as close to an antithesis of Gnome as you could get (outside of tiling window managers) - everything is customizable/extensible
    - barrkel 5y ago
      Cinnamon basically makes Gnome feel more like Windows.

agumonkey 5y ago

time agnostic rule #1: people are people

dsr_ 5y ago
And people form tribes, and tribal allegiance becomes very important to them. In this case, both tribes (GNOME and Wayland) have a vision of the perfect way for software to work. They have each captured enough weak allegiance/users to prove to themselves that they are right. Therefore, the other side is wrong.
- turminal 5y ago
  The problem with this analogy is that nobody knows that Gnome != wayland. Not even gnome developers know gnome != wayland. As a result, a lot of people hate wayland because of gnome's failed switch to wayland. And a lot of people hate gnome for their pretentiousness.

thayne 5y ago

Sadly, I don't know of a good alternative to GTK. Qt, being C++ is more difficult to bind to from other languages, and doesn't seem to integrate quite as well with XDG/Linux standards, unless you use KDE which is a much heavier dependency.

Cloudef 5y ago
I wish blender's UI toolkit was separated into own library. It's pretty much the best UI I've used, and I like blender for other reasons too (it doesn't open multiple windows, popups or nags, everything's contained in it). Immediate mode UI framework that actually supports accessibility stuff would be neat too.
edflsafoiewq 5y ago
This is why people use electron.

matheusmoreira 5y ago

> don't make the mistake of thinking their libraries are meant for others to use I agree. This presentation convinced me: https://youtu.be/ON0A1dsQOV0?t=2468 https://youtu.be/ON0A1dsQOV0?t=2468 GTK+ is really just a toolkit for GNOME projects. All other users are secondary.

zxzax 5y ago
To give another perspective, that presentation is from 7 years ago and does not reflect the current state of things. The situation has improved and currently some GNOME functionality is being moved out of GTK into a new library, so GTK can focus on being its own library: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/introducing-libadwaita.html https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...
- hitekker 5y ago
  Are you affiliated with GNOME?
  - zxzax 5y ago
    No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
    - j-james 5y ago
      Based on my personal interactions with GNOME developers and unresolved bugs, I suspect your experience is the exception, not the broad norm.
      - zxzax 5y ago
        I don't meant to say it doesn't have bugs, of course it does. Every project has bugs. As with all open source, submitting patches to fix those bugs will usually go farther than patiently waiting and hoping that another volunteer will get frustrated enough by the bug to fix it eventually. The obvious segfault bugs that affect everyone badly will tend to get fixed pretty fast, the more obscure ones that arise from weird use of widgets (and need a lot of in-depth debugging) are a harder thing to ask a volunteer to spend their time on.

infogulch 5y ago

I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look: > In reply to Daniel Micay from comment #10: > > Implementing this in VTE would mean ruling out having any flexibility in the > > terminal using the library. I haven't responded any more here because an > > implementation inside VTE won't satisfy the use case. > > Implementing keyboard selection inside vte means that *every* terminal based > on vte benefits; adding only hooks for you means that all the other terminals > get *no* benefit. This seems like a pretty shallow argument. What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? Or, stated another way, why is gnome terminal entitled to receive all the features built on top of GTK component apis used by other projects? He's stating the conclusion that VTE is the correct layer to implement the end-user highlight/selection feature without actually making an explicit case for it, and without acknowledging that there's an argument that the layer above could actually be a better location to implement the feature. Thoughts? [1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12 https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12

zxzax 5y ago
>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-289286939 https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
- infogulch 5y ago
  Yes that's the case Christian was making (implicitly). Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.

nh2 5y ago

I was also disappointed by the recent removal of static linking support in GTK [1]. It worked for a long time and now was made impossible. The reason given was "don't want to support it". That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mind will link to internal symbols anyway. In my opinion, an application developer should be able to choose how to link their program; toolkit developers should not forbid one way if there isn't a good technical reason. [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_1099438 https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109943...

zxzax 5y ago
Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
- nh2 5y ago
  Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).
  - zxzax 5y ago
    Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson. If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
    - nh2 5y ago