Happy Birthday GNOME! 25 years today(happybirthdaygnome.org)
happybirthdaygnome.org
Happy Birthday GNOME! 25 years today
https://happybirthdaygnome.org/
112 comments
I use KDE daily and I don't see what your point is. I don't know Gnome because I don't use it, but saying that we have big GUI problems seems far fetched to me.
I have a launcher, I can alt-tab between apps, I have a very nice file mananger, a pretty good console and, well, hemm, that's basically all I need. Ah yes, the BlueTooth thing is working but that user friendly; USB stick mounting is not super nice but works, everything is GPU accelerated (but tearing happens all over the palce), etc. So, yeah, it lacks polish here and there but it certainly does the job. Plus I get to read tons of community stuff about the platform.
I'm sure Gnome can't be that different and thus, we should be happy that the community has been able to pull out 2 major D.E. plus a myriad of smaller ones.
Happy birthday Gnome !
I have a launcher, I can alt-tab between apps, I have a very nice file mananger, a pretty good console and, well, hemm, that's basically all I need. Ah yes, the BlueTooth thing is working but that user friendly; USB stick mounting is not super nice but works, everything is GPU accelerated (but tearing happens all over the palce), etc. So, yeah, it lacks polish here and there but it certainly does the job. Plus I get to read tons of community stuff about the platform.
I'm sure Gnome can't be that different and thus, we should be happy that the community has been able to pull out 2 major D.E. plus a myriad of smaller ones.
Happy birthday Gnome !
> I have a very nice file mananger, a pretty good console and, well, hemm, that's basically all I need
This is exactly the problem. A vocal minority only needs a small subset of features, and criticise anybody that want a little more from their desktop, or at least to reach parity with commercial offerings. And then immediately go on to list all the problems with the free desktops.
What about:
* Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.)
* Fractional scaling (common retort: Wayland does it, but see above)
* VR support (common retort: I just need a shell, tyvm)
* Lack of tearing across all 3 GPU vendors (common retort: see your comment, "I don't need it". Wayland does it, but Wayland bad)
* Variable Refresh Rate interface across all 3 GPU vendors (common retort: I just need this option in xorg.conf, if you're on NVIDIA it's your problem)
etc.
As I said before, I'm fine with everybody doing their own thing. But please be mindful that what works for you, doesn't work for anybody. There's a selfishness and clique mindset that is very hard to like among Linux users.
We're slowly getting to a better Linux desktop despite its users constantly bickering and pushing back any form of change that might improve their OS. It's a collective Stockholm Syndrome.
https://xkcd.com/1172/
This is exactly the problem. A vocal minority only needs a small subset of features, and criticise anybody that want a little more from their desktop, or at least to reach parity with commercial offerings. And then immediately go on to list all the problems with the free desktops.
What about:
* Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.)
* Fractional scaling (common retort: Wayland does it, but see above)
* VR support (common retort: I just need a shell, tyvm)
* Lack of tearing across all 3 GPU vendors (common retort: see your comment, "I don't need it". Wayland does it, but Wayland bad)
* Variable Refresh Rate interface across all 3 GPU vendors (common retort: I just need this option in xorg.conf, if you're on NVIDIA it's your problem)
etc.
As I said before, I'm fine with everybody doing their own thing. But please be mindful that what works for you, doesn't work for anybody. There's a selfishness and clique mindset that is very hard to like among Linux users.
We're slowly getting to a better Linux desktop despite its users constantly bickering and pushing back any form of change that might improve their OS. It's a collective Stockholm Syndrome.
https://xkcd.com/1172/
My understanding is that fractional scaling actually works a fair bit better under QT at the moment, although maybe things have changed on the bleeding edge. KDE on wayland works great for me.
Wayland doesn't make it any easier to get fractional scaling, obviously. It's up to the toolkits to support fractional scaling, and while you can magnify a window by like 1.2x under wayland it's going to get blurry, you're essentially just up-scaling an image.
Wayland doesn't make it any easier to get fractional scaling, obviously. It's up to the toolkits to support fractional scaling, and while you can magnify a window by like 1.2x under wayland it's going to get blurry, you're essentially just up-scaling an image.
Thanks for your answer.
So maybe we'd need some kind of poll to know what all of us collectively need. And I'm sure those who make Gnome (many at RedHat I think) have an idea. So maybe there is some interest, or unfortunate planets alignment that makes "simple" users to be second class citizen. That is, Wayland, VR, tearing are not things that prevent one of completing a professional task so they just don't get fixed...
My point was that I see many area of improvements but none of them prevents me of being happy (I use my Linux DE 80% professional and 20% leisure; or 5% movies and 95% browser/coding). It seems that some of these areas are not on the improvement level for you but on the indispensable one. So as you said, there's some personal appreciation going on. So for me the equation is more like FLOSS quality + licenses >= proprietary quality + license. That is, I value the license difference more than the quality difference; hence I'm pretty happy with many sub standard tools :-)
So now, in your list, the tearing is clearly, for me, the most painful issue at the moment. Watching movies is a bit painful at times.
So in the end, well, ain't sure anything gonna change soon. But the sooner the better, I agree on that :-)
So maybe we'd need some kind of poll to know what all of us collectively need. And I'm sure those who make Gnome (many at RedHat I think) have an idea. So maybe there is some interest, or unfortunate planets alignment that makes "simple" users to be second class citizen. That is, Wayland, VR, tearing are not things that prevent one of completing a professional task so they just don't get fixed...
My point was that I see many area of improvements but none of them prevents me of being happy (I use my Linux DE 80% professional and 20% leisure; or 5% movies and 95% browser/coding). It seems that some of these areas are not on the improvement level for you but on the indispensable one. So as you said, there's some personal appreciation going on. So for me the equation is more like FLOSS quality + licenses >= proprietary quality + license. That is, I value the license difference more than the quality difference; hence I'm pretty happy with many sub standard tools :-)
So now, in your list, the tearing is clearly, for me, the most painful issue at the moment. Watching movies is a bit painful at times.
So in the end, well, ain't sure anything gonna change soon. But the sooner the better, I agree on that :-)
Red-Hat has decided there is no money to be taken in Linux Desktop, the extent they improve GNOME is that even enterprises need some kind of basic GUI to manage their workstations.
https://lwn.net/Articles/56947/
https://lwn.net/Articles/56947/
Canonical has seemingly also decided the same thing when they cancelled Unity. And I do not blame them. Has anyone you know actually paid for a Linux desktop, outside of buying some really basic and general enterprise support?
Back in the year days of desktop dream it was common to buy Manadrake and SuSE in their respective CD/DVD software box.
For example, https://lizards.opensuse.org/2011/05/03/vintage/
But that was 20 years ago.
For example, https://lizards.opensuse.org/2011/05/03/vintage/
But that was 20 years ago.
> * Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.)
That might be the common retort but according to this opinion piece there's more going on:
https://news.itsfoss.com/wayland-core-protocol-issue/
If you accept that opinion piece then it's more that Wayland doesn't need anything but GNOME. KDE and others have been working hard to function well on Wayland and have made decent progress while still offering new features (like fractional scaling) given that they weren't really a consideration when Wayland started.
That might be the common retort but according to this opinion piece there's more going on:
https://news.itsfoss.com/wayland-core-protocol-issue/
If you accept that opinion piece then it's more that Wayland doesn't need anything but GNOME. KDE and others have been working hard to function well on Wayland and have made decent progress while still offering new features (like fractional scaling) given that they weren't really a consideration when Wayland started.
That article is pretty rambling and the conclusion does not make a lot of sense. GNOME also does not really support custom panels on X11 either (unless you use an extension). If they do not want to support custom panels then that is their decision, it should not have any influence on what other desktops decide to do.
In my personal opinion, all those panel and decoration protocols are broken and are needlessly recreating many of the same problems as were present in X11.
In my personal opinion, all those panel and decoration protocols are broken and are needlessly recreating many of the same problems as were present in X11.
Thanks for the fact check. The article was labelled as opinion, and itsfoss.com can be a little rambling at its best, so it's good to hear a more informed counter-point.
> Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.)
Wayland is -trying to be- a means to an end, not an end by itself.
> Fractional scaling (common retort: Wayland does it, but see above)
This is really a toolkit (and to some extent window manager) issue, not a window system issue. You can have fractional scaling in both Wayland and X11, as long as the underlying toolkit (or the framework above it) can do it. For example Lazarus / LCL applications support fractional scaling in X11 even with the Gtk2 backend (which itself doesn't support fractional scaling) by doing the scaling.
Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things (e.g. being able to have per-window, per-application, per-output scaling values, independent of each other and independent of the DPI - after all i may want to scale some windows at 300% on a "regular DPI" monitor because i am taking a screencast that i want to be readable on YouTube even at bitrates).
> VR support
Last time i checked the issue was mainly that the space is very dependent on proprietary technologies - at least for the headsets that people would want to use. Valve has done some low level work (or, paid external people to do low level work, anyway) but even them have their own solution which i think is bound to Steam instead of some standardized way that can be used by any application.
> Lack of tearing across all 3 GPU vendors (common retort: see your comment, "I don't need it". Wayland does it, but Wayland bad)
Lack of tearing where? Depending on where you mean it, this can be a feature instead of a problem (or at least any solution would introduce unacceptable problems). For example i prefer (i.e. it isn't a case of not caring, i actively prefer it) to have tearing on my desktop when moving/resizing windows, etc than have everything tied to the monitor's refresh rate because it makes the desktop feel much more responsive. Similarly for games where i use the mouse, i also prefer tearing to vsync because it reduces input lag (especially with some FP games that have their own issues, but the lag is there even with perfectly written games - this isn't just a workaround to the problem if badly written games, the badly written games are making it worse, but the problem is there even with good written games).
On the other hand tearing during video playback is undesirable to me, of course (though with a high refresh rate monitor it isn't very noticeable - but i do not always use one).
In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory and the vblank_mode environment variable. My approach is simple: in the .drirc file i have the vblank_mode to 0 which forces all applications to ignore any requests for synchronizing with the refresh rate, but when playing a video (or want to run some game or application with vsync for some reason) i run it as vblank_mode=3 vlc filename (actually i use a script for that that is launched by my file manager so i don't really type it but the same idea).
> * Variable Refresh Rate interface across all 3 GPU vendors (common retort: I just need this option in xorg.conf, if you're on NVIDIA it's your problem)
Well, yes, it is your problem, whose problem would it be when it was your choice to buy from a vendor who has repeatedly shown disdain towards working with the community?
My AMD GPU works perfectly fine with my VRR monitor under Xorg and i'm certain that the Intel iGPU on my laptop would also work fine if i connected the monitor to it - but both of these GPUs have open source drivers with support from their vendors.
> But please be mindful that what works for you, doesn't work for anybody. There's a selfishness and clique mindset that is very hard to like among Linux users. [...] We're slowly getting to a better Linux desktop despite its users constantly bickering and pushing back any form of change that might improve their OS. It's a collective Stockholm Syndrome.
You realize that with the latter part you are basically doing the exact same thing you describe with the first part, right? The people who you see "constantly bickering and pushing back any form of change" may actually see things that change in ways that do not work for them, thus making their experience of using their computers worse.
This is why when making such "improvements" it is important to do it ways that doesn't invalidate existing practices - which also implies doing things in modular and replaceable ways instead of moving towards monolithic designs.
(also i'm going to assume that in the first sentence you meant "doesn't work for everybody", not "anybody" since that wouldn't make logical sense unless you wanted to say "what works for you works only for you and nobody else")
Wayland is -trying to be- a means to an end, not an end by itself.
> Fractional scaling (common retort: Wayland does it, but see above)
This is really a toolkit (and to some extent window manager) issue, not a window system issue. You can have fractional scaling in both Wayland and X11, as long as the underlying toolkit (or the framework above it) can do it. For example Lazarus / LCL applications support fractional scaling in X11 even with the Gtk2 backend (which itself doesn't support fractional scaling) by doing the scaling.
Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things (e.g. being able to have per-window, per-application, per-output scaling values, independent of each other and independent of the DPI - after all i may want to scale some windows at 300% on a "regular DPI" monitor because i am taking a screencast that i want to be readable on YouTube even at bitrates).
> VR support
Last time i checked the issue was mainly that the space is very dependent on proprietary technologies - at least for the headsets that people would want to use. Valve has done some low level work (or, paid external people to do low level work, anyway) but even them have their own solution which i think is bound to Steam instead of some standardized way that can be used by any application.
> Lack of tearing across all 3 GPU vendors (common retort: see your comment, "I don't need it". Wayland does it, but Wayland bad)
Lack of tearing where? Depending on where you mean it, this can be a feature instead of a problem (or at least any solution would introduce unacceptable problems). For example i prefer (i.e. it isn't a case of not caring, i actively prefer it) to have tearing on my desktop when moving/resizing windows, etc than have everything tied to the monitor's refresh rate because it makes the desktop feel much more responsive. Similarly for games where i use the mouse, i also prefer tearing to vsync because it reduces input lag (especially with some FP games that have their own issues, but the lag is there even with perfectly written games - this isn't just a workaround to the problem if badly written games, the badly written games are making it worse, but the problem is there even with good written games).
On the other hand tearing during video playback is undesirable to me, of course (though with a high refresh rate monitor it isn't very noticeable - but i do not always use one).
In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory and the vblank_mode environment variable. My approach is simple: in the .drirc file i have the vblank_mode to 0 which forces all applications to ignore any requests for synchronizing with the refresh rate, but when playing a video (or want to run some game or application with vsync for some reason) i run it as vblank_mode=3 vlc filename (actually i use a script for that that is launched by my file manager so i don't really type it but the same idea).
> * Variable Refresh Rate interface across all 3 GPU vendors (common retort: I just need this option in xorg.conf, if you're on NVIDIA it's your problem)
Well, yes, it is your problem, whose problem would it be when it was your choice to buy from a vendor who has repeatedly shown disdain towards working with the community?
My AMD GPU works perfectly fine with my VRR monitor under Xorg and i'm certain that the Intel iGPU on my laptop would also work fine if i connected the monitor to it - but both of these GPUs have open source drivers with support from their vendors.
> But please be mindful that what works for you, doesn't work for anybody. There's a selfishness and clique mindset that is very hard to like among Linux users. [...] We're slowly getting to a better Linux desktop despite its users constantly bickering and pushing back any form of change that might improve their OS. It's a collective Stockholm Syndrome.
You realize that with the latter part you are basically doing the exact same thing you describe with the first part, right? The people who you see "constantly bickering and pushing back any form of change" may actually see things that change in ways that do not work for them, thus making their experience of using their computers worse.
This is why when making such "improvements" it is important to do it ways that doesn't invalidate existing practices - which also implies doing things in modular and replaceable ways instead of moving towards monolithic designs.
(also i'm going to assume that in the first sentence you meant "doesn't work for everybody", not "anybody" since that wouldn't make logical sense unless you wanted to say "what works for you works only for you and nobody else")
>Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale
Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland.
>For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory
>Well, yes, it is your problem
This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland.
>For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory
>Well, yes, it is your problem
This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
> Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland.
You'll need to explain why and how it is "flawed and inferior", because the way i see it a Window Manager is responsible for managing windows and has an overview of all (toplevel) windows on the system (as a result of being responsible for them) and its placement and setup (e.g. in which monitor it is, what state -minimized, rolled up, maximized, etc- it is, etc). As such, like how it moves windows around, updates its state (minized, rolled, etc) it can also update the window's scale factor.
The main difference here is that the window needs to know how to scale itself, but this isn't that different from knowing how to handle arbitrary sizes when getting resized.
The idea isn't that weird (and honestly Windows does something similar so toolkits that work on Windows would need little change to support the same functionality on X):
1. Applications/toolkits that do not support the protocol will be scaled by the window manager, if possible (via, e.g, composition, note that a window can be composed without composing the full desktop - though there might be some corner cases here that need tweaks on the X server - a full desktop compositor will have no issues here however)
2. Applications/toolkits that do support the protocol but are running under a window manager that doesn't support it will do their scaling themselves by using the appropriate X APIs (RandR provides per-output DPI info that can be scaled, though a toolkit can also have user-wide settings for providing DPI-independent scaling settings per monitor) and geometry notifications
3. Applications/toolkits that do support the protocol and are running under a window manager that does support it (which can be known by a root window attribute and the application can also use a window attribute to specify that the window "speaks" the protocol) will receive scaling events from the window manager. The logic for these scaling values would be up to the window manager (e.g. per-output, per-monitor, per-application scaling but also could be some option in a context menu in the titlebar that provides scaling values and/or have some shortcut keys to scale up/down).
For #3 there could also be a message for the window manager to request scaling for a window so that, e.g. something like xdotool could provide such requests via the command like.
> It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
Then i suggest making better effort towards understanding what others write or at least ask clarifications (like i did at my first response in this comment) because making the assumption that it doesn't move a discussion forward.
You'll need to explain why and how it is "flawed and inferior", because the way i see it a Window Manager is responsible for managing windows and has an overview of all (toplevel) windows on the system (as a result of being responsible for them) and its placement and setup (e.g. in which monitor it is, what state -minimized, rolled up, maximized, etc- it is, etc). As such, like how it moves windows around, updates its state (minized, rolled, etc) it can also update the window's scale factor.
The main difference here is that the window needs to know how to scale itself, but this isn't that different from knowing how to handle arbitrary sizes when getting resized.
The idea isn't that weird (and honestly Windows does something similar so toolkits that work on Windows would need little change to support the same functionality on X):
1. Applications/toolkits that do not support the protocol will be scaled by the window manager, if possible (via, e.g, composition, note that a window can be composed without composing the full desktop - though there might be some corner cases here that need tweaks on the X server - a full desktop compositor will have no issues here however)
2. Applications/toolkits that do support the protocol but are running under a window manager that doesn't support it will do their scaling themselves by using the appropriate X APIs (RandR provides per-output DPI info that can be scaled, though a toolkit can also have user-wide settings for providing DPI-independent scaling settings per monitor) and geometry notifications
3. Applications/toolkits that do support the protocol and are running under a window manager that does support it (which can be known by a root window attribute and the application can also use a window attribute to specify that the window "speaks" the protocol) will receive scaling events from the window manager. The logic for these scaling values would be up to the window manager (e.g. per-output, per-monitor, per-application scaling but also could be some option in a context menu in the titlebar that provides scaling values and/or have some shortcut keys to scale up/down).
For #3 there could also be a message for the window manager to request scaling for a window so that, e.g. something like xdotool could provide such requests via the command like.
> It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
Then i suggest making better effort towards understanding what others write or at least ask clarifications (like i did at my first response in this comment) because making the assumption that it doesn't move a discussion forward.
>You'll need to explain why and how it is "flawed and inferior"
Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of X11 and it will break when someone wants to disable compositing or use another old window manager. As for the other parts, those would technically work, and it already does work like that for the most part. Most programs that can do DPI scaling do already have a way to scale themselves. But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
>Then i suggest making better effort towards understanding what others write or at least ask clarifications
There are no clarifications to ask, you are repeating the same comments that get posted all the time. Keep in mind these are the type of comments that you can see repeated very often:
"I have no problem, it works on my hardware"
"It is not a problem because I personally prefer it this way"
"Just try to fix the problem yourself by tweaking these developer settings (config files, environment variables, etc) and hoping it works"
If your comment follows this pattern then I would say just avoid making that comment, it is not moving the discussion forward. I think you can agree, when building these systems the goal is to get something that is usable out of the box for everyone. So these comments do not "move the needle" towards that, these are just reinforcing the current status quo.
Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of X11 and it will break when someone wants to disable compositing or use another old window manager. As for the other parts, those would technically work, and it already does work like that for the most part. Most programs that can do DPI scaling do already have a way to scale themselves. But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
>Then i suggest making better effort towards understanding what others write or at least ask clarifications
There are no clarifications to ask, you are repeating the same comments that get posted all the time. Keep in mind these are the type of comments that you can see repeated very often:
"I have no problem, it works on my hardware"
"It is not a problem because I personally prefer it this way"
"Just try to fix the problem yourself by tweaking these developer settings (config files, environment variables, etc) and hoping it works"
If your comment follows this pattern then I would say just avoid making that comment, it is not moving the discussion forward. I think you can agree, when building these systems the goal is to get something that is usable out of the box for everyone. So these comments do not "move the needle" towards that, these are just reinforcing the current status quo.
> Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of X11 and it will break when someone wants to disable compositing or use another old window manager.
But it also does not rely on Wayland and all the flaws it has - after all my point was about being possible on X11, not about Wayland. Wayland had nothing to do with the post i wrote.
> But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
Yes, which is exactly what i wrote in my original message: "Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things".
> There are no clarifications to ask, you are repeating the same comments that get posted all the time [...] If your comment follows this pattern then I would say just avoid making that comment
I suggest try to actual read what people are writing instead of trying to pattern match answers to whatever you think the poster is writing. This may also help understand what i write in my other replies about backwards compatibility.
But it also does not rely on Wayland and all the flaws it has - after all my point was about being possible on X11, not about Wayland. Wayland had nothing to do with the post i wrote.
> But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
Yes, which is exactly what i wrote in my original message: "Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things".
> There are no clarifications to ask, you are repeating the same comments that get posted all the time [...] If your comment follows this pattern then I would say just avoid making that comment
I suggest try to actual read what people are writing instead of trying to pattern match answers to whatever you think the poster is writing. This may also help understand what i write in my other replies about backwards compatibility.
>after all my point was about being possible on X11
Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance. WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add, and some X11 users still seem to insist on not using them... Any attempts to add this to X11 are fighting an uphill battle.
>I suggest try to actual read what people are writing
I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance. WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add, and some X11 users still seem to insist on not using them... Any attempts to add this to X11 are fighting an uphill battle.
>I suggest try to actual read what people are writing
I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
> Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance.
Regardless of what you consider "inferior" (again, i do not see anything inferior assuming it is done as i described), the point was that it was possible.
> WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add
Compositing is only needed for applications that do not support scaling themselves. There is no compositing necessary for applications that do support scaling, aside from the (literal) edge case of having an application cross two (or more) different monitors of different scale values and wanting to have the same visible area in all of them.
> and some X11 users still seem to insist on not using them...
At the end of the day it is up to users to decide what they want to do with their computers - and deal with pros and cons of their choices, the best developers can do is try to provide options.
If something isn't possible in whatever "perfect" sense one might have, it can still be worth implemented in "good enough" ways. For example i use Window Maker, a window manager without desktop compositing support (aside from a minor use for window thumbnails) the UX of which i like in general despite its flaws in some cases. If i had multiple monitors with mixed DPI, i'd rather stick with WM even if i had to deal with the "window looks too big/small while dragging it between monitors" flaw since i consider the latter a minor issue while switching to a different environment (and all the consequences it may have) a much bigger one.
> I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
Your responses indicate that your beliefs are wrong then. The comment about backwards compatibility are relevant if you are also trying to do that pattern matching against what i write there.
Regardless of what you consider "inferior" (again, i do not see anything inferior assuming it is done as i described), the point was that it was possible.
> WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add
Compositing is only needed for applications that do not support scaling themselves. There is no compositing necessary for applications that do support scaling, aside from the (literal) edge case of having an application cross two (or more) different monitors of different scale values and wanting to have the same visible area in all of them.
> and some X11 users still seem to insist on not using them...
At the end of the day it is up to users to decide what they want to do with their computers - and deal with pros and cons of their choices, the best developers can do is try to provide options.
If something isn't possible in whatever "perfect" sense one might have, it can still be worth implemented in "good enough" ways. For example i use Window Maker, a window manager without desktop compositing support (aside from a minor use for window thumbnails) the UX of which i like in general despite its flaws in some cases. If i had multiple monitors with mixed DPI, i'd rather stick with WM even if i had to deal with the "window looks too big/small while dragging it between monitors" flaw since i consider the latter a minor issue while switching to a different environment (and all the consequences it may have) a much bigger one.
> I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
Your responses indicate that your beliefs are wrong then. The comment about backwards compatibility are relevant if you are also trying to do that pattern matching against what i write there.
>At the end of the day it is up to users to decide what they want to do with their computers - and deal with pros and cons of their choices
The issue with this thinking is that those cons eventually cascade back to the developer, if you know for a fact users will use an option that is going to break the intended use case. Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method. Old legacy applications with no scaling support will still need support from the window manager. So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
>Your responses indicate that your beliefs are wrong then
I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
The issue with this thinking is that those cons eventually cascade back to the developer, if you know for a fact users will use an option that is going to break the intended use case. Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method. Old legacy applications with no scaling support will still need support from the window manager. So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
>Your responses indicate that your beliefs are wrong then
I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
> The issue with this thinking is that those pros and cons eventually cascade back to the developer, if you know for a fact users will use an option that is going to break the intended use case.
Thinking "for a fact" that users will do something is a perfect way to make several of them unhappy when they want to do something else :-P.
> Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method.
Maybe, but as i wrote, the alternative is either not using Window Maker or not having any scaling support, both of which would be way more undesirable for me.
> Old legacy applications with no scaling support will still need support from the window manager.
Sure, like any application with no scaling support in any platform that provides it, will need to support them somehow - this isn't limited to X11.
> So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
As far as i am concerned, the solution i describe is both superior and works perfectly fine when the alternative is introducing worse issues.
And this is the important bit: what i consider better and superior and what you consider better and superior are not the same thing, hence being able to have the option to set up things in the way each one likes (which of course relies on underlying systems that are modular enough to allow that).
> I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
I brought up Window Maker as an example that i have personal experience with, it could have also been IceWM or any other window manager without support for desktop composition.
Also FWIW my original reply in this thread wasn't about GNOME specifically either, it was a reply on some issues the original poster had with the Linux desktop environment in general (itself a post not specifically about GNOME too).
Thinking "for a fact" that users will do something is a perfect way to make several of them unhappy when they want to do something else :-P.
> Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method.
Maybe, but as i wrote, the alternative is either not using Window Maker or not having any scaling support, both of which would be way more undesirable for me.
> Old legacy applications with no scaling support will still need support from the window manager.
Sure, like any application with no scaling support in any platform that provides it, will need to support them somehow - this isn't limited to X11.
> So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
As far as i am concerned, the solution i describe is both superior and works perfectly fine when the alternative is introducing worse issues.
And this is the important bit: what i consider better and superior and what you consider better and superior are not the same thing, hence being able to have the option to set up things in the way each one likes (which of course relies on underlying systems that are modular enough to allow that).
> I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
I brought up Window Maker as an example that i have personal experience with, it could have also been IceWM or any other window manager without support for desktop composition.
Also FWIW my original reply in this thread wasn't about GNOME specifically either, it was a reply on some issues the original poster had with the Linux desktop environment in general (itself a post not specifically about GNOME too).
> Lack of tearing where? Depending on where you mean it, this can be a feature instead of a problem
Depends on the user; I dislike tearing everywhere, including games (distracting when focus is important and hard to notice details when moving). I have never been able to get rid of tearing on Xorg without unacceptable side effects (very uneven framerate, with microfreezes of a few frames when playing with options). This prevented me from using Linux-based desktops as main OS for a long time. (although I could have bought another GPU)
On the latest Fedora with Wayland and up-to-date nvidia drivers, the experience is completely tear-free and I am back to Linux as default boot OS. (still missing VR).
Depends on the user; I dislike tearing everywhere, including games (distracting when focus is important and hard to notice details when moving). I have never been able to get rid of tearing on Xorg without unacceptable side effects (very uneven framerate, with microfreezes of a few frames when playing with options). This prevented me from using Linux-based desktops as main OS for a long time. (although I could have bought another GPU)
On the latest Fedora with Wayland and up-to-date nvidia drivers, the experience is completely tear-free and I am back to Linux as default boot OS. (still missing VR).
> Depends on the user; I dislike tearing everywhere, including games (distracting when focus is important and hard to notice details when moving).
Yes, that was my point that not everyone has the same requirements. This is why i gave my usecase as an example - and of course with details to help others who might be in the same position as me but don't know where to look to help themselves.
> I have never been able to get rid of tearing on Xorg without unacceptable side effects (very uneven framerate, with microfreezes of a few frames when playing with options). This prevented me from using Linux-based desktops as main OS for a long time. (although I could have bought another GPU) [..] up-to-date nvidia drivers, the experience is completely tear-free and I am back to Linux as default boot OS.
At least on my AMD Radeon RX 5700 XT and the open source drivers, i do not have issues. With VRR i even had silky smooth animations (though right now i am using a 60Hz monitor without VRR).
TBH since i was always in the "no-vsync camp", even when i had an Nvidia GPU i always had it disabled in as many places i knew where it can be disabled :-P but IIRC there is an environment variable that is equivalent to vblank_mode (or even that :-P it has been years since i had an Nvidia GPU).
There is nothing really special or weird about Xorg here, vsync isn't rocket science. As long as the application (and desktop compositor, if you use one) uses the proper APIs it should work fine. Assuming there isn't anything broken on the Nvidia side, of course.
Yes, that was my point that not everyone has the same requirements. This is why i gave my usecase as an example - and of course with details to help others who might be in the same position as me but don't know where to look to help themselves.
> I have never been able to get rid of tearing on Xorg without unacceptable side effects (very uneven framerate, with microfreezes of a few frames when playing with options). This prevented me from using Linux-based desktops as main OS for a long time. (although I could have bought another GPU) [..] up-to-date nvidia drivers, the experience is completely tear-free and I am back to Linux as default boot OS.
At least on my AMD Radeon RX 5700 XT and the open source drivers, i do not have issues. With VRR i even had silky smooth animations (though right now i am using a 60Hz monitor without VRR).
TBH since i was always in the "no-vsync camp", even when i had an Nvidia GPU i always had it disabled in as many places i knew where it can be disabled :-P but IIRC there is an environment variable that is equivalent to vblank_mode (or even that :-P it has been years since i had an Nvidia GPU).
There is nothing really special or weird about Xorg here, vsync isn't rocket science. As long as the application (and desktop compositor, if you use one) uses the proper APIs it should work fine. Assuming there isn't anything broken on the Nvidia side, of course.
I missed Gnome 2, too, 10 years ago. Then... 10 years passed, and I've just gotten used to the new UI. It's not like you can't customise it to some extent, and you still have the choice of using any alternative DM that you wish.
IMHO, Gnome just works. There are other parts of the Linux ecosystem that still suck (audio...), but GNOME is IMHO not among them.
IMHO, Gnome just works. There are other parts of the Linux ecosystem that still suck (audio...), but GNOME is IMHO not among them.
Pipewire seems to be the solution for audio... probably. I still have issues with different users that run at the same time not being able to use the same output (i.e. having two Xorg instances in different virtual terminals output to my USB headset at the same time) which is a stupid problem to have, but TBH i'm not sure if it is a PulseAudio issue or a Pipewire issue.
It is most likely fixable, but it hasn't bothered me enough to try and figure it out.
It is most likely fixable, but it hasn't bothered me enough to try and figure it out.
But I don't care about Pipewire. Or Pulseaudio. Or ALSA. Or the 500 different interfaces that these tools have. I want to have an audio setup that just works without me having to know anything about it, and how these different subsystems interact etc.
I honestly miss all the 3D effects I had running on Gnome 2. It made my desktop fun to use. Modern replacements for the wobbly windows aren’t getting anywhere close to what I was used to.
KDE has most of those features, especially with wayfire.
Normally these pages are filled with people who prefer old gnome. I thought I'd weigh in and say I prefer gnome 3 by a significant margin.
* I don't use border click targets to resize, I hold alt + click to resize / move windows.
* I use "expose" like functionality to switch windows or alt tab.
* Nautalis isn't great, but I don't spend much time in there anyway.
* I prefer the gnome 3 launcher (Windows key + start typing), than the menu system
I barely see gnome, it lets the applications take centre stage, and I spend all my time in them anyway.
* I don't use border click targets to resize, I hold alt + click to resize / move windows.
* I use "expose" like functionality to switch windows or alt tab.
* Nautalis isn't great, but I don't spend much time in there anyway.
* I prefer the gnome 3 launcher (Windows key + start typing), than the menu system
I barely see gnome, it lets the applications take centre stage, and I spend all my time in them anyway.
GNOME is very keyboard centric and it is a joy to use :)
Nautilus improved a lot the past years. There was a big backslash due to the removal of find-as-you-type but the new search instantly works as type-ahead-find inside the current directory or recursive. Special thanks to Carlos Soriano!
I also thank Red Hat (Debarshi Ray and David King) for the transparency feature of gnome-terminal. I maintain myself a package for Arch with the required patches because I want it.
Nautilus improved a lot the past years. There was a big backslash due to the removal of find-as-you-type but the new search instantly works as type-ahead-find inside the current directory or recursive. Special thanks to Carlos Soriano!
I also thank Red Hat (Debarshi Ray and David King) for the transparency feature of gnome-terminal. I maintain myself a package for Arch with the required patches because I want it.
Sorry, did you just say you liked gnome 3 yet told us that the file manager isn't great?
I use mod + left/right to move my windows on Mate. Alt tab still works fine. Mod + r shows the run box which shows all the same entries as the menu. I used gnome 2 for many many years but also kde 3.5 (Konqueror did everything!) so the modern gnome 3 experience seem dysfunctional to me. I even used gnome 1 - must have been on RedHat 6.2?
One thing I can't stand on the modern gnome apps is the hamburger menu and popout menus that are impossible to spawn from the keyboard. Eg. alt-f won't bring up that menu so you have to fumble around with the mouse.
But thank goodness gnome exists, whether in gnome2-forever guise or the "modern" (I would say less-useful) 3.
I use mod + left/right to move my windows on Mate. Alt tab still works fine. Mod + r shows the run box which shows all the same entries as the menu. I used gnome 2 for many many years but also kde 3.5 (Konqueror did everything!) so the modern gnome 3 experience seem dysfunctional to me. I even used gnome 1 - must have been on RedHat 6.2?
One thing I can't stand on the modern gnome apps is the hamburger menu and popout menus that are impossible to spawn from the keyboard. Eg. alt-f won't bring up that menu so you have to fumble around with the mouse.
But thank goodness gnome exists, whether in gnome2-forever guise or the "modern" (I would say less-useful) 3.
[deleted]
> I barely see gnome
This is key for me. A good OS (in this case DE) gets out of the way. With none-to-little effort, recent Gnome does this well, and it's not something that Win/Mac are keen on.
This is key for me. A good OS (in this case DE) gets out of the way. With none-to-little effort, recent Gnome does this well, and it's not something that Win/Mac are keen on.
Seconded... I was on kde for years and while productive, I couldn't just get the feeling that it got out of the way
Decided to give gnome a try a couple of months ago in a VM and liked it enough that now I have an older version of GNOME on kde neon
With a few shell extensions, GNOME fits my workflow and just gets out of the way that I don't even notice it .... And, to me, is the highest praise that any software can get.
Decided to give gnome a try a couple of months ago in a VM and liked it enough that now I have an older version of GNOME on kde neon
With a few shell extensions, GNOME fits my workflow and just gets out of the way that I don't even notice it .... And, to me, is the highest praise that any software can get.
>>I barely see gnome
see this is my problem with gnome3, it absolutely insists on being seen: the launcher takes over the entire screen, so does the "expose", switching workspaces with the mouse? whole screen. Even the alt-tab pop-up is comparatively enormous.
see this is my problem with gnome3, it absolutely insists on being seen: the launcher takes over the entire screen, so does the "expose", switching workspaces with the mouse? whole screen. Even the alt-tab pop-up is comparatively enormous.
Yes, I use GNOME 3 and feel similarly. It just gets out of my way and lets me work.
I also have a lot of appreciation for GNOME driving Wayland adoption. I know it's been a bumpy road, but desktop Linux is much better for it, and things are better now than they ever were in the past.
Unlike many long time Linux users who post here, I really do not look back fondly on the days of twm or fluxbox or something. GNOME has all the little QOL features that help me when I need them, without getting in the way during daily operation.
I also have a lot of appreciation for GNOME driving Wayland adoption. I know it's been a bumpy road, but desktop Linux is much better for it, and things are better now than they ever were in the past.
Unlike many long time Linux users who post here, I really do not look back fondly on the days of twm or fluxbox or something. GNOME has all the little QOL features that help me when I need them, without getting in the way during daily operation.
Happy Birthday, MATE . (<https://mate-desktop.org>)
What is called "GNOME" today is something else.
What is called "GNOME" today is something else.
>Happy Birthday, MATE
Too bad that GTK is more or less controlled by the GNOME people which means that useful features are getting deprecated left and right. For this reason I sadly had to leave MATE and everything else GTK related behind since you never know how much will be deprecated in the next big GTK release. I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else. GNOME2 (and also GNOME 1.4) was good as is for me. I never needed more and don't want my user interface to change at all. It would be perfect if one could just compile GNOME 1.4 or GNOME 2.x without having to worry about some changes in a dependency of the DE making it unusable.
Too bad that GTK is more or less controlled by the GNOME people which means that useful features are getting deprecated left and right. For this reason I sadly had to leave MATE and everything else GTK related behind since you never know how much will be deprecated in the next big GTK release. I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else. GNOME2 (and also GNOME 1.4) was good as is for me. I never needed more and don't want my user interface to change at all. It would be perfect if one could just compile GNOME 1.4 or GNOME 2.x without having to worry about some changes in a dependency of the DE making it unusable.
> I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else.
That is not a good idea because new computers and hardware have new features that you'd want to use from your existing programs. For example you'd certainly want touch support for the laptops that have it, scaling support for high DPI screens, hardware acceleration support for having fast and smooth graphics on slower machines that still have hardware accelerated graphics (e.g. Raspberry Pi), etc.
The thing isn't to only get bug fixes and nothing else, but to get bug fixes and new features - but done in a completely backwards compatible way (even if that means new features have to be done by explicitly opting in to them).
This is harder and not as interesting as rewriting things from scratch though.
That is not a good idea because new computers and hardware have new features that you'd want to use from your existing programs. For example you'd certainly want touch support for the laptops that have it, scaling support for high DPI screens, hardware acceleration support for having fast and smooth graphics on slower machines that still have hardware accelerated graphics (e.g. Raspberry Pi), etc.
The thing isn't to only get bug fixes and nothing else, but to get bug fixes and new features - but done in a completely backwards compatible way (even if that means new features have to be done by explicitly opting in to them).
This is harder and not as interesting as rewriting things from scratch though.
GTK was not rewritten from scratch. Each major release has been an incremental improvement.
Gtk in its entirety was never written from scratch but Gtk is big and individual components and parts of it have been written from scratch and has broken backwards compatibility in major ways, requiring from applications and libraries that depend on it to waste time keeping up with those changes (see XFCE or even GIMP as examples that took literally years to update to a new major version, only for Gtk developers to break their APIs again).
It reminds me of that old "Fire and Motion" article by Joel[0], especially these last bits:
> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? [..] The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. [..] People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby.
Except of course, unlike Microsoft, GNOME and Gtk have nothing to gain by shooting the developers that depend on their APIs :-P
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
It reminds me of that old "Fire and Motion" article by Joel[0], especially these last bits:
> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? [..] The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. [..] People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby.
Except of course, unlike Microsoft, GNOME and Gtk have nothing to gain by shooting the developers that depend on their APIs :-P
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
If they are getting something out it then it is not a waste of time. Those applications are free to stay on GTK1 or GTK2 or whatever they want. Those APIs were never broken. But I bet even you would admit that is a horrible idea because those toolkits are woefully outdated.
As i wrote in the other comment you replied (copy pasting here again since you basically repeated the exact same comment) it was a waste of time because new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
> But I bet even you would admit that is a horrible idea because those toolkits are woefully outdated.
The only reason these are seen as "woefully outdated" is because Gtk2 was incompatible with Gtk1, Gtk3 incompatible with Gtk2 and Gtk4 incompatible with Gtk3. If, however, they were backwards compatible then there wouldn't even be possible for a situation where remaining with a "woefully outdated" version to be a consideration - people would just upgrade to whatever is the latest version and things would keep working.
Again, Gtk breaking itself with major versions isn't due forces of nature, so you don't have to act as if that would be the only possibility.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
> But I bet even you would admit that is a horrible idea because those toolkits are woefully outdated.
The only reason these are seen as "woefully outdated" is because Gtk2 was incompatible with Gtk1, Gtk3 incompatible with Gtk2 and Gtk4 incompatible with Gtk3. If, however, they were backwards compatible then there wouldn't even be possible for a situation where remaining with a "woefully outdated" version to be a consideration - people would just upgrade to whatever is the latest version and things would keep working.
Again, Gtk breaking itself with major versions isn't due forces of nature, so you don't have to act as if that would be the only possibility.
>new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries.
This is incorrect, things like the DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits. It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes. The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment. The rest of the comment stems from this incorrect assumption so I have not much else to say.
This is incorrect, things like the DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits. It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes. The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment. The rest of the comment stems from this incorrect assumption so I have not much else to say.
> This is incorrect, things like the DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits.
Then, assuming these specific features cannot be added in a backwards compatible way for existing applications (i have my doubts for DPI scaling since, e.g. Lazarus / LCL did exactly that, though in source code compatibility form only but that is due to a language limitation around shared libraries), they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features.
> It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes.
Nobody ever mentioned that, what i refer to is not breaking existing applications, libraries and -of course- code that works, not to design APIs that are perfect from the get go.
> The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment.
If there is actual interest in not breaking backwards compatibility, these features and any other features, could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
If i have, e.g., a program that has an input field with two buttons, one that shows a file picker dialog to fill the field with the path to the selected file and another that performs some (non-GUI) operation on the picked file, then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
Then, assuming these specific features cannot be added in a backwards compatible way for existing applications (i have my doubts for DPI scaling since, e.g. Lazarus / LCL did exactly that, though in source code compatibility form only but that is due to a language limitation around shared libraries), they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features.
> It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes.
Nobody ever mentioned that, what i refer to is not breaking existing applications, libraries and -of course- code that works, not to design APIs that are perfect from the get go.
> The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment.
If there is actual interest in not breaking backwards compatibility, these features and any other features, could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
If i have, e.g., a program that has an input field with two buttons, one that shows a file picker dialog to fill the field with the path to the selected file and another that performs some (non-GUI) operation on the picked file, then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
>they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features.
This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.
>could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
This is simply not possible. Many older APIs are just not designed to support this.
>then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
Indeed, such a program would probably be trivial to port.
>With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
If you want binary compatibility, that is a different story. It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4. But only the most trivial ones like a form with a couple of buttons. Anything with custom widgets (which is all non-trivial applications) would probably break or would lose most/all of the benefits, the GTK1 API simply was not designed in that way.
This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.
>could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
This is simply not possible. Many older APIs are just not designed to support this.
>then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
Indeed, such a program would probably be trivial to port.
>With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
If you want binary compatibility, that is a different story. It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4. But only the most trivial ones like a form with a couple of buttons. Anything with custom widgets (which is all non-trivial applications) would probably break or would lose most/all of the benefits, the GTK1 API simply was not designed in that way.
> This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.
Sorry but this shows you refuse to understand what i write in my responses.
> This is simply not possible. Many older APIs are just not designed to support this.
Then make new APIs alongside the old APIs.
> Indeed, such a program would probably be trivial to port.
And my point is that it shouldn't need to be ported.
> If you want binary compatibility, that is a different story.
It is not a different story, it is part of the entire backwards compatibility story. I refer to not only binary compatibility but also source compatibility. What i refer to is being able to:
1. Run old binaries in new systems while receiving any new functionality that may apply
2. Compile old programs against the latest version of the library without issues (at least not issues due to the library) and get pretty much the same functionality you'd get if you ran the old binary against the latest version of the library
3. Being able to upgrade the program, in parts or in whole (where that'd make sense - a new approach might be "better" in some ways but not be worth the effort for a particular program so using the old approach should still work)
> It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4.
Such a compatibility is only needed because Gtk4 itself isn't backwards compatible with Gtk1.
Sorry but this shows you refuse to understand what i write in my responses.
> This is simply not possible. Many older APIs are just not designed to support this.
Then make new APIs alongside the old APIs.
> Indeed, such a program would probably be trivial to port.
And my point is that it shouldn't need to be ported.
> If you want binary compatibility, that is a different story.
It is not a different story, it is part of the entire backwards compatibility story. I refer to not only binary compatibility but also source compatibility. What i refer to is being able to:
1. Run old binaries in new systems while receiving any new functionality that may apply
2. Compile old programs against the latest version of the library without issues (at least not issues due to the library) and get pretty much the same functionality you'd get if you ran the old binary against the latest version of the library
3. Being able to upgrade the program, in parts or in whole (where that'd make sense - a new approach might be "better" in some ways but not be worth the effort for a particular program so using the old approach should still work)
> It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4.
Such a compatibility is only needed because Gtk4 itself isn't backwards compatible with Gtk1.
I understand exactly what you are saying but it does not make sense. Think of this on the most basic level like with DPI scaling. If an application has no idea of DPI scaling and has a certain DPI hard coded in (like many GTK1 applications do) then you cannot do anything about that with any "backwards compatibility". The application will just not work with DPI scaling until it is ported to work with a variable scale instead of a hard coded DPI. You cannot upgrade the program in parts either, or add a new API alongside it. The whole thing must be changed to support DPI scaling or some of it will be in the incorrect scale and the effects will cascade to other widgets that expect the scale to be passed to them from the parent widget. Because remember everything in a GTK program is in a widget tree that depends on passing down state.
Part of the reason that the themes changed and the CSS implementation got changes was because of these issues, i.e. pretty much all GTK1 and GTK2 applications and themes had no concept of device-independence, most drawing was done hard coding a DPI against raw device pixels. The few applications that implement it themselves would not benefit from any backwards compatibility layer.
You can also apply the same logic to many of the other changes in GTK. Your suggestions just cannot be done by swapping out the library, they are either impossible or are even more impractical than the current situation. If it were as easy as you seem to think it is then the GTK developers would have done it by now.
Part of the reason that the themes changed and the CSS implementation got changes was because of these issues, i.e. pretty much all GTK1 and GTK2 applications and themes had no concept of device-independence, most drawing was done hard coding a DPI against raw device pixels. The few applications that implement it themselves would not benefit from any backwards compatibility layer.
You can also apply the same logic to many of the other changes in GTK. Your suggestions just cannot be done by swapping out the library, they are either impossible or are even more impractical than the current situation. If it were as easy as you seem to think it is then the GTK developers would have done it by now.
>I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else.
This is how it already is for MATE as long as they intend to keep it that way. It uses GTK3, which is currently in maintenance mode, and will only receive bug-fixes and nothing else.
This is how it already is for MATE as long as they intend to keep it that way. It uses GTK3, which is currently in maintenance mode, and will only receive bug-fixes and nothing else.
It also means it wont receive any new features though and if the MATE developers want those features they'd have to waste time upgrading their -non-trivial- codebase from Gtk3 to Gtk4, just like they had to waste time (which took years, IIRC) to to upgrade the GNOME 2 (early MATE) codebase from Gtk2 to Gtk3.
Time that could have been spent improving MATE instead.
Time that could have been spent improving MATE instead.
The parent comment was asking for "bug-fixes and nothing else" so I have no idea why you are talking about new features. If they wanted new features then it was not a waste of time. There are plenty of new features in GTK3 and GTK4, those are the main reason to port.
> The parent comment was asking for "bug-fixes and nothing else" so I have no idea why you are talking about new features.
Because "bug-fixes and nothing else" isn't enough as i described in the comment you replied to right now as well as in a more detailed comment i replied to the parent post.
> If they wanted new features then it was not a waste of time. There are plenty of new features in GTK3 and GTK4, those are the main reason to port.
It was a waste of time because new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
Because "bug-fixes and nothing else" isn't enough as i described in the comment you replied to right now as well as in a more detailed comment i replied to the parent post.
> If they wanted new features then it was not a waste of time. There are plenty of new features in GTK3 and GTK4, those are the main reason to port.
It was a waste of time because new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
>What is called "GNOME" today is something else.
This is like telling somebody who's been into math for the past ten years and then decided to dive deep into arts they are now a different person.
You may not like the change, but Gnome is still Gnome.
This is like telling somebody who's been into math for the past ten years and then decided to dive deep into arts they are now a different person.
You may not like the change, but Gnome is still Gnome.
I guess that depends on if you see Gnome as an organization or as a desktop environment. The organization is 25 years old, but I'd argue that the desktop environment is not. Gnome 3 was a big enough change that I think it's reasonable to consider it an entirely new desktop environment.
I'm talking about (r)evolution of a software. I find it strange that people agree that windows 10 is still windows just like windows 3.11 but Gnome 42 is somehow 'not Gnome' anymore.
Anyway, I don't there is any point to argue about it. Depending on interpretation we can say that every human wakes up as an entirely new entity every day too.
Anyway, I don't there is any point to argue about it. Depending on interpretation we can say that every human wakes up as an entirely new entity every day too.
Thanks GNOME for facilitating me meeting XFCE
I moved to XFCE ages ago when Gnome and KDE kept changing things.
XFCE mostly stays the same, which is as it should be. Stop reinventing the wheel!
XFCE mostly stays the same, which is as it should be. Stop reinventing the wheel!
Same here, even with my C rants, that is exactly my desktop environment on the surviving netbook that still runs Linux.
Kudos to XFCE devs.
Kudos to XFCE devs.
In 2001 I got an article published on The C/C++ User's Journal as introduction to GNOME development with Gtkmm.
In those days I still believed that GNU/Linux would eventually gather around one main desktop solution.
Nowadays I focus on Apple, Google and Microsoft platforms, while GNOME does yet another reboot with Gtk4, leaving behind Glade, extensions and whatever else.
That C++ code for the article has nothing to do with "modern" Gtk.
In those days I still believed that GNU/Linux would eventually gather around one main desktop solution.
Nowadays I focus on Apple, Google and Microsoft platforms, while GNOME does yet another reboot with Gtk4, leaving behind Glade, extensions and whatever else.
That C++ code for the article has nothing to do with "modern" Gtk.
Likewise. Very sad to see it all start with such promise, and then end up where it is today. If I read your username right, you also helped me get a tutorial published in CVu on GTK+ development around 2005 (which lives on at https://gitlab.com/codelibre/ogcalc). I ceased to maintain it when GTK+ stopped being usable for professional application development (not that, in retrospect, it was ever that great in the first place).
I invested a significant amount of time and effort developing C and C++ applications with GTK+ and Gtkmm. The consideration given to application developers when making repeated incompatible changes, along with a seemingly endless stream of bugs in both, forced me to move to Qt, and I've been using that exclusively for GUI work since the Qt5 timeframe. There's no upgrade path for older Glade project files. Basic widgets have been deprecated and removed. A fairly trivial maintenance cost has instead been imposed upon the entire developer base, in most cases for little or no tangible benefit.
In 2022, where are the "network objects"? GNOME started with a fairly revolutionary and interesting premise of interconnected services using CORBA. CORBA of course died a slow death, but there are modern replacements (not dbus), which could be used to great effect. Over the last 15 years, GNOME seems to have been primarily driven by appearance and usability (by their definition), but the technical underpinnings of the whole thing are fairly shallow and limited compared with what might have been.
I invested a significant amount of time and effort developing C and C++ applications with GTK+ and Gtkmm. The consideration given to application developers when making repeated incompatible changes, along with a seemingly endless stream of bugs in both, forced me to move to Qt, and I've been using that exclusively for GUI work since the Qt5 timeframe. There's no upgrade path for older Glade project files. Basic widgets have been deprecated and removed. A fairly trivial maintenance cost has instead been imposed upon the entire developer base, in most cases for little or no tangible benefit.
In 2022, where are the "network objects"? GNOME started with a fairly revolutionary and interesting premise of interconnected services using CORBA. CORBA of course died a slow death, but there are modern replacements (not dbus), which could be used to great effect. Over the last 15 years, GNOME seems to have been primarily driven by appearance and usability (by their definition), but the technical underpinnings of the whole thing are fairly shallow and limited compared with what might have been.
>not dbus
In practice D-Bus is functionally similar to many other IDL schemes and can be trivially tunneled over SSH. But yes, it has mostly become used for local applications to communicate with system daemons, and the networked case is not particularly relevant.
The modern replacement for networked objects is to write a web server and communicate using XMLHttpRequest/fetch/websockets, which is outside the scope of a desktop environment.
In practice D-Bus is functionally similar to many other IDL schemes and can be trivially tunneled over SSH. But yes, it has mostly become used for local applications to communicate with system daemons, and the networked case is not particularly relevant.
The modern replacement for networked objects is to write a web server and communicate using XMLHttpRequest/fetch/websockets, which is outside the scope of a desktop environment.
If you feel like it you can probably run that 2001 code in Gtk 1.2 fixed to work in modern Linux[0] :-P.
At least the lower levels of the desktop stack hasn't succumbed (yet) to the backwards compatibility breakage found in the higher levels.
[0] http://runtimeterror.com/pages/badsector/gtk12/
At least the lower levels of the desktop stack hasn't succumbed (yet) to the backwards compatibility breakage found in the higher levels.
[0] http://runtimeterror.com/pages/badsector/gtk12/
The only reasons anything has compatibility breakage is because things have not been back ported, or because no one has built a compatibility layer. GTK1, and most other programs using Xlib, are able to work because XWayland was built as a compatibility layer. If there are other areas where things have broken, then I suggest you try to build additional compatibility layers.
As i already wrote twice in other replies, Gtk breaking backwards compatibility is not due to a force of nature, but due to the Gtk developers deciding to break it.
The backwards compatibility i refer here is having libraries, binaries and code work with the very latest version of Gtk (not Gtk1, Gtk2, Gtk3 or Gtk4, but *Gtk*, no numbers or anything) always work, just like a Win32 binary made in Windows 95 using the Win32 API can work in Windows 11 and even get new functionality introduced in the same APIs since then or just like an ELF binary compiled in a 1997 Linux i386 distribution can work on a modern x86_64 Linux distribution (assuming no dependencies to broken userland libraries, of course) and use new functionality introduced to the same APIs in kernel since then.
The backwards compatibility i refer here is having libraries, binaries and code work with the very latest version of Gtk (not Gtk1, Gtk2, Gtk3 or Gtk4, but *Gtk*, no numbers or anything) always work, just like a Win32 binary made in Windows 95 using the Win32 API can work in Windows 11 and even get new functionality introduced in the same APIs since then or just like an ELF binary compiled in a 1997 Linux i386 distribution can work on a modern x86_64 Linux distribution (assuming no dependencies to broken userland libraries, of course) and use new functionality introduced to the same APIs in kernel since then.
Not all features of Windows 11 can be bolted on to legacy Win32 APIs. Some features can but others cannot. GTK is not different in this regard. Some features have stayed the same but others have changed and require porting.
If the suggestion is that GTK should somehow get the same budget that Microsoft has to put towards backwards compatibility, you know very well this is not possible. It would probably not even be wanted, GTK is a lot less popular than Windows.
If the suggestion is that GTK should somehow get the same budget that Microsoft has to put towards backwards compatibility, you know very well this is not possible. It would probably not even be wanted, GTK is a lot less popular than Windows.
Win32 programs from 2000 work on the latest Win32 and get new functionality that is exposed through the APIs they used at the time, where that applies.
Gtk programs from 2000 do not work on the latest Gtk, regardless of if the functionality they used from the APIs they relied on would be found in the latest Gtk. Instead they have to be "ported" to the new Gtk, assuming the source code is available, the developers are available and someone is willing to waste effort and time to do the porting.
Gtk programs from 2000 do not work on the latest Gtk, regardless of if the functionality they used from the APIs they relied on would be found in the latest Gtk. Instead they have to be "ported" to the new Gtk, assuming the source code is available, the developers are available and someone is willing to waste effort and time to do the porting.
This is a nonsensical comparison though. New versions of GTK are actually new APIs. So what you are saying is more like "WPF programs do not work if you delete WPF and try to compile it against only the Win32 API" which is also correct. GTK1 programs will continue to work on GTK1, it has not changed.
> This is a nonsensical comparison though. New versions of GTK are actually new APIs.
Which has been my entire criticism! Gtk major versions being "new APIs" is what breaks backwards compatibility and causes existing applications, libraries to waste time keeping up.
It actually worse than Win32 vs WPF because the latter is something you can ignore as Win32 is still receiving improvements with bug fixes and new functionality, but Gtk development for any previous major version eventually stops all development. Not only that but even with new APIs, under Windows there is always some official way to use the previous APIs together with the new (e.g. mix Win32 with WPF) but there isn't anything like that for GtkN-1-with-GtkN (and even if there was it'd be pointless in long term as GtkN-1 would eventually stop working, unlike Win32).
Which has been my entire criticism! Gtk major versions being "new APIs" is what breaks backwards compatibility and causes existing applications, libraries to waste time keeping up.
It actually worse than Win32 vs WPF because the latter is something you can ignore as Win32 is still receiving improvements with bug fixes and new functionality, but Gtk development for any previous major version eventually stops all development. Not only that but even with new APIs, under Windows there is always some official way to use the previous APIs together with the new (e.g. mix Win32 with WPF) but there isn't anything like that for GtkN-1-with-GtkN (and even if there was it'd be pointless in long term as GtkN-1 would eventually stop working, unlike Win32).
>but Gtk development for any previous major version eventually stops all development.
Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. The whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.
Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. The whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.
No, my actual criticism is that backwards compatibility was broken, not that previous versions stopped development - such a concern about stopping development only exists because the newer versions were not backwards compatible.
That does not follow. WPF is also not backwards compatible and you have no issue with that, because Win32 is still being maintained so that makes you feel you can ignore WPF. Am I wrong here?
I have issues with WPF too since i think Microsoft should have focused on improving Win32 instead of wasting their resources (and, most importantly, the time of everyone who felt at the time they had to keep up - see the Joel article i linked elsewhere), but bringing up WPF doesn't serve anything aside from muddling the discussion.
The only areas where i see WPF doing better is that at least it allows merging Win32 and WPF code, so an application can improve partially if they see WPF as a valid path forward - and it doesn't present itself as Win32 v2 so that Win32 development can continue independently (remember that i wrote that WPF is something you can at least ignore). None of these are the case with Gtk though.
But again, mentioning WPF here serves no purpose, what i wrote so far should be clear enough by itself.
The only areas where i see WPF doing better is that at least it allows merging Win32 and WPF code, so an application can improve partially if they see WPF as a valid path forward - and it doesn't present itself as Win32 v2 so that Win32 development can continue independently (remember that i wrote that WPF is something you can at least ignore). None of these are the case with Gtk though.
But again, mentioning WPF here serves no purpose, what i wrote so far should be clear enough by itself.
There's a new Glade-like for gtk4!
https://gitlab.gnome.org/jpu/cambalache
I haven't read anything about them leaving behind extensions yet, do you have any more info?
I haven't read anything about them leaving behind extensions yet, do you have any more info?
Yes, it uses Web rendering for what is supposed to be a native toolkit and is years behind to be feature complete, not worth waiting for.
What's with the modern obsession of using web rendering for everything? It's actually insane.
I really don't get it, when I do native I want native tooling, when I do Web, I expect no more than whatever the user has installed as their main browser.
I was never found of MSHTML and Active Desktop, nor of its FOSS clones.
See the readme on the repo, they basically use Gtk rendering into browsers.
I was never found of MSHTML and Active Desktop, nor of its FOSS clones.
See the readme on the repo, they basically use Gtk rendering into browsers.
From what I understand they're basically doing this as an abstraction layer so as to support both Gtk3 and 4? I'm still not sure why it needs to involve a browser though..
It is using a webkit view because currently it is the easiest way to display content from an external process in a cross-platform way. It does not have to be that way though: https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalache...
>Ideally I would use an embedded Wayland compositor widget instead of a webview and broadway, but unfortunately there is only an old non working prototype called Wakefield and finishing it is a project on its own. In any case replacing the webview with a wayland compositor widget would be trivial.
>Ideally I would use an embedded Wayland compositor widget instead of a webview and broadway, but unfortunately there is only an old non working prototype called Wakefield and finishing it is a project on its own. In any case replacing the webview with a wayland compositor widget would be trivial.
I've always liked how Linux offers a desktop that is geared towards macOS (GNOME) and Windows (KDE) users. And the feel of each desktop hasn't adhered to a design standard (e.g., the Apple Human Interface Guidelines), but instead has evolved continually over the years to reflect what those who use the software (as with all open source software that is developed by those who use it).
As a UNIX/macOS person, I primarily use GNOME. And in recent years I've come to prefer using it for development over macOS and Windows. So to the GNOME project: Congrats on 25, and here's to another 25!
As a UNIX/macOS person, I primarily use GNOME. And in recent years I've come to prefer using it for development over macOS and Windows. So to the GNOME project: Congrats on 25, and here's to another 25!
This year, I finally made the jump from Windows to Linux (specifically Fedora) and one thing I was anticipating was poorer, perhaps buggier UI. I was blown away by Gnome 41, it felt more like MacOS (not a reliable source for that, haven't used a mac in about a decade but you get the idea) than the slapped together front-end I was expecting. And the majority of the things I wasn't such a fan of (eg lack of taskbar) was easily fixed with gnome-extensions or tweaks. It barely took me even a month to get more used to it than Windows. And on top of all that, its incredibly performant (was running it on an X220).
Obviously its not perfect (I don't really like the look of the app-menu for example, looks a bit mobile-y), but I've yet to find anything better, not just on Linux but across any OS.
Obviously its not perfect (I don't really like the look of the app-menu for example, looks a bit mobile-y), but I've yet to find anything better, not just on Linux but across any OS.
Not sure about the menu, but using Mate (which is GNOME2+ effectively), by default the menu was a weird menu in the style of Windows 11 where you had to type to find anything.
But you could replace the menu with a different menu button from the applets list to get the traditional menu back / other styles.
I wonder if it's the same for Gnome 4?
But you could replace the menu with a different menu button from the applets list to get the traditional menu back / other styles.
I wonder if it's the same for Gnome 4?
And that was a great user experience:
Note the scrollbars that indicate where you are in your document/file list. No guessing on how many pages (if any!) there are to go.
Note the edges of the windows that can be clicked on with a mouse with confidence. I don't need to be a 16 year old pro E-sports gamer to hit that 1 pixel edge as in current desktop environments.
Note the clear button UI. You know 1: what part of the UI is a button and 2: if a button is active.
Note the cohesive windows and colors. No mess of different UI toolkits, each with their own buttons, menubar layout and color space.
But then I am not the target audience anymore: The desktop power user is a dying breed. 95% ( * ) of the people in the world view "the internet" via a small screen on their phone and have no interest in running multiple programs at once, managing large amounts of data on file systems, or even running their own PC.
(*) random statistic that I made up.
Note the scrollbars that indicate where you are in your document/file list. No guessing on how many pages (if any!) there are to go.
Note the edges of the windows that can be clicked on with a mouse with confidence. I don't need to be a 16 year old pro E-sports gamer to hit that 1 pixel edge as in current desktop environments.
Note the clear button UI. You know 1: what part of the UI is a button and 2: if a button is active.
Note the cohesive windows and colors. No mess of different UI toolkits, each with their own buttons, menubar layout and color space.
But then I am not the target audience anymore: The desktop power user is a dying breed. 95% ( * ) of the people in the world view "the internet" via a small screen on their phone and have no interest in running multiple programs at once, managing large amounts of data on file systems, or even running their own PC.
(*) random statistic that I made up.
The fact that a large userbase has evolved on smartphones does not mean that the desktop userbase is dying. In fact, it's probably increased in size somewhat. And we need to make UI designers understand that what may work and be appropriate for a smartphone or tablet should not be applied to desktops.
Wow so I have been using gnome for 25 years! Here are some screenshots along the way
https://www.pixelbeat.org/pics/ss/
Thanks for sharing these. I became aware of Linux in the gnome 2.x days, so I'd never seen the screenshots of gnome 1. I feel quite fortunate to live in a world where software projects like Gnome exists.
I appreciate the work GNOME authors have put in over the years - but at the same time am highly critical of many of their choices.
My personal favorite desktop environment is Cinnamon:
https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment)
created by the Linux Mint folks as an alternative to GNOME 3. But even there we are stuck with the horrendous Gtk file-picker.
A compile of problematic claims from the post:
> GNOME 3.0 was an exciting new desktop designed for today’s users and which is suited to a range of modern computing devices.
That's quite debatable. Or rather, it seems that the designers decided what "today's users" need, and neglected to verify that was actually the case.
> Flatpak, the next generation application framework for Linux
It is not.
> Flatpak ... provides cross-distribution applications that are more secure than traditional Linux apps
Baseless claim. And it is somewhat "imperialistic" of GNOME to expect people to get binaries directly from them.
My personal favorite desktop environment is Cinnamon:
https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment)
created by the Linux Mint folks as an alternative to GNOME 3. But even there we are stuck with the horrendous Gtk file-picker.
A compile of problematic claims from the post:
> GNOME 3.0 was an exciting new desktop designed for today’s users and which is suited to a range of modern computing devices.
That's quite debatable. Or rather, it seems that the designers decided what "today's users" need, and neglected to verify that was actually the case.
> Flatpak, the next generation application framework for Linux
It is not.
> Flatpak ... provides cross-distribution applications that are more secure than traditional Linux apps
Baseless claim. And it is somewhat "imperialistic" of GNOME to expect people to get binaries directly from them.
"neglected to verify that was actually the case"
This seems very true. They decided that "apps" should abandon all of the useful toolbars because they were too "distracting" which is why gedit ended up being a big white space where you had to poke around in a floating popup menu to work out what you could actually do with it.
By the same logic, reading a page of text is horrendously distracting and we should only be given access to 1 line at a time.
Insanity, it my view, and a terrible regression on decades of UI development.
This seems very true. They decided that "apps" should abandon all of the useful toolbars because they were too "distracting" which is why gedit ended up being a big white space where you had to poke around in a floating popup menu to work out what you could actually do with it.
By the same logic, reading a page of text is horrendously distracting and we should only be given access to 1 line at a time.
Insanity, it my view, and a terrible regression on decades of UI development.
I did use GNOME-3 for 2 years in order to learn the "GNOME-3-way" of managing windows, and I kind of managed to get used to it. But then I've installed KDE and its traditional way of management felt like fresh air, after 2 years of trying to "learn the better way". So I've stopped trying to forcefully "evolve" my workflow management patterns and I've stopped looking at GNOME-3 altogether.
Nevertheless, I'm sending happy birthday from a distant island where I live a more happy life than before ;)
Nevertheless, I'm sending happy birthday from a distant island where I live a more happy life than before ;)
I like Gnome well enough. I keep trying to switch to KDE for the additional settings, many of which are useful, and what I understand to be more innovative core features, but its lack of consistency just feels janky. Gnome provides the most essential features, including a good amount of customization around focus and window switching, and Gnome apps are consistent in appearance and features, such as being able to select text in the UI.
The 'problem' I have is that all these desktops are trying to recreate a 1990s era desktop. At least the Gnome people are professionals focused on a higher goal than a cool anime background, but I think the contingent of people who want a desktop experience with local media player, file manager, office suite and games is decreasing daily.
If they don't want to be subsumed by tablet and ChromeOS options, focusing on goals like being a secure, networked operating system that an ordinary user would appreciate might be a good way forward. I think embracing rather than hiding the technical nature of the OS would be a good way to do this, but nothing like the disaster of forums today. For example, give every widget an ID and version, and create web based conversations around them that are embedded directly in the UI.
The 'problem' I have is that all these desktops are trying to recreate a 1990s era desktop. At least the Gnome people are professionals focused on a higher goal than a cool anime background, but I think the contingent of people who want a desktop experience with local media player, file manager, office suite and games is decreasing daily.
If they don't want to be subsumed by tablet and ChromeOS options, focusing on goals like being a secure, networked operating system that an ordinary user would appreciate might be a good way forward. I think embracing rather than hiding the technical nature of the OS would be a good way to do this, but nothing like the disaster of forums today. For example, give every widget an ID and version, and create web based conversations around them that are embedded directly in the UI.
If you believe that the number of people wanting a file manager and office suite is decreasing, what do you think the desktop environment actually will consist of?
"focusing on goals like being a secure, networked operating system that an ordinary user would appreciate might be a good way forward"
Isn't that precisely what the system is??
"give every widget an ID and version, and create web based conversations around them that are embedded directly in the UI"
What does this even mean? What is a "web based conversation" in terms of the user interface??
"focusing on goals like being a secure, networked operating system that an ordinary user would appreciate might be a good way forward"
Isn't that precisely what the system is??
"give every widget an ID and version, and create web based conversations around them that are embedded directly in the UI"
What does this even mean? What is a "web based conversation" in terms of the user interface??
«If you believe that the number of people wanting a file manager and office suite is decreasing, what do you think the desktop environment actually will consist of?»
Look at ChromeOS and tablets. But, if you want to skip to a decentralized, user innovation and privacy-first future, look at KDE Nepomuk (which was an ambitious decentralized semantic desktop that collapsed), MS Graph (which is a centralized semantic system that probably won't), Plan 9, Nix, Qubes.
«Isn't that precisely what the system is??»
It's not really networked, in fact it's going backwards. X lets you run distrbibuted application on a fine level, as do other decentralized ideas like WS and HATEOAS, but we're reverting to a thin client model where the user is dependant on the browser and ???. But getting to the fine level requires more isolation, data & identify consciousness.
«What does this even mean? What is a "web based conversation" in terms of the user interface??»
Think of an inherently local, yet potentially complex control; a volume control. I can simply use it to control volume, but I might also want to mix volume with networked devices, which spirals into complexity, especially as we get into spatial audio. It's all possible on a Linux desktop, but doing it takes you into open ended complexity, compounded by the fact there are so many versions and combinations of software. A post-90s desktop could add a new control to the context menu which opened a live discussion about that version of that control and combination of desktop options.
Look at ChromeOS and tablets. But, if you want to skip to a decentralized, user innovation and privacy-first future, look at KDE Nepomuk (which was an ambitious decentralized semantic desktop that collapsed), MS Graph (which is a centralized semantic system that probably won't), Plan 9, Nix, Qubes.
«Isn't that precisely what the system is??»
It's not really networked, in fact it's going backwards. X lets you run distrbibuted application on a fine level, as do other decentralized ideas like WS and HATEOAS, but we're reverting to a thin client model where the user is dependant on the browser and ???. But getting to the fine level requires more isolation, data & identify consciousness.
«What does this even mean? What is a "web based conversation" in terms of the user interface??»
Think of an inherently local, yet potentially complex control; a volume control. I can simply use it to control volume, but I might also want to mix volume with networked devices, which spirals into complexity, especially as we get into spatial audio. It's all possible on a Linux desktop, but doing it takes you into open ended complexity, compounded by the fact there are so many versions and combinations of software. A post-90s desktop could add a new control to the context menu which opened a live discussion about that version of that control and combination of desktop options.
You are using lots of words that do not mean a lot to me. It is indistinguishable from marketing-speak.
"decentralized, user innovation and privacy-first future"
Why would you want a decentralized desktop? Are you somehow referring to a syncing of files to a new desktop when you use a different machine? If so, see Windows Profiles, VNC, RDP or NoMachine. If you're somehow referring to something different, I cannot see the use-case for it. The desktop follows the concept of a desk surface in real life. When I go to work elsewhere, I have a new desk but I can put familiar things on it. I don't need the things I put on it to live in the ether above me. "Decentralized" is mubmojumbo - the data has to live somewhere. It can certainly have copies on different machines and perhaps that's what you mean by "decentralized".
My desktop under RedHat 6.2 was "privacy-first". It was even this way on my Windows 3.11 machine...
And I am able to use a volume control fine - I've been able to use one for 40 years without needing it to be "networked". I even manage to pipe audio from my Windows PC to Pulse on a Linux laptop so I can use Presonus Studio One remotely.
It seems you are inventing scenarios that are looking for problems to solve. This seems endemic in the modern software world, in an attempt to "stand out" from the crowd, in my opinion.
I am honestly very confused by your response.
"decentralized, user innovation and privacy-first future"
Why would you want a decentralized desktop? Are you somehow referring to a syncing of files to a new desktop when you use a different machine? If so, see Windows Profiles, VNC, RDP or NoMachine. If you're somehow referring to something different, I cannot see the use-case for it. The desktop follows the concept of a desk surface in real life. When I go to work elsewhere, I have a new desk but I can put familiar things on it. I don't need the things I put on it to live in the ether above me. "Decentralized" is mubmojumbo - the data has to live somewhere. It can certainly have copies on different machines and perhaps that's what you mean by "decentralized".
My desktop under RedHat 6.2 was "privacy-first". It was even this way on my Windows 3.11 machine...
And I am able to use a volume control fine - I've been able to use one for 40 years without needing it to be "networked". I even manage to pipe audio from my Windows PC to Pulse on a Linux laptop so I can use Presonus Studio One remotely.
It seems you are inventing scenarios that are looking for problems to solve. This seems endemic in the modern software world, in an attempt to "stand out" from the crowd, in my opinion.
I am honestly very confused by your response.
I'm glad you got your volume control networked. I kind of gave up on that, since everything kept changing with every release.
"Decentralized" in the developing sense, for distributed consumer, business and individual services, is about identity and trust. In contrast to "federated," the services do not have to have a specific agreements between them, they just have to adhere to standards with identity and privacy baked in. As an example, this was how OpenID Connect was supposed to work, but for simplicity, most logins only permit a few providers. The modern standards around these ideas, if you really want to explore, are Verifiable Credentials and Decentralized Identifiers, sometimes collectively referred to as "self-sovereign identity."[1] These standards are designed to enable deep exchange of information between any services (with user permission), while preserving privacy. Each participating service just gets a random identifier, with no personal information.
The idea of "files," where all the information required for a "document," is disappearing for many purposes. A document is a moment in time. Instead, information is an aggregate panel from distributed (decentralized) information. This is evident from how federated identity works today, and how specialized services people access from a web site work with increasing ease and utility, though today it's about pushing the envelope with obscurity and plunder.
If you only work in files, and you "even manage" to do complex things with your volume control, and you're content, then you're basically part of the problem. You have a 1990s vision of a desktop, which you expect every other user to climb to identically, even though many of the steps constantly shift for arbitrary reasons. The steps you used to get your volume control to work that way were about a moment in time configuration, built on all kinds of underlying knowledge that is probably deeply entrenched in your life, and it should have been simple. Do you expect every user to go through that, or does it take a special user?
Consumer solutions, based on the web and closed operating systems and ecosystems, are providing these features, based on increasingly sophisticated ideas of "what most people want," and based on deep integration with distributed (but not decentralized) web services. These approaches have risks, but also huge advantages, but they truly need more consciousness from end users. If Linux is going to be relevant to more than a small cohort of desktop users, and a Linux desktop is meaningful as a true open, comprehensible platform rather than a way to access a browser which does black magic, it has to highlight these features. These features are available in completely coherent forms (see Matter standards, IoT, Solid, VC, DID, etc) to allow services like getting a drivers license or booking a complex international trip online in minutes without relying on a black box web site, but because so many people can only see a 1990s desktop, efforts behind Linux Desktops are basically a dog chasing after a 1990s car.
KDE was way ahead of the curve with Nepomuk. It provided a local semantic database of fine information, built around standards with networked schemas that support entailment. So rather than typing documents from memory, local and distributed information is integrated. But it was too ambitious, and most technical users got distracted by the money to be made selling pet food online or the challenge of getting their volume control networked. So, today, all the centralized providers, and open projects like Wikidata, are forming around these ideas. But Linux desktops are too busy trying to re-add live backgrounds to pay much attention.
Finally, notice I am only now mentioning "blockchain?" Blockchain can be used in some schemes, for example to host public keys and revocations, but this is not a side effect of blockchain hype, it's about where everything is headed, if computers are more than fancy typewriters.
1. https://en.wikipedia.org/wiki/Self-sovereign_identity
"Decentralized" in the developing sense, for distributed consumer, business and individual services, is about identity and trust. In contrast to "federated," the services do not have to have a specific agreements between them, they just have to adhere to standards with identity and privacy baked in. As an example, this was how OpenID Connect was supposed to work, but for simplicity, most logins only permit a few providers. The modern standards around these ideas, if you really want to explore, are Verifiable Credentials and Decentralized Identifiers, sometimes collectively referred to as "self-sovereign identity."[1] These standards are designed to enable deep exchange of information between any services (with user permission), while preserving privacy. Each participating service just gets a random identifier, with no personal information.
The idea of "files," where all the information required for a "document," is disappearing for many purposes. A document is a moment in time. Instead, information is an aggregate panel from distributed (decentralized) information. This is evident from how federated identity works today, and how specialized services people access from a web site work with increasing ease and utility, though today it's about pushing the envelope with obscurity and plunder.
If you only work in files, and you "even manage" to do complex things with your volume control, and you're content, then you're basically part of the problem. You have a 1990s vision of a desktop, which you expect every other user to climb to identically, even though many of the steps constantly shift for arbitrary reasons. The steps you used to get your volume control to work that way were about a moment in time configuration, built on all kinds of underlying knowledge that is probably deeply entrenched in your life, and it should have been simple. Do you expect every user to go through that, or does it take a special user?
Consumer solutions, based on the web and closed operating systems and ecosystems, are providing these features, based on increasingly sophisticated ideas of "what most people want," and based on deep integration with distributed (but not decentralized) web services. These approaches have risks, but also huge advantages, but they truly need more consciousness from end users. If Linux is going to be relevant to more than a small cohort of desktop users, and a Linux desktop is meaningful as a true open, comprehensible platform rather than a way to access a browser which does black magic, it has to highlight these features. These features are available in completely coherent forms (see Matter standards, IoT, Solid, VC, DID, etc) to allow services like getting a drivers license or booking a complex international trip online in minutes without relying on a black box web site, but because so many people can only see a 1990s desktop, efforts behind Linux Desktops are basically a dog chasing after a 1990s car.
KDE was way ahead of the curve with Nepomuk. It provided a local semantic database of fine information, built around standards with networked schemas that support entailment. So rather than typing documents from memory, local and distributed information is integrated. But it was too ambitious, and most technical users got distracted by the money to be made selling pet food online or the challenge of getting their volume control networked. So, today, all the centralized providers, and open projects like Wikidata, are forming around these ideas. But Linux desktops are too busy trying to re-add live backgrounds to pay much attention.
Finally, notice I am only now mentioning "blockchain?" Blockchain can be used in some schemes, for example to host public keys and revocations, but this is not a side effect of blockchain hype, it's about where everything is headed, if computers are more than fancy typewriters.
1. https://en.wikipedia.org/wiki/Self-sovereign_identity
For me, Gnome died at 12.
In case the author is reading, the specified font-family 'Cantarell' is not loading and there are no fallbacks specified. Probably needs a 'sans-serif' fallback or a webfont.
I was always more of KDE person, but I've always liked GNOME.
I tried it, hit a few bugs and immediately switched. The right click menu for the language bar was stuck on the desktop forever which annoyed me right away. It happens in Windows too, and I just don't want to use buggy software.
Gnome has lots of bugs too, but they are not obvious and in my face like this.
Gnome has lots of bugs too, but they are not obvious and in my face like this.
25 years, still no preview images in file picker
It beggars belief that gnome devs seem somehow totally incapable of understanding why one would want a proper thumbnail view in the file picker. Have they never had to find a specific image in a directory of many images? If you told me their response to the file picker issue is some kind of elaborate troll or gaslighting operation I would believe you.
Not a Linux user, but I heard about the problem OP describe with this usecase: identify a picture of your children in a camera dump with dozen of pictures where the filename are all dsc_1346.jpg. Don't use a dedicated software because it's only for quick sharing.
I see two previews, one next to the file name, and a large one on the right when clicking on a image file name. So:
25 years, now with preview images in file picker :)
25 years, now with preview images in file picker :)
1. select thing
2. press space
3. get preview of thing
4. come to hackernews
5. make a post complaining about lack of thing previews
6. ????
Amazing desktop if primarily used with the keyboard. Congratulations to 25 years!
Happy birthday Gnome!
I'm extremely happy with ............. XFCE!
Happy birthday GNOME. You might not have as many fans as years ago, but I appreciate the courage of trying something new. I miss GNOME 2, but yours is still my favourite desktop on the PC bar none. Looking forward to the next 25 years.