File picker meme(wiki.installgentoo.com)
wiki.installgentoo.com
File picker meme
https://wiki.installgentoo.com/wiki/File_Picker_meme
121 comments
This meme isn't a limited case and it's representative of the mindset that GNOME has. Extremely focused in one "vision" disregarding the opinions and issues of users.
Alas it does not happen only on GNOME.
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...
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 crap, the reason they make up all those excuses is because they have nothing better than it. The majority of them talking online seem to think GIMP is a superior image manipulation tool than Photoshop on a technical level despite the fact gimp cannot even simply or reliably draw a circle.
Your comment's really negative and disrespectful, please don't do that. If your test for drawing programs is "makes it simple to draw a circle" than Microsoft Paint would be better than both of them.
based
I'll disagree on that. GIMP has no dedicated tool to draw basic geometric shapes because it's an image editor, not a painting tool. For its devs to add such a tool will not be hard because GIMP can already do it in a more advanced way by stroking selection. If anyone wants to try: make a new image > rectangle/ellipse selection (shortcuts R/E) > press / (in keyboard) > write some of and enter on "Stroke selection..." > enter. If there's a problem with GIMP, it's being pretty complicated (then again it's an advanced program), perhaps more than its competitors.
I don't get this post. You listed several rational reasons why it has no tool to do that:
>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.
>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.
>Linux desktops
Linux is a kernel.
Linux is a kernel.
... and desktops running operating systems with a Linux kernel are called Linux desktops when it doesn't matter much which distribution is being discussed.
I agree that collaboration is always desirable, and that common standards are beneficial to everyone.
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.
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.
I've always wondered why file picker has to be so tightly integrated into GUI toolkit. Separate program outputting the selected path(s) sounds like much nicer design, and makes it easier to implement alternative file pickers.
I believe that is the purpose of the xdg portals specification.
https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
Not really
>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
>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
It was indeed designed to be a portal for escaping the sandbox, but this has the nice side-effect of allowing the file dialog to be implemented by whatever program is called through D-Bus. This is already being used in KDE distributions to show the KDE file picker in firefox, where it would've required patching firefox back in the day.
Not really how? https://github.com/ranchester2/nautilus-as-file-chooser-poc
This is a standardized GTK workflow that works in and out of flatpak.
I was under impression the backend has to implement all of the API to do that. Nice to know it's enough to have dbus service that listens to a single call. I might do this to replace file picker on my machine. It's still baffling however, how fork + exec <-> pipe can't be used for this. Especially considering that under all that dbus cruft the PoC essentially does this: https://github.com/ranchester2/nautilus-as-file-chooser-poc/...
Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...
I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.
Because the goal was to make an API that works the same both inside the sandbox and outside the sandbox. Edit: It wouldn't work with just processes and namespaces because you need a way to talk to a resource with a privilege level above the current mount namespace.
Right, the child process can't escape the sandbox. I guess IPC here is the only sane choice.
Although they disagree in many aspects, kde and gnome community have, AFAICS, had a healthy relationship for many years now. They collaborate with each other, implement common standards and even held events together. The adoption and popularization of ICCCWM, xdg-tools, PackageKit and even the support to wayland, pipewire and flatpaks are result of that.
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.
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.
Sometimes collaboration goes nowhere: https://gitlab.gnome.org/GNOME/mutter/-/issues/217
Option A: applications can continue to do what they’ve done for nearly 30 years and rely on system title bars. This will work everywhere — X11 GNOME, KDE, SwayWM, macOS, Windows, BeOS,… except GNOME on Wayland, and it will feel native.
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.
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.
>applications can continue to do what they’ve done for nearly 30 years and rely on system title bars. This will work everywhere
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?
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?
Does libdecor even support XDG Decoration? If not, no thanks. Sorry, but if you create a brand new problem for us to all deal with I expect you to have a solution too. If it looks or feels non-native on KDE it’s still broken…
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.)
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.)
>Does libdecor even support XDG Decoration?
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.
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.
I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there. 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. Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine.
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.
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.
>I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there.
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.
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.
> No, not really. On those other platforms you would link against the toolkit.
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.
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.
>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.
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.
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.
> 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.
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???
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’m just trying to explain to you how it works because you are saying things that are inaccurate to prove your point
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.
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.
> 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.
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?)
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?)
>Surely the choice should fall on the user.
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.
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.
> It does, the user can choose to use GTK or Qt apps.
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.
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.
>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.
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.
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.
> Sure, but this fragmentation isn't exactly new. There have always been multiple toolkits on Linux
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.
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.
>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.
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.
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.
>Enough spam for today. Locking the issue.
Locked as expected. But really? Well-written written arguments from users and developers is considered spam?
Locked as expected. But really? Well-written written arguments from users and developers is considered spam?
To the narcissist any criticism of anything they have done, believed, enjoyed or have been involved in is a personal attack, no matter how you phrase it. To you and I, we see a respectful conversation. In the view of the narcissist you might as well have been screaming personal insults at them.
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.
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.
The worst bit IMO is that that promptly followed:
> 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]
> 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]
[deleted]
Unfortunately GNOME development team has been more interested in hypothetical users than real users.
Oh, dear. Are they still chasing my grandmother? My grandmother has been dead for several years now, and my mom barely uses a laptop anymore, since she prefers her tablet.
Someone would have to really despise their grandmother if they install Linux on her desktop, doesn't matter which DE it is.
I guess some people out there do like moron-friendly UI and UX.
I guess some people out there do like moron-friendly UI and UX.
A granddad I think (he was at least old enough to be one) taught me that Ubuntu was a usable not too bad looking Gnome distro back in 2006 or so...
Of course in my opinion Ubuntu isn't the same now as then but on the other hand KDE Neon is now even better.
Of course in my opinion Ubuntu isn't the same now as then but on the other hand KDE Neon is now even better.
On the Gnome bug tracker? Yes.
But why, I don't understand. These conversations need to be had somewhere, why not in a bug tracker where developer said they won't fix it? There already is an argument not to fix it, why can't others support fixing it?
I don't think GP means it's good or that they agree with it. Just like 'oh yeah, that's to be expected there...'
Again, I don't understand why this is expected. I'm a software engineer and if someone said "closing this because principle! even though user wants it", I will most definitely support my position somewhere. Since this is a community project, why can't that place be public bugtracker instead of private emails?
I just mean that the other commenter's expecting it (I think) from experience, saying that that's normal there or that it doesn't come as a surprise to them. Again, not saying it's good and fine or that they think that.
It's not expected in general, it's the kind of thing I expect from Gnome, and specifically, on Gnome's bug tracker.
What's not to understand? Feature requests are closed if there are no plans to implement a certain feature. The developers are just being honest about their plans. Users wanting it or making arguments as to why they want it is irrelevant. Surely there have been times when you've said "no we're not going to implement that feature"?
Typically bug trackers are for tracking bugs; not having discussions about the direction of the project. In some open source projects feature requests in general are entirely off topic in the issue tracker (though I'm not sure if that's true for Gnome).
>Well-written written arguments from users and developers is considered spam?
Yes. The bug tracker is not a place to have an argument. The correct place for that would be a mailing list.
Yes. The bug tracker is not a place to have an argument. The correct place for that would be a mailing list.
File picking is a very important thing, I am sorry if is hard to implement but some pathetic workaround or some simplicity excuse is not working with many users.
> An example of how such a limited case can fuel beliefs of one desktop being "better" than the other
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?
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?
Welcome to Linux on the desktop, where every project has no money and no developers and is decades behind Windows and Mac. It's been like this the entire time I've been using Linux. But somehow, some people still manage to use it and get work done.
https://wiki.installgentoo.com/index.php?title=File_Picker_m... Will get you the content without the NSFW go away message.
I know it’s utterly distasteful, but I am fairly amused at the youthful rebellion of defacing a web page in this fashion. Feels very old Internet.
That has been hijacked too, this should work: https://archive.ph/Gq2hv
The lack of a thumbnail is hardly the most glaring flaw in gtkfilechooserwidget.c in Gtk3. Since 2013 (before this it was fine) the file chooser File->Open dialog no longer allows you to type in it or paste file paths into without first hitting a series of hot keys. It will literally throw an error if you paste a file path into the file chooser. This means every application that uses Gtk3 is broken on linux.
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.
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.
The page seems to have been vandalized, and it's currently showing an NSFW image.
EDIT: here's the old, non-vandalized version: https://wiki.installgentoo.com/index.php?title=File_Picker_m...
EDIT: here's the old, non-vandalized version: https://wiki.installgentoo.com/index.php?title=File_Picker_m...
That has been hijacked too, this should work: https://archive.ph/Gq2hv
I hopped off the GNOME train a few months ago, v40 was just too much, too fast, and will likely leave the ecosystem pretty broken for the considerable future.
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.
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.
>What concerns me is the hypocrisy of the modern GNOME team and how little they listen to the actual community using their DE.
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.
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.
Many in charge seem to employed by Red Hat. Really makes you go "Hmmm...".
Why? Red Hat employees are not different from any other volunteer.
@dang might want to remove this based on page edit. Submitting a link to a 4chan wiki was probably a silly idea :)
Or link to the version of the page before the edits: https://wiki.installgentoo.com/index.php?title=File_Picker_m...
That has been hijacked too, this should work: https://archive.ph/Gq2hv
https://archive.ph/Gq2hv maybe replace the link with this
[deleted]
This issue is almost never raised in good faith. Just look at this document. Disingenuous, trolling, contemptuous of the work of FLOSS developers. Then look at the comments in this thread, repeating and escalating the same nastiness.
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. :-)
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. :-)
>Then, consider the priorities of the people contributing to the GNOME and GTK projects
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.
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.
Votes in a bug tracker don't represent the priorities of developers or even a representative audience of users. Yes, it's a known issue, but there are trade-offs and a lot of work involved. Most people just aren't aware of the complexity involved in file chooser implementations and APIs.
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. That doesn't mean it's not real, it just means it's fodder for precisely the kind of document we're responding to.
>Votes in a bug tracker don't represent the priorities of ... a representative audience of users
>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.
>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.
>What are you basing this on?
>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.
>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.
Patches for it have been submitted but they were never merged. Some users even patch gtk themselves.
Can you please show me one of these merge requests that was submitted? If there is any chance of it getting merged, the patch should be against GTK4 master.
There have been various in https://bugzilla.gnome.org/show_bug.cgi?id=141154, first one in 2011 I believe. There are a few more not mentioned there, such as https://github.com/Dudemanguy/gtk and https://gist.github.com/ahodesuka/01213036b58e510dc074
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).
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).
Those are old and obsolete patches for GTK2 and GTK3 that to my knowledge were never submitted upstream, and currently it's too late to do that as GTK2 and 3 are not being developed anymore. If there is an open merge request for GTK4 that I am not aware of, please show it.
Everyone knows that a richer file chooser is a desirable, highly requested feature and has been for years. There's no question about that, and no one's being dismissive about that. Actually fixing it is a whole other matter.
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.
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.
They're trying to get you to substantiate your claim it's almost never raised in good faith. It's an extraordinary claim.
At least we don't have to see ads.
I’ll take good faith bugs and missing features over the pathological psycho warfare in closed software any day of the week.
I think that the point here is that this is anything but a "good faith bug".
How is that the point? GNOME is an understaffed and underfunded project.
Well why doesn't the GNOME project offer a way for people to pay for specific features and bugfixes? I would contribute money if I knew it would go towards paying someone to fix the file-chooser dialog. So would a lot of other people, if there was an announcement. I know for a fact I am not the only person who would do this:
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.
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.
In my opinion, that article is pretty insubstantial and is mostly just responding to the same 4chan trolling mentioned in this wiki. It's just not a productive line of discussion and doesn't make any sense in the actual context of how open source works. But I'll answer your question anyway.
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.
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.
>In my opinion, that article is pretty insubstantial and is mostly just responding to the same 4chan trolling mentioned in this wiki. It's just not a productive line of discussion and doesn't make any sense in the actual context of how open source works.
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
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
Sorry, I don't mean the article is trolling or bad-faith. What I mean is that the author seems to have been trolled and the article is only responding to that trolling. That's just my guess after seeing this 4chan wiki and after seeing some very hostile statements made about this over the years. The discourse is being driven by trolls. The questions asked here aren't "bad" per se but if there had been any communication with the real developers at all then I wouldn't expect anyone to ask these questions, they don't make any sense in context. It seems to me the only reason they're being asked is because trolls spread misinformation about the project. Please try to avoid falling into the same trap, I'm noticing that you're doing it and it's not helpful. Don't let the trolls win.
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'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.
GNOME's attitude isn't caused by them seeking to monetise their software or invigilate their users (e.g. "we say that we're not adding/changing this feature because X, but _really_ we're not doing so because it would prevent us from displaying ads/addicting our users"), but because they have a certain vision that they're stubbornly sticking to, so yes, it is a "good faith bug".
There is cool program for people like you, it is called Bonzibuddy. Proprietary software is guaranteed to be ethical and respectful of your privacy. In part, because the opaqueness creates an incentive for people to write better, more secure software.
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.
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.
I have never seen an ad in Windows, period. (And for that matter, I've never changed any setting to achieve that. Perhaps this is because as a Surface user, I get Win10 Pro installed by default?)
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.)
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.)
I see ads on Windows constantly, usually for Microsoft Edge and Bing, but every install always comes with a link to Candy Crush as far as I've seen.
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.
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.
> try using a pen or touch as a meaningfully usable interface
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.
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.
Yeah, they had ads for a mmo game or something on the lock screen of my Professional licensed machine and always ads for Candy Crush in the menu as well as trying to finally outcompete Google in scammy pushing of browser for the first time in a decade.
Steam Deck is for you perhaps
Back then at least there was some sense in trying to mimick Windows as closely as possible in a graphical environment to gain acceptance among Windows users who'd claim they can't get used to a new interface.
Starting with Windows 8 at the latest that argument was kind of silly :)
Starting with Windows 8 at the latest that argument was kind of silly :)
Even Serenity OS has a feature complete file picker. Embarrassing.
[deleted]
This is by far the biggest obstacle to mass adoption.
Poe's law strikes again: are you saying, sarcastically, "Yeah of course Gnome's filepicker is the biggest problem Linux has," or are you saying, seriously, "Yes, this attitude of 'We won't fix it because principle!' is the biggest problem the Linux community has"?
Honestly, it could be either one, and that's what makes this meme so interesting/fantastic/depressing.
Gnome's UI really does suck.
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.
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 don't see the problem, to be honest. I never really care about how many files are in a directory or how big that directory is when I'm in the "open file" dialog. I just want to find my file quickly.
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.
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.
No idea why this is downvoted, its spot on.
Related discussion from earlier this year
https://news.ycombinator.com/item?id=25719796
https://news.ycombinator.com/item?id=25719796
What's really important is that the elements of the dialog box all move around every few fears, so no one can get too familiar with it and expect to understand what they see at a glance.
The presence of text box in which any text entered does something totally unexpected is at least universal.
The presence of text box in which any text entered does something totally unexpected is at least universal.
Absolutely agree about the bizarre textbox that pops up if I accidentally press a key while the filename box isn't selected... what on Earth is it supposed to be doing? Does anyone want that feature, someone who thinks, "Yes, when I hit a key in a Save dialog, I'd like to have a strangely filtered list of the files that are there already!?"
You may have heard the rumour that GTK/GNOME developers make software for simpleton users that don't exist. But you've just run into a power user feature that you don't understand.
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. :-)
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. :-)
People were actually annoyed when they replaced the normal search with the new recursive one, so I doubt it.
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.