File picker meme
wiki.installgentoo.com
wiki.installgentoo.com
The presence of text box in which any text entered does something totally unexpected is at least universal.
Now, what do you think will happen if the GTK/GNOME developers get rid of that "bizarre textbox" so it doesn't get in your way? Yes, they'll get a torrent of abuse for "removing the last power user feature" or something. :-)
The lack of collaboration between desktops is, in my opinion, at the core of the fragmentation that makes Linux desktops still appear so far from their proprietary counterparts.
This is not to say that either desktop is perfect in vision or implementation, of course, but the "GNOME vs KDE flame wars" are just childish talk. Mature criticism and, especially, collaboration is what both desktops need.
But the GTK filepicker is simply an embarrassment, there's no other word for it. For all of the effort that has been spent on everything else Gnome-related, adding thumbnails to the filepicker would have been an extremely easy win.
The current implentation is at Win 3.x levels of design and experience.
https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
>The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog.
In addition it being a dbus api for communicating outside a sandbox
Flame wars about what DE is best reminds of the days when people thought you were a 'hacker' just because you used linux. Or better, when people used linux just because they thought people would think they were hackers.
For example, mentioning how irrational is that to this day GIMP has no dedicated tool to draw basic geometric shapes (rectangles, ovals) as every other image editor does, even the most basic ones, can get you a lecture about how GIMP is free software, its lack of funding, that (allegedly) those tools are irrelevant and go against their philosophy, downvotes, bans...
>GIMP is free software, its lack of funding, that (allegedly) those tools are irrelevant
If you have a specific feature request, you might consider checking the bug tracker for an existing issue. If there is one, then it's not helpful to mention it any further. The developers already know what the request is. From that point on the only helpful thing you can do is to contribute code, designs, etc towards getting the feature done.
To illustrate, have you ever had somebody sitting behind you while you work who keeps repeatedly saying things like "are you working on that thing for me yet? are you done yet? when will you be done?" until you finish? It's kind of like that. Doing that doesn't help the person go any faster.
Locked as expected. But really? Well-written written arguments from users and developers is considered spam?
I guess some people out there do like moron-friendly UI and UX.
Of course in my opinion Ubuntu isn't the same now as then but on the other hand KDE Neon is now even better.
> I've created a new thread that hopefully is a bit more relevant. Continue the conversation here
> ['here' marked as duplicate of 'this' and closed]
When you see someone getting into a screaming match about why Playstation is better than XBox it may indicate narcissism. If the screamer had chosen the second best option, that would imply they aren't perfect and that isn't something a narcissist is able to process. The internet just allows for the XBox and Playstation selecting narcissists to find one another.
Yes. The bug tracker is not a place to have an argument. The correct place for that would be a mailing list.
Option B: applications can choose between GTK 3/4 (not exactly a fan favorite) and get native looking title bars only on GNOME (without extra work — also only supports an out-of-date spec for native window frames on Wayland) or they can use libdecoration (or libdecor or whatever) which appears to be persistently not ready for prime time, and will still not look native in most Wayland compositors.
Honest to goodness, apps should just force themselves into X11 mode on GNOME until the compositor is fixed. The CSD initiative is a broken idea.
This isn't true, some X11 window managers don't draw any title bars.
Anyway this isn't a problem if you link against GTK or libdecor. Yeah it's broken if you're trying to work against the system and do things in the inconsistent way that they were done in X11, so... don't do that?
And telling me all Linux apps they should link against GTK would make me angry if it wasn’t so stupid.
P.S. edit: I’d just to like to add:
- Please don’t take my harsh tone too personally. I’m not pissed off at people, I am pissed off at their initiatives sometimes though. I don’t really harbor any ill will towards individual developers. I think if you make decisions that impact an ecosystem it’s only natural that strong emotions will emerge.
- The main reason why GNOME solutions are not really landing that well is specifically because they are attacking the problem more from GNOME’s philosophical standpoint than from the standpoint of what is best for applications. KDE does not appear to be embodying the CSD initiative, which is actually Good for GNOME users, since KDE apps will likely feel a ton more native in GNOME as a result. Certainly more than GNOME apps do in KDE… but it also means that libdecor is kind of moot, because what we as app developers really want is one solution that gives us fully native basic window borders everywhere. And to do that, we need a solution that starts from the common ground (xdg-decoration) then goes into special cases (GNOME, Weston, etc.)
It does, that was the first thing added. I wouldn't suggest using xdg-decoration though as it will mostly guarantee that your apps don't match the decorations.
>And telling me all Linux apps they should link against GTK would make me angry if it wasn’t so stupid.
If you want GTK decorations, then you should link against GTK. Not sure why you would think that's stupid or would make you angry, please elaborate. If you don't want to use compile time linkage then you can use dlopen, that's what libdecor does under the hood.
>KDE does not appear to be embodying the CSD initiative
This isn't entirely true, some KDE apps have actually started to use client-side decorations.
>which is actually Good for GNOME users, since KDE apps will likely feel a ton more native in GNOME as a result
I don't think so, KDE apps will never feel native in GNOME as they're built for a different HIG. Using non-matching decorations will actually make it worse because now the application is following two separate and incompatible HIGs. That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency.
>what we as app developers really want is one solution that gives us fully native basic window borders everywhere
I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on.
>And to do that, we need a solution that starts from the common ground (xdg-decoration) then goes into special cases (GNOME, Weston, etc.)
This isn't correct, xdg-decoration is not the common ground. The common ground would be drawing your own decorations because that's the way any Wayland server works by default. Xdg-decoration is an optional extension that even with its presence doesn't guarantee you will get the borders that you want.
Surely the choice should fall on the user.
> That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency.
Which is why we would like all of these to be configurable.
> The common ground would be drawing your own decorations because that's the way any Wayland server works by default
What if I, as a user of a tiling wm don't want any decorations?
> Xdg-decoration is an optional extension
That everything supports it afaik. (except mutter?)
It does, the user can choose to use GTK or Qt apps.
>Which is why we would like all of these to be configurable.
So making it all configurable is just guaranteeing that the app is broken out of the box and needs to have all this stuff set up before it even works correctly. Not exactly a user-friendly way to ship a program.
>What if I, as a user of a tiling wm don't want any decorations?
You may have to accept that some apps are not built to work in a tiling WM. In my experience, you will have a lot of trouble with some apps for various other reasons too, not just the decorations.
>That everything supports it afaik. (except mutter?)
I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
That's... not what I meant by it. I find this dangerous as it encourages duplicate work for minor differences.
I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization.
> So making it all configurable is just guaranteeing that the app is broken out of the box
Not sure why you think that. You just put the existing choices as the defaults.
> You may have to accept that some apps are not built to work in a tiling WM
What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.
As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor. To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.
> In my experience, you will have a lot of trouble with some apps for various other reasons too
Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.
> I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?
Edit: I heard that Enlightenment does not support it either.
Sure, but this fragmentation isn't exactly new. There have always been multiple toolkits on Linux. I don't know what else to tell you, if you don't like it then you can pick one toolkit for your own apps and just focus on that. I wouldn't exactly call this "basic customization" if it requires you to rewrite your whole app so it's fine to just use one toolkit. I understand maybe you are facing some indecision about toolkits, that's normal, you may want to take some time to research them and find which one suits your app better.
>Not sure why you think that. You just put the existing choices as the defaults.
I already explained it, that will be broken if you use it outside the recommended environment as the HIGs won't match. The defaults only make sense on the target platform.
>What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.
Well, no it doesn't. You can disable the decorations in GTK. Most GTK apps don't by convention but you can do it if you really want. And you don't have to use GTK, you could use another toolkit.
>As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor.
>Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.
I disagree with this entirely, the app needs to be designed in a fully responsive fashion to do that. Most older apps aren't like this.
>To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.
I don't know what you mean by this. GNOME is not a tiling WM, so people who make GNOME apps usually do not target tiling WMs or test there. It would actually be the opposite, supporting the tiling WM would be going out of their way.
>Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?
The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.
I think that we got a little bit sidetracked. "I want my users to be able to be able to select what borders to have" -> "the user can choose to use GTK or Qt apps" -> "it encourages duplicate work for minor differences" -> "fragmentation isn't exactly new"
Fragmentation might not be new but I would really rather not re-write my UI in another toolkit just to offer a second border option.
> that will be broken if you use it outside the recommended environment as the HIGs won't match
Depends on your definition of broken I guess. If you consider the user unbinding C-q from "quit" as broken because "the HIGs won't match" then I would have to say that I disagree. If the user wants to make "breaking" chances to my applications they should be free, especially since I don't believe that any big issues will be caused. If some minor issues are caused at certain configurations then that's fine, after all the user could revert to the default config if they encounter an issue that breaks their use-case or makes the interaction feel inferior to the default one.
> Well, no it doesn't
Thank you for the correction, I take it back. I guess if I go with gtk4 I would have to use a mix of gtk4+libdecor in order to have "native" borders in all WMs, is that correct?
> Most older apps aren't like this.
What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era? I do not think that I had a big issue with any of them but I could be forgetting something.
> GNOME is not a tiling WM
Well, yeah, because GNOME is not a WM :p
By "going out of their way" I meant specifically the decision to implement CSD.
In general I think that GNOME should be able to do whatever it wants, I just wish that they would play better with the other players (and well, the users).
> The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.
More like "all (relevant) C compilers except MSVC support C99 VLAs", or "all mobile phones in the EU except apple's use a standard charger". The point is that while xdg-decoration might be an optional extension in reality it is pretty much standard except in two WMs that require special handling.
Then don't offer that second option? You can also offer multiple border options within the toolkit.
>If you consider the user unbinding C-q from "quit" as broken because "the HIGs won't match" then I would have to say that I disagree.
That would be one keybind. Complex apps have many keybinds, it's not really feasible to expect every user to change them all to match whatever their setup is. You could provide this as an option if you really wanted but some applications won't bother with this.
>If the user wants to make "breaking" chances to my applications they should be free, especially since I don't believe that any big issues will be caused.
Again you could provide this as an option if you really wanted but this is a sub-par experience for the user to have to mess with this. What I see really complex cross-platform apps doing: they just decide which platforms they support and then provide different sets of keybinds for each of those platforms, no need for the user to have to re-configure hundreds of keybinds to match their setup.
>I guess if I go with gtk4 I would have to use a mix of gtk4+libdecor in order to have "native" borders in all WMs, is that correct?
No, you cannot use libdecor with GTK4 at this time because of technical limitations. GTK4 technically does support the kde server decoration protocol which is an older version of xdg-decoration. So that may already work if you're using a wayland server that supports it. Otherwise you could try to patch GTK4 to support xdg-decoration.
>What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era?
I've noticed many apps that are built around the old-style desktop concepts of menus/toolbars/panels/dialogs don't play well with the extremely squashed resolutions that tiling window managers tend to put windows into. This is the same problem with trying to run those "native" apps on a Linux phone like the Librem, they just aren't designed to run at a small resolution.
>Well, yeah, because GNOME is not a WM :p
Sorry, what I mean is that GNOME includes its own WM and shell which is the only thing that it supports, and that is the only thing that GNOME developers usually test with. They have not supported alternate WMs in quite a while, as they have no reason to.
>By "going out of their way" I meant specifically the decision to implement CSD.
Well that's not true, you can see some of the motivations for using CSD here: https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
You may not agree with these motivations, but they were not done to make you miserable. Please don't assume bad faith.
>I just wish that they would play better with the other players (and well, the users).
I'm not sure what you mean, GNOME is its own platform. If you are not a user of that app platform then I don't see why it would matter to you.
>The point is that while xdg-decoration might be an optional extension in reality it is pretty much standard except in two WMs that require special handling.
There's no special handling, everything that is needed to support xdg-decoration is also needed to support those other WMs. Even with xdg-decoration, you still need to provide a fallback. Also, I believe Weston is another one that does not support it, and the Elementary compositor is likely not going to support it either.
> Again you could provide this as an option if you really wanted but this is a sub-par experience for the user to have to mess with this.
Then don't make them. Just do what every other desktop has done since 1992, give people the option to configure things the way they want, and save your "sub-par user experience" argument for setting the defaults. If corner-cutting starts to affect power users, you need to go back to the drawing board and re-think things. Luckily, this is a pretty easy situation: nothing is broken, nothing needs to be fixed. It's along the lines of GNOME deciding the remove your clipboard history because it was gauche and such an old and ugly feature.
> Well that's not true, you can see some of the motivations for using CSD here
Yeah, real motivation going on there. Of the 4 apps they mention needing CSD, only one got it. Is that really what 3 years of progress should look like for that kind of initiative?
> I'm not sure what you mean, GNOME is its own platform. If you are not a user of that app platform then I don't see why it would matter to you.
GNOME is not Linux, and the issue is that the GNOME developers are making too many decisions on behalf of the end user. I didn't have an issue with the mostly hands-off approach that GTK2 and 3 used. I do take issue when I can't use a desktop environment because my preference for handling packages is apparently verboten, and now they've decided to remove features that I liked. It's a regression on the level of dropping the Unity desktop, but even more user-hostile.
And even still, I have a hard time calling GNOME in it's current state much of a platform. It exhibits constant crashing issues on my Haswell devices which means I can't use it on half my devices, and it only truly functions on one or two distros. Not to go "us vs them", but KDE has no problem maintaining a stable, usable desktop even across major releases. I'm utterly dumbfounded by how the current maintainers of GNOME feel so self-righteous in their redesign, especially considering the state of their recent releases.
So your statements here aren't correct. Please avoid accusing me of being a fanboy. If you really want to know my opinion, I'll use any desktop and I'm not passionate about any of them, GNOME is just one of them. They each have their strengths and weaknesses. But if you're asking questions about GNOME and GTK then I'll give you straight answers, they are also part of the "Linux community" and it doesn't help either of us to misrepresent them. There are certain facts about that which it is not helpful for us to disagree on, because they are just that: facts, not opinions.
>Then don't make them. Just do what every other desktop has done since 1992, give people the option to configure things the way they want
Well some users may have no need to configure that. And like I was saying with complex apps, it may be that you don't need to give users a really complicated way to configure every little detail. It may be that what they really want is just a way to swap between "presets" and that will be enough for everyone. You don't know until you actually do the design work and iterate. This of course is a more complex and nuanced topic than just saying "give us an option" or "give us a default" or something like that.
>If corner-cutting starts to affect power users, you need to go back to the drawing board and re-think things.
Well no, in my experience power users are just as likely to be trying to accomplish something specific like that. When you get down to it their usage patterns are not particularly different.
>Yeah, real motivation going on there. Of the 4 apps they mention needing CSD, only one got it. Is that really what 3 years of progress should look like for that kind of initiative?
I really don't know what their progress goals are but there are many other GNOME apps not listed there that use CSD, you should look at them if you're interested to fully understand the progress.
>GNOME is not Linux, and the issue is that the GNOME developers are making too many decisions on behalf of the end user.
Yes I agree that GNOME is not Linux. But GNOME developers are making decisions on behalf of GNOME users. That's what they're supposed to do, those are the end users they support. I don't understand what your issue here is. If you don't use any GNOME software then their decisions won't affect you.
>I do take issue when I can't use a desktop environment because my preference for handling packages is apparently verboten
Which preference is this? Can you elaborate?
>and now they've decided to remove features that I liked. It's a regression on the level of dropping the Unity desktop, but even more user-hostile.
I'm sorry to hear that, but I hope you can understand that every project cannot support infinite features. If it's desired to add a new feature then sometimes an older feature that has some overlap with it will have to be removed. That's just the unfortunate reality, nobody is trying to be hostile to you. And it's not really feasible to ask software developers to stop adding new features, if they did this then everything would stagnate.
>And even still, I have a hard time calling GNOME in it's current state much of a platform. It exhibits constant crashing issues on my Haswell devices which means I can't use it on half my devices, and it only truly functions on one or two distros.
Can you please report these bugs? I've never experienced this. If those are legitimate bugs then I'm sure someone will want to have them fixed. It could possibly be a driver issue that is not strictly related to GNOME.
>Not to go "us vs them", but KDE has no problem maintaining a stable, usable desktop even across major releases. I'm utterly dumbfounded by how the current maintainers of GNOME feel so self-righteous in their redesign, especially considering the state of their recent releases.
Please understand that not every project has the resources to test with every hardware combination, it may just be that you hit some unusual and unfortunate combination of hardware and software that blows up. It's just lucky for you that KDE doesn't hit that.
If you don't want to use GNOME or Flatpak that's perfectly fine, I'm happy for you to choose whatever you want. But some of the statements you've made here are false, including the assumptions you've made about me. That's not being respectful to me or to the project when you do that. Please don't spread misinformation or make decisions based on false information, that damages the community and it also hurts both me and you. If you're not actively using/developing a certain project or in regular contact with the developers then I would suggest not making definitive statements about it or assuming that your experiences are shared by everyone. IMO it's a mistake to quit a discussion based on false information. If you ever change your mind and decide you want to report those bugs, the door is wide open for you.
Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case.
I will grant you that I didn’t know libdecor supported xdg-decoration. I attempted to read the source code once and entirely missed it, possibly because I was focusing too hard on the plugins aspect.
Anyways, this is going too far off the deep end now. Yes I understand that Dolphin will never look as native under GNOME as Nautilus. However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability.
I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.
No, not really. On those other platforms you would link against the toolkit.
>If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM.
Same thing with Wayland, except typically apps are expected to draw the window borders there.
>Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine.
Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly.
>Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case.
No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own.
>However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability.
Yes, apps that don't follow the KDE HIG will always look non-native. Try to run windows apps in Wine and it will similarly look out-of-place. Try to run some old Motif apps and they'll look weird too. If you want to get an app that looks and acts native in KDE then you would want to use the KDE frameworks. Why complain about this when you're use an app that is intentionally designed for a different platform?
>I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.
So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.
This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function.
macOS internals are harder for me to ascertain, but it seems similar in how responsibility is split between OS and application.
Besides that, GTK is not the canonical toolkit of Linux or Wayland. So this is not a reasonable option even if it would be on another system.
> Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly.
They make GTK apps behave badly, but most Qt stuff works pretty reasonably.
Anyways, if you dislike tiling WMs that’s fine, but I don’t and I want my apps to act decently, like apps designed to work with tiling WMs tend to work (which is not a huge ask at all, considering they don’t ask for much other than accurate window hints and no custom borders.)
> No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own.
That’s not a good solution. That just means my app will look like crap if the compositor doesn’t support xdg-decoration.
> So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.
The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. And for that, this opinion is literally the crux of the issue.
You would still need to link against the toolkit. Plus, if it's a syscall, that means the kernel is involved in drawing the decorations, which is probably not going to happen in Linux. Sorry. Not every OS is built the same as Windows. If you like the way Windows is built, you might want to use it and not Linux.
>Besides that, GTK is not the canonical toolkit of Linux or Wayland.
Right, but that doesn't change it. If you want GTK decorations, you link against GTK. If you want other decorations then you link against another toolkit. If you don't care about the decorations and just want whatever then you could use xdg-decoration or libdecor, but not all app developers will want that.
>So this is not a reasonable option even if it would be on another system.
I don't understand what you mean reasonable? Both ways work if you're designing a system, you only have to care about them if you're a developer because it's a minor implementation detail.
>They make GTK apps behave badly, but most Qt stuff works pretty reasonably.
My experience is actually the opposite, Qt apps are even more likely to have odd sizing issues or inconsistent behavior. But I probably used a different set of apps than you did.
>considering they don’t ask for much other than accurate window hints and no custom borders
Maybe the window manager developers don't ask for anything but the apps are still broken. A lot of desktop apps cannot be placed into 1/6th of the corner of the screen and still work correctly but that's what tiling WMs try to do. Especially on a laptop with a small screen I find this behavior to be completely unusable. The window hints and borders are really not significant compared to all the other issues, so I honestly have no idea why some people seem to be so focused on that.
>That just means my app will look like crap if the compositor doesn’t support xdg-decoration.
This makes no sense to me. Libdecor will draw the fallback, if your app correctly supports xdg-decoration then it has to draw a fallback. The only thing xdg-decoration does is allow the compositor to draw fallbacks in some circumstances, so if you think the fallbacks all look like crap, then nothing you do there will ever help. There is no possible way to solve your problem.
>The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders.
It's the same difference. Just as in X11, some window managers will never handle the window borders. There is nothing you can do about this besides patching all those window managers. But you probably don't care about that because most people don't seem to switch window managers very often.
Again, User32 is not like GTK or even Cocoa.
I didn’t say I liked the way Windows is built, I’m just trying to explain to you how it works because you are saying things that are inaccurate to prove your point. And besides, people who like the way Windows is built would be fully allowed to impose their own feelings into such a discussion. It is, after all, the most commercially successful operating system, and its UI, for all its faults, is a hell of a lot better to use than GNOME in the opinion of many hardcore Linux users.
> I don't understand what you mean reasonable? Both ways work if you're designing a system, you only have to care about them if you're a developer because it's a minor implementation detail.
Yes. But unless GNOME is an operating system in and of itself, it cannot prescribe what the canonical toolkit of Linux is. User32 ships with Windows; it is as integral to Windows as the kernel is. GTK isn’t even close to as ubiquitous on Linux, and it’s also not nearly as integral to the operating system.
So no. It is not reasonable to ask applications to link to a canonical toolkit. There is a canonical toolkit on Windows and macOS. But if I write an app that is cross platform, as many of the apps people install today are, I want to be as agnostic as is reasonable. I don’t want my app to look like it’s running in VMWare Unity Mode on the majority of desktops, because at that point it might as well be, and why even port software to Linux?
This line of thinking requires Linux to be a cohesive platform like Windows or macOS, but it is not. GNOME is not an operating system. It’s not even a distribution of Linux.
> This makes no sense to me. Libdecor will draw the fallback, if your app correctly supports xdg-decoration then it has to draw a fallback. The only thing xdg-decoration does is allow the compositor to draw fallbacks in some circumstances, so if you think the fallbacks all look like crap, then nothing you do there will ever help. There is no possible way to solve your problem.
The problem you’re having is that you seem to have a distorted view of the ecosystem. There are tons of Wayland compositors just as there were X11 WMs — having all of them have libdecor plugins would be possible, but I fail to see how it is ideal in any way. The way I see it, a compositor that supports xdg-decoration is likely to have nice looking fallback borders, and one that does not is likely to show hideous GTK borders. It’s only a reasonable option to do the latter if the desktop environment truly prescribes nothing yet still expects window borders. However, I know of none that do this: tiling WMs don’t draw them at all, and other WMs generally have customizable window borders.
The difference between libdecor and xdg-decoration is simple: one is a protocol level thing, and the other is some crap off to the side that people have to contribute to. Or you can just support xdg-decoration and get libdecor support for free. So why would anyone not unless they intentionally designed their compositor to not support this?
> It's the same difference. Just as in X11, some window managers will never handle the window borders. There is nothing you can do about this besides patching all those window managers. But you probably don't care about that because most people don't seem to switch window managers very often.
Maybe GNOME users never swich window managers, but I definitely switch between a few. I like SwayWM quite a bit these days, and I have my own toy Wayland compositor that I occasionally poke around with. xdg-decoration feels like it is in spirit with the nature of Linux and the freedom to choose; anyone can, with no centralization, just support it, and most apps can display native window borders.
Not GTK apps, even ones that request native borders, though; it seems the GTK folks are such great pals of the ecosystem that they only support an older non-standard for negotiating native borders. Gee, thanks everyone.
Anyways, you keep alluding to X11 WMs that don’t draw borders, but please give me an example of an X11 WM that doesn’t draw borders and expects the client to do so. Seriously. If the WM doesn’t want windows to have borders, like tiling ones, I don’t want to fuck with that. I want my app to display with no borders because that’s evidently what the user wants. This is not the same as GNOME not supporting xdg-decoration and having apps with no borders. That issue didn’t occur on X11 because that wasn’t how window management was approached.
I am totally okay with apps having the ability to draw their own borders. Discord, VSCode, Chromium and plenty of other apps do it, it’s fine. There is no serious issue with the concept of CSD. I think, though, that pushing the responsibility to draw basic native borders onto the app is still not an ideal situation. I view CSD as a fad. I do not think it makes for better UIs, either from an aesthetic standpoint or a usability standpoint. Now that is just an opinion. On the other hand, the reality is that 10 years ago, very few apps ever did CSD, nor did any system really expect them to. And so, moving the expectation to the client is naturally a breaking change. The expectation, broadly across many systems and WMs, used to be separated from the client. It’s kind of crazy that I have to even argue this, since if this wasn’t the case, there would have been absolutely no reason to have the CSD initiative since clearly it was the status quo. It was not. And the protocol standards be damned, it really still isn’t. I still am not convinced linking to system libdecor is even a good idea, and I wonder how well this plays with containerized systems like flatpak.
There is really no question regarding xdg-decoration: when you’re on the protocol level, all of these problems disappear. And when all you need is a GL or Vulkan context, like many games, which tend to run in a chroot or sandbox, it is really, terribly silly to force this bizarre conundrum on them when all Mutter had to do was not wall itself out of implementing a spec like xdg-decoration.
Well, it’s too late now. But we are now years out from the CSD initiative and still today there are issues with apps and games that have no or broken borders in GNOME. GNOME developers, of course, blame the apps, and the app devs are all scratching their heads at why they have to deal with this new concern from a thing that doesn’t run well on their GPU anyways.
I’m very in support of Wayland, but this whole squabble was so easily avoided. Yes I know, that it would be ugly to have had essentially libdecor in the compositor. I am not convinced, however, that this change has resulted in a better system overall. It just moved a bunch of complexity and ugliness over to app developers. So… thanks???
I don't understand your explanation though, what you've described seems even worse, with needing to tie into the kernel to draw window decorations. So if you want different decorations, you need to install a kernel module or hack the kernel? I don't get it. Sorry if I don't get the specifics of Windows here but it's been a very long time since I did any hard-core Windows debugging and AFAIK most Windows developers are using a toolkit and are not making the raw NT kernel syscalls. But please correct me if I am still wrong here.
>for all its faults, is a hell of a lot better to use than GNOME in the opinion of many hardcore Linux users.
Honestly, I don't think anyone in the GNOME or KDE camps are interested in making a clone of Windows down to the kernel level. Sorry. I think if they wanted Windows, they would just use it.
>So no. It is not reasonable to ask applications to link to a canonical toolkit.
Yes it is because I was talking about the canonical toolkit for GNOME, not for Linux as a whole. If you don't want to support GNOME then don't link that toolkit. I really don't get what the concern here is.
>I don’t want my app to look like it’s running in VMWare Unity Mode on the majority of desktops
My experience with various Linux desktops for the last 15 years is that tons and tons of apps look like that. It's unavoidable because there are tons and tons of toolkits to choose from on Linux and none of them look or act the same. Sorry, what you want might just not be possible. At some point people who are using obscure and niche desktops have to accept that apps built for other desktops are going to look and act weird because not everyone has enough time to get everything working the right way on every obscure setup.
>This line of thinking requires Linux to be a cohesive platform like Windows or macOS, but it is not. GNOME is not an operating system. It’s not even a distribution of Linux.
I don't understand why you're saying this. I was talking about GNOME, not about Linux. Linux is obviously not a cohesive platform, if you thought of "Linux as a whole" you would also have to include Android and ChromeOS applications which would also look and act strange if you tried to run them in KDE or GNOME and vice versa.
>The problem you’re having is that you seem to have a distorted view of the ecosystem. There are tons of Wayland compositors just as there were X11 WMs — having all of them have libdecor plugins would be possible, but I fail to see how it is ideal in any way. The way I see it, a compositor that supports xdg-decoration is likely to have nice looking fallback borders, and one that does not is likely to show hideous GTK borders. It’s only a reasonable option to do the latter if the desktop environment truly prescribes nothing yet still expects window borders. However, I know of none that do this: tiling WMs don’t draw them at all, and other WMs generally have customizable window borders. The difference between libdecor and xdg-decoration is simple: one is a protocol level thing, and the other is some crap off to the side that people have to contribute to.
So I think you're confused as to what libdecor actually is and that's why it seems to you that my view is distorted. You've got it exactly backwards. You don't make a libdecor plugin for the compositor. You make a libdecor plugin for a toolkit. Libdecor is for client-side decorations, it has nothing to do with the compositor and compositor developers don't need to do anything to support it. If the compositor doesn't support xdg-decoration then it's up to the app to draw its borders. Yes a GTK app will fall back to GTK borders in that case, what else could it possibly fall back to? And BTW, GNOME has not supported user customizing the borders in quite a while. Only the app can customize the borders.
>Or you can just support xdg-decoration and get libdecor support for free. So why would anyone not unless they intentionally designed their compositor to not support this?
Again this is backwards and not how it works. What happens is that toolkits link against libdecor and get xdg-decoration for free. Xdg-decoration can be implemented by the server, and libdecor provides an implementation of it for the client that will fall back to client-side decorations if it's not there. Nothing needs to be done on the server to support libdecor.
>Maybe GNOME users never swich window managers, but I definitely switch between a few. I like SwayWM quite a bit these days, and I have my own toy Wayland compositor that I occasionally poke around with.
That's great and I'm glad you're doing that, but you are not the target user that GNOME app developers would be aiming for, sorry. They would be aiming for GNOME users.
>xdg-decoration feels like it is in spirit with the nature of Linux and the freedom to choose
This is not the spirit of Linux. I hate having to link this page often, but please read this: http://islinuxaboutchoice.com/
>Not GTK apps, even ones that request native borders, though; it seems the GTK folks are such great pals of the ecosystem that they only support an older non-standard for negotiating native borders.
Maybe they will accept a patch to update to the new standard, if you're serious about that then you should ask them. I don't think it would be much code.
>Anyways, you keep alluding to X11 WMs that don’t draw borders, but please give me an example of an X11 WM that doesn’t draw borders and expects the client to do so.
Well you already mentioned those, that would be most tiling WMs. In most tiling WMs I've seen it's a setting to configure whether to request borders or not, so it's not accurate to say that they always want windows to not have borders.
Continued in a reply because the response is too long.
From the app developer perspective it is the same though. A GNOME user will want their apps to have client-side GTK decorations because this is the way GNOME apps are built. It's the same as if that user was using a tiling WM and turned the client-side decoration setting to always on. You have to handle this if you are an app developer and want to support those platforms.
>I think, though, that pushing the responsibility to draw basic native borders onto the app is still not an ideal situation.
Well that's not what's happening, usually the responsibility falls on the toolkit. Libdecor exists to simplify the task for toolkits, apps should really not be linking against it directly unless they're something big like Blender that has enough resources to implement and maintain its own toolkit.
>I view CSD as a fad. I do not think it makes for better UIs, either from an aesthetic standpoint or a usability standpoint. Now that is just an opinion.
Ok that's fine for you if you feel that way, GNOME designers seemingly do not feel that way as it has become a central part of their design language.
>It’s kind of crazy that I have to even argue this, since if this wasn’t the case, there would have been absolutely no reason to have the CSD initiative since clearly it was the status quo. It was not. And the protocol standards be damned, it really still isn’t.
It is the status quo on GNOME.
>I still am not convinced linking to system libdecor is even a good idea, and I wonder how well this plays with containerized systems like flatpak.
It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
>There is really no question regarding xdg-decoration: when you’re on the protocol level, all of these problems disappear.
This isn't true, and it also has the potential to create other problems. What you are missing is that the protocol doesn't really matter, what matters is having a good experience for the user.
>But we are now years out from the CSD initiative and still today there are issues with apps and games that have no or broken borders in GNOME. GNOME developers, of course, blame the apps, and the app devs are all scratching their heads at why they have to deal with this new concern from a thing that doesn’t run well on their GPU anyways.
Those apps were totally broken on Wayland to begin with, Wayland did not even support borders at all before the KDE protocol and subsequent xdg-decoration which only happened a few years ago. So yes you could say is the app developer's fault, or more accurately it is the toolkit developer's fault for advertising Wayland support and yet having incomplete support for it. GNOME cannot fix app developer's apps for them, nor can KDE. And let me illustrate this again: even with xdg-decoration, even under KDE, all apps still have to implement fall-back decorations to be compliant with the spec. If your app is supposed to have borders and there is ever a situation when it has no borders then that app is broken as per the spec, you need to handle that case inside the app, not in the compositor.
>I’m very in support of Wayland, but this whole squabble was so easily avoided.
I disagree, there are real technical reasons why this wasn't done. KDE's implementation of this is also pretty complex and not suitable for all desktops to copy.
>I am not convinced, however, that this change has resulted in a better system overall. It just moved a bunch of complexity and ugliness over to app developers. So… thanks???
I don't agree with this either, the complexity and ugliness has moved to libdecor which gets used by the toolkit. App developers don't have to bother with the details, they just use a toolkit.
> It is the status quo on GNOME.
This is your problem, and GNOME's too: GNOME doesn't own the Linux desktop. The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. The protocol standards should be driven by the needs of the larger ecosystem. I'm not saying the needs of GNOME are unimportant. They are just not the end of what needs to be considered when developing this kind of thing.
This point here is more important than this entire argument about CSD. The rest can be discarded. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer? The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
> It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
> This isn't true, and it also has the potential to create other problems. What you are missing is that the protocol doesn't really matter, what matters is having a good experience for the user.
libdecor also has the potential to create other problems. This is just pointing out that software is hard. Yes, I get that.
If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem. The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
> I don't agree with this either, the complexity and ugliness has moved to libdecor which gets used by the toolkit. App developers don't have to bother with the details, they just use a toolkit.
Not every application needs a UI toolkit. There are also a lot of UI toolkits. Now many of them struggle with the fairly unimpressive task of displaying a window with reasonable looking borders. That's not a good user experience, and it's certainly not a good developer experience.
I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.
I'm sorry I have no idea what you mean. This is not about the Linux desktop, this is about GNOME. If you don't want to support GNOME then there's no reason to discuss this, because it doesn't matter, you can keep going about your way and you don't have to care about them. Am I missing something here?
>The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer?
They aren't, and they don't? I'm extremely confused as to what you're talking about here. This again is about what you would have to do to support GNOME. Not any other Linux desktop.
>The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
This doesn't matter because the issue here is how to make apps that aren't broken. Some things simply cannot be fixed in the compositor, they have to be fixed in the app, and this is one of them. I sympathize with your concern and I wish it wasn't the case, but sometimes app developers have to do some work that they don't want to do.
>Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
That isn't how flatpak works at all. You don't use the system version, you only use the vendored version, and you do that specifically to avoid that linking problem you mentioned. Also libdecor does use the protocol so I have really no idea what you're talking about again here, sorry.
>libdecor also has the potential to create other problems.
Sure but the problems there would be exactly the same as they would be if you did it all in the server, so libdecor is not making it any worse. The only difference is that the code moved to the client.
>If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem.
Well I'm not sure if you saw this part in my previous part but those apps are broken according to the xdg-decoration spec. It has really nothing to do with GNOME at all. All Wayland apps need to provide fallback window borders if they want to work correctly in all situations, if they don't then that's a bug.
>The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
I don't see why that concerns you if you're not a GNOME user and you have no interest in supporting GNOME. GNOME can deal with their own problems, if that causes them to lose users then that's something only they have to care about, not you.
Continued...
Sure, but if you don't use a toolkit then you need to take care of the missing pieces on your platform, in the case of Wayland one of those missing pieces is window borders. If you're a toolkit developer and you can't implement window borders, then I would suggest not advertising your toolkit as having complete support for Wayland.
>I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.
I'm sorry if this seems rude but both your opinion and my opinion don't matter and I don't care how you feel about this. That's nothing personal towards you. We're just two people having an informal conversation, it's just not helpful for us to look at it like we're trying to sway each other's opinions, so don't feel like you have to convince me of something or rebut my opinions. If you feel you don't want to support a certain type of decorations then that's perfectly fine, I'm happy for you to carry on doing that. But the technical reality of the situation and what that means for the challenges you may face is a different discussion from what you or I feel, and clearing up the technical stuff is all I'm interested to discuss.
If you have some other technical things to present then please do that, otherwise you're right that there is nothing more to discuss here. I'm only typing here to correct some misconceptions that I saw you had about the whole situation with libdecor. I find that most people who are upset about the situation don't really understand it fully or missed some key piece of information. I usually try not to do it point-by-point but it's really hard when you list a lot of points. However it does seem that a lot of your statements are stemming from a few initial misconceptions, so I can summarize that if you want.
Disagree completely, if they don't care to add such a relatively basic feature that every other environment has and don't care if their users have a 90s level experience opening documents which users do multiple times a day then why would you expect any of the rest of the system to have any care and attention paid to it?
Linux is a kernel.
Which terminology you use depends on what you want to emphasize.
I've talked to the devs responsible for this over on their GNOME IRC channel and they say everyone should port their applications to Gtk4 and Gtk3 is frozen and will never be fixed. I've attempted to fix it myself in source, compile, and manually swap in the new gtk3 libs but so far I can only get the filename entry text box to appear by default on the first "File->Open" operation but none after the first.
It is one of the major reasons I run older versions of software. Newer software is broken unless it is bleeding edge and then nothing actually uses it.
EDIT: here's the old, non-vandalized version: https://wiki.installgentoo.com/index.php?title=File_Picker_m...
However, I still really like GTK (even prefer it over QT, in many ways) and have full faith that the Linux desktop will push through. What concerns me is the hypocrisy of the modern GNOME team and how little they listen to the actual community using their DE. They claim to want "less settings and more features" yet remove features with every update, only to be forced into adding feature flags/settings options to add/remove it at the user's discretion. They claim that we're finally going to kill sacred cows, but the File Picker Meme still exists. They claim to respect your freedom, but force you to use Flatpaks and obfuscate their own code to prevent you from getting consistent app theming. It really disappoints me to see a DE fall from grace like this, but I probably shouldn't have been so dependent on a single project in the first place. Here's hoping they can iron out all of the (many, many) issues before the next major release.
Please remember: GNOME is a loosely connected group of volunteers all working on what they want to work on. If one person says they're prioritizing something and another person says they're going to do something else, that's not hypocrisy, that's just a difference of opinion. I know it may be confusing when one person says one thing and another person says something different but this is something you have to get used to in open source, it's not like a company where the CEO tells everyone what to do. Some developers may choose to listen to certain community members and may choose to ignore other community members, sadly that has to happen in any project where the wider community outnumbers the developers. Every interested person can't get their way all the time because resources are limited.
>They claim to respect your freedom, but force you to use Flatpaks and obfuscate their own code to prevent you from getting consistent app theming
This statement doesn't make sense to me. Flathub lists the license of the program and most packages are open source. And I have no idea what you mean by "obfuscate their own code" or "consistent app theming", could you elaborate? The suggested way to get consistent app theming is to stick with the Adwaita theme, if you're installing custom themes then that's guaranteed to be inconsistent.
>Here's hoping they can iron out all of the (many, many) issues before the next major release.
If there are issues that you want to see fixed, the best way to help that would be to contribute.
Windows File Explorer sucks, too, just not nearly as bad. (Though I'd put it FAR ahead of the Mac's counter-intuitive and ill-named Finder.)
It's the 21st century - WHY, OH, WHY do we still have file managers that provide NO CLUE as to the size and number of files in a directory? Why are all presentations still list or grid-based? Why does it take so long to find files? Can't we save the hashes from the last search and update them periodically when the machine is idle?
I'll venture a guess: Because "real programmers" don't use GUIs for file manipulation, so they JUST DON'T CARE about making the most important UI next to the browser any better.
I have no idea how to efficiently operate Apple's design, but I've never had a problem with the Windows file picker. Same with Gnome, to be honest, except when I'm trying to pick an image file. Out of all the UI options, I don't think the grid or list views are the biggest problem here.
I don't know what kind of view you expect, but even on phones you'll get grids and lists when picking a file. Every application on the desktop as far as I know has a mechanism to remember the last folder opened, but searches are rarely repeated. I think that makes sense because searches are usually for one specific file, and the probability that you want to open the exact same file multiple times in a row is relatively low compared to the probability that you want to open a file from the same folder. Windows Collections and the search folder mechanism do allow you to use such a method of file picking, though, because the virtual folders that every application already supports can be reused and customised to your hearts desire.
As for why it's still a flat overview of files and folders, it's probably performance related. On my machine, I can find pretty much any file by hitting the super key and typing. Gnome Tracker and Windows Search index all the files in my home directory and searching is pretty much instant. On hard drives the searching is slower, but at the same time the indexing barely ever runs because the hard drive is always busy (or the indexer is slowing down the whole system, like on Windows Vista).
Automated collections of images and video files work great in a sandboxes environment but Android's buggy file picker shows what happens with that paradigm in an arbitrary file structure, often missing pictures or listing deleted ones on my device because an app used the wrong API or a database sync is still running in the background. My device isn't even a particularly cheap one, I can't imagine how often people with $100 phones run it to this mess.
Crap like this contributes to burnout, people leaving the community, etc. Why spend your time on a volunteer effort if you're just going to be abused by non-contributors?
There's a reason behind the problem should anyone care to find out...
Most people reading this thread should have at least some sympathy (empathy, even) for architectural and social challenges in large, long-running software projects.
GNOME is a 22 year old project, and for much of that time its underlying toolkit, GTK (formerly GTK+), was intentionally maintained very separately. The consequence is that, broadly speaking, GTK could not depend on GNOME features.
So, shoving GNOME's Nautilus-powered file management in a GTK file chooser? That's tricky. Other GTK users would not appreciate GTK depending on, well, almost all of GNOME.
A point of integration was required, to allow the outside environment to provide the file chooser user interface. Turns out that's also tricky, especially when your toolkit is providing API/ABI guarantees. Consider that GTK 2.x maintained API/ABI compatibility for almost half the entire lifetime of the GTK project.
But no one gave up. More recently, the XDG portals work provides an opportunity to solve this (and quite a few other problems) cleanly and, more importantly, securely. This will also allow a KDE environment to provide the file chooser interface for a GTK application. Nice! Why isn't it already supported everywhere? Because there are a lot of people and projects involved.
It's entirely legitimate to ask, in good faith, why this wasn't done 10, even 20 years ago.
Consider that building a complete FLOSS desktop system is an immense amount of work, and that's what GNOME (even before 2.0) was focused on. Not just "a user interface for Linux", but making the entire stack work for real people. So many improvements in Linux desktop systems came from GNOME developers deciding that the status quo wasn't good enough. We wanted to fix the kernel, device discovery and enablement, dynamic wired and wireless network configuration, rich input devices, accessibility, etc., etc.
Remember, 20 years ago just getting X to work with your bloody monitor to work was enough of a pain.
Then, consider the priorities of the people contributing to the GNOME and GTK projects. Was it more important to break toolkit API/ABI compatibility to let GNOME replace the file chooser, or maintain that compatibility and work on other, arguably more fundamental problems?
Oh, and you know what happens when GTK/GNOME chose to break API/ABI compatibility for 3.x and 4.x? Everyone complained that FLOSS desktop developers can't maintain compatibility and that's the thing holding back "Linux on the desktop".
Anyway, if you're not already turned off by all the abuse that FLOSS desktop developers cop for literally everything they do, from people who don't know any better and people who should know better, I can still recommend it as deeply satisfying work. :-)
To be fair, this has been the #1 most requested issue in GNOME for quite a few years. Though now it seems to be second behind a blurry text issue.
https://gitlab.gnome.org/GNOME/gtk/-/issues?sort=popularity
>This issue is almost never raised in good faith.
I have no idea what you mean by that. This is a big issue that affects a large portion of users. Nobody is just pretending they need to see thumbnails for some nefarious purpose.
The file chooser issue is more often raised in the context of internet abuse than good faith user requests. That doesn't mean it's not real, it just means it's fodder for precisely the kind of document we're responding to.
>The file chooser issue is more often raised in the context of internet abuse than good faith user requests
What are you basing this on? That sounds incredibly dismissive. I think the core of the issue is that you're so out of touch with your users, that you're mistaking a highly requested feature with hostility. Maybe a user survey would be a good idea to bridge the gap.
I think one large discrepancy is that this only affects a subset of users who frequently handle a large amount of images. In this example, it is users of image boards. But it also includes artist, photographers, etc. Not so much professional programmers. But to those who are affected, they are hindered greatly.
I also see an issue with your idea that there are "good faith" and "bad faith" feature requests. This seems like a really unhealthy way to look at things. There is no conspiracy that there are a bunch of people out there that want to give you a bunch of work to do just to mess with you. 100% of these people are honestly affected by the issue and would like it resolved.
Genuine user requests are not made in bad faith. Stupid internet abuse is bad faith. Like I said: This issue, and others like it, mostly comes up as thoughtless abuse, not genuine user requests.
You seem like you're trying to convince me that it's a legitimate issue. I already know that. GNOME developers already know that.
>There is no conspiracy that there are a bunch of people out there that want to give you a bunch of work to do just to mess with you. 100% of these people are honestly affected by the issue and would like it resolved.
I don't know if you noticed, but the wiki article appears to include instructions for 4chan users on how to use this issue to troll and rile up Linux users. If you include whoever wrote that article and whichever 4chan users have read it then it's probably a good deal less than 100%. And honestly I've seen this trolling on reddit and hacker news pop up before several times before, almost every time the file chooser gets mentioned it seems to be a result of some 4chan trolling. Of course the issue is going to get locked if it's getting brigaded by 4chan trolls. If people honestly wanted to get it resolved, they would have written a merge request for it.
I personally don't care as one can use flatpak portals nowadays (qt makes it really easy for non-flatpak applications to use, but I haven't seen how I can do it in non-flatpak gtk applications).
https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbna...
> One may say, "quit complaining, the GNOME developers are doing for free!" Okay. Well, how much money should I pay for someone to fix this then? I’m legit offering a bounty here. Conditions are that this fix makes it into the master branch.
I think there are a few GNOME developers that have patreons or some other crowdfunding/bounty thing but it's not a major source of income for most. Getting $2 a month from a handful of people is not enough to fund a developer for any serious work. If you want to fund someone for real then you should probably pay a real developer salary which would be at least $75k-$100k a year in the US, and more if you want them to have competitive benefits. The price could be different in other countries. You might be able to hire one of the Linux consultancies to do it for the equivalent hourly rate. This is of course if you work for a company that can afford that. If you're a normal non-rich person then you're probably out of luck here, sorry. Software is expensive.
I also would be wary of anyone who guarantees they can get something into the master branch. To me that's scammer talk. Getting patches merged is an ongoing conversation between the developers and maintainers, you don't want someone who's just pushing code through without any checks. And if they're saying they can get something through before any code is even written and before anyone even knows if the solution is viable or not, then I would view that with extreme skepticism. If it's a major feature then it may end up taking months or years for it to get reviewed and merged, or it may just sit around for years and not get merged at all because it causes issues in some other part of the code, or it could end up being obsoleted by something else before then, or it could just end up being low priority and nobody gets around to it... or any number of other things really.
Hopefully that clears up some of those bizarre statements that are in that article.
How on Earth is it "trolling"? Seriously, I want you to explain to me how that article is bad-faith in any way. Yes, it's written in a absurd, ironic way -- that's because the situation it's describing is absurd. When such a massive, obvious usability flaw has gone unfixed for so long, people have the perfect right to joke about it and make fun of GNOME. Sorry if you think that's unfair trolling -- it isn't.
And lol at the goalpost moving
>gnome is underfunded
>okay, how much money to fix the file chooser
>oh well uhh that's now how it works and you couldn't afford it anyway
I'll go a step further and say: I don't think your assessment is correct. There isn't anything absurd about an open source project missing a popular feature, it's a completely normal situation. Most open source projects are underfunded and understaffed and seem to have a giant "wishlist" of unimplemented features. Also, please avoid making hostile jokes or mocking people, that's more of that cruelty-focused 4chan-style discourse that is against the rules here. It's not an interesting discussion. When you drift into that unproductive stuff that's just being cruel to other people, I would say that absolutely is unfair trolling, so please don't do that. A more productive discussion might be something like: we discuss ways to fund the project, we discuss ways to get bugs fixed, we discuss technical advancements that could help speed things along. Does that make sense? I'm happy to discuss that stuff with you further.
>And lol at the goalpost moving
This again is what I mean, please don't dismiss my comments like this, it's really hostile. I gave you an answer for what it costs, and I also explained why that's not really a good question to ask. If you want me to clarify something then just ask, I could also suggest some better questions to ask if you really do want to help open source developers.
I would also much rather consume software made by people that spend 99% of their time waiting for the weekend, than from people that write software out of self-motivation and enjoyment.
By the way, try using a pen or touch as a meaningfully usable interface on Linux (or Mac)... I'll never buy another computer that doesn't support both rich pen and touch - THAT'S a UI improvement that has changed my life, and made me swear off ALL keyboard-and-mouse-only desktops and laptops forever. (I still use KB/mouse when docked or using type cover, of course, but why would I ever want to limit myself to those?)
BTW - I'll probably also never own another computer that's not dockable - the ability to pull the computer out and have your entire working state just go with you in less than a second is incredibly valuable, as is the ability to dock again when you arrive at one of your desks. My only real complaint about the Surface is that battery replacement is really only practical as a device swap - and Li batteries don't last long enough to use the PC until its technically obsolete. (I'll upgrade to the new SP8, but I'm still running an SP4, which is my third due to two previous battery bloatings since 2014.)
Have you tried doing that on windows? No a pen is not supposed to be used for scrolling on a pc, it's not a smartphone: https://github.com/TheJoeFin/Windows10-Community/issues/17
I have seen windows ads on pro/enterprise on the lock screen even.
Maybe Microsoft dialed back the ads on the Surface, but on other platforms Windows is full of dark patterns to advertise Microsoft's own software. Just recently I've had to give admin permission to my computer to dismiss a warning from Windows Defender that I'm not signed into OneDrive.
I can't say I see the same value in the strong points of the Surface you see, but I have to admit that it's a shame how little good competition there is to the Surface line in terms of convertibles. Apple could easily outcompete Microsoft by providing a professional version of the iPad Pro that runs normal applications, but their desire for simplifying and locking down general purpose computers seems to prevent them from doing so. Other manufacturers like Dell and Lenovo simply don't seem to put out the same quality of hardware.
Starting with Windows 8 at the latest that argument was kind of silly :)