5 ms·

Gnome turns 25...still no image preview in the filepicker

by dtx1 4y ago

ginko 4y ago
And people that try to provide workarounds will get called 'clowns' and sabotaged by the GTK people: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829
- jeroenhd 4y ago
  I love using Gnome but I hate the Gnome developer mindset. Everybody but them is an incompetent fool because they dare use their precious code in a different way. Every time one of these issues come up I consider just switching to KDE because although the UI doesn't sit as right with me, the developers and culture around the KDE project just seem so much better.
- kuschku 4y ago
  If users have to use debug flags because your software has no customizability whatsoever, the fault isn't with the users using those flags, the fault is with the developer not offering proper solutions. WTF Gnome, why do you hate your own users so much
  - ducktective 4y ago
    Actually the fault is with the users who still put up with random philosophies of certain app developers. It's a free world. Move on to something else. Recommend i3wm with Xfce apps.
    - jraph 4y ago
      The GTK file picker is practically unavoidable. It's in important applications like Inkscape, Gimp and was unavoidable with electron apps too until recently. Moreover, most users don't actually follow the discussions with the developers. They would not know about their philosophy. Also, this is not the only criterion when choosing software. And given how Gnome and GTK are (still) everywhere, I'd find it worth having this kind of things fixed even if I don't/didn't personally use the thing. I don't think blaming the users is a solution.
      - Crysstalis 4y ago
        The closest thing to a solution is to blame the distros for shipping the apps incorrectly and encouraging users to do unsupported things like combining several apps from several different desktops together without testing them, when this has never really been a thing that ever worked correctly. The correct way to get portal support is to use the flatpak versions of those packages, because those are the only packages that have actually been designed and tested to work with the portal. And if you are a person who really does not like flatpak, then you should ask your distro to start integrating sandboxing and portals into their own package managers and testing/supporting the packages that way.
        ginko 4y ago
        Flatpak? Are you serious?
        Crysstalis 4y ago
        I am not sure what you are asking, other than asking for me to repeat myself. I gave the reason why Flatpak is the only option here.
        ducktective 4y ago
        The Correct Way™ is actually NixOS/GuiX these days. I had major issues when I used Snap GUI apps. Like it was not clear where did the config file saved to or sometimes the file picker couldn't even detect my drives (due to sandboxing). It was doing its own thing regarding theming. If Flatpak is anything like this, then it's not a viable solution.
        neurostimulant 4y ago
        > sometimes the file picker couldn't even detect my drives (due to sandboxing) At least you can use `flatpak override` command to whitelist access to certain path.
        Crysstalis 4y ago
  - Crysstalis 4y ago
    The environment variable was disabled because of a bug report on reddit that it was causing other issues: https://www.reddit.com/r/gnome/comments/vhij0o/gtk_use_portal1_environment_variable_causes_gnome/ https://www.reddit.com/r/gnome/comments/vhij0o/gtk_use_porta... In this case, the arch wiki was actively telling users to do things that could break their system. It was a debug flag that was only intended to be used by developers and causes a number of other side effects. So it is no surprise that they changed it. Technically it was not removed, it was only moved into a flag that is only available in debug builds.
    - kuschku 4y ago
      So why don't they add a proper flag? I'm now running debug builds of gnome to get that functionality back. I wish everyone would abandone GTK and instead switch to Qt, but as long as that hasn't happened yet, I'll have to use such environment variables to get GTK apps to look and work consistently on a Qt desktop.
      - Crysstalis 4y ago
        The short answer is because any flag will break other things. There is another suggestion to not require any flag, but it probably will not be implemented because of this: https://gitlab.gnome.org/GNOME/gtk/-/issues/5026 https://gitlab.gnome.org/GNOME/gtk/-/issues/5026 It is not possible in open source to force everyone to use one toolkit, in my opinion you are wasting your time by wishing for that. There are dozens of toolkits to choose from and the number seems to be growing. The fragmentation has only gotten stronger over the last 25 years, if Qt was the clear winner the proliferation would have stopped long ago. Now there is pretty much no chance that you will be able to hack every toolkit to get all of them to look and work consistently. In particular, the way an app works is decided by the HIG it follows, not the theme. This is reflected in the entire design of the app, to change it requires redesigning the whole app. It cannot be changed just by setting some environment variables.
        kuschku 4y ago
        It’s mostly an issue with games or java apps or electron using Gtk dialogs. Those apps don’t feel native anyway, but the areas where they interact with the OS at least should feel native. I don’t care about Gtk apps themselves, because I just don’t use any proper Gtk apps (I want my apps to be customizable, after all, and I build my own programs to be customizable too). Why is it always Gnome developers and fans who hate any attempt to make Gnome apps look and feel more like other toolkits? No one expects Gnome apps to work 1:1 like Qt apps, but it feels like every step in the right direction is met with constant hate and objections.

Gnome turns 25...still no image preview in the filepicker

by dtx1 4y ago

Gnome turns 25...still no image preview in the filepicker

And people that try to provide workarounds will get called 'clowns' and sabotaged by the GTK people: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829

jeroenhd 4y ago
I love using Gnome but I hate the Gnome developer mindset. Everybody but them is an incompetent fool because they dare use their precious code in a different way. Every time one of these issues come up I consider just switching to KDE because although the UI doesn't sit as right with me, the developers and culture around the KDE project just seem so much better.
kuschku 4y ago
If users have to use debug flags because your software has no customizability whatsoever, the fault isn't with the users using those flags, the fault is with the developer not offering proper solutions. WTF Gnome, why do you hate your own users so much
- ducktective 4y ago
  Actually the fault is with the users who still put up with random philosophies of certain app developers. It's a free world. Move on to something else. Recommend i3wm with Xfce apps.
  - jraph 4y ago
    The GTK file picker is practically unavoidable. It's in important applications like Inkscape, Gimp and was unavoidable with electron apps too until recently. Moreover, most users don't actually follow the discussions with the developers. They would not know about their philosophy. Also, this is not the only criterion when choosing software. And given how Gnome and GTK are (still) everywhere, I'd find it worth having this kind of things fixed even if I don't/didn't personally use the thing. I don't think blaming the users is a solution.
    - Crysstalis 4y ago
      The closest thing to a solution is to blame the distros for shipping the apps incorrectly and encouraging users to do unsupported things like combining several apps from several different desktops together without testing them, when this has never really been a thing that ever worked correctly. The correct way to get portal support is to use the flatpak versions of those packages, because those are the only packages that have actually been designed and tested to work with the portal. And if you are a person who really does not like flatpak, then you should ask your distro to start integrating sandboxing and portals into their own package managers and testing/supporting the packages that way.
      - ginko 4y ago
        Flatpak? Are you serious?
        Crysstalis 4y ago
        I am not sure what you are asking, other than asking for me to repeat myself. I gave the reason why Flatpak is the only option here.
      - ducktective 4y ago
        The Correct Way™ is actually NixOS/GuiX these days. I had major issues when I used Snap GUI apps. Like it was not clear where did the config file saved to or sometimes the file picker couldn't even detect my drives (due to sandboxing). It was doing its own thing regarding theming. If Flatpak is anything like this, then it's not a viable solution.
        neurostimulant 4y ago
        > sometimes the file picker couldn't even detect my drives (due to sandboxing) At least you can use `flatpak override` command to whitelist access to certain path.
        Crysstalis 4y ago
- Crysstalis 4y ago
  The environment variable was disabled because of a bug report on reddit that it was causing other issues: https://www.reddit.com/r/gnome/comments/vhij0o/gtk_use_portal1_environment_variable_causes_gnome/ https://www.reddit.com/r/gnome/comments/vhij0o/gtk_use_porta... In this case, the arch wiki was actively telling users to do things that could break their system. It was a debug flag that was only intended to be used by developers and causes a number of other side effects. So it is no surprise that they changed it. Technically it was not removed, it was only moved into a flag that is only available in debug builds.
  - kuschku 4y ago
    So why don't they add a proper flag? I'm now running debug builds of gnome to get that functionality back. I wish everyone would abandone GTK and instead switch to Qt, but as long as that hasn't happened yet, I'll have to use such environment variables to get GTK apps to look and work consistently on a Qt desktop.
    - Crysstalis 4y ago
      The short answer is because any flag will break other things. There is another suggestion to not require any flag, but it probably will not be implemented because of this: https://gitlab.gnome.org/GNOME/gtk/-/issues/5026 https://gitlab.gnome.org/GNOME/gtk/-/issues/5026 It is not possible in open source to force everyone to use one toolkit, in my opinion you are wasting your time by wishing for that. There are dozens of toolkits to choose from and the number seems to be growing. The fragmentation has only gotten stronger over the last 25 years, if Qt was the clear winner the proliferation would have stopped long ago. Now there is pretty much no chance that you will be able to hack every toolkit to get all of them to look and work consistently. In particular, the way an app works is decided by the HIG it follows, not the theme. This is reflected in the entire design of the app, to change it requires redesigning the whole app. It cannot be changed just by setting some environment variables.
      - kuschku 4y ago
        It’s mostly an issue with games or java apps or electron using Gtk dialogs. Those apps don’t feel native anyway, but the areas where they interact with the OS at least should feel native. I don’t care about Gtk apps themselves, because I just don’t use any proper Gtk apps (I want my apps to be customizable, after all, and I build my own programs to be customizable too). Why is it always Gnome developers and fans who hate any attempt to make Gnome apps look and feel more like other toolkits? No one expects Gnome apps to work 1:1 like Qt apps, but it feels like every step in the right direction is met with constant hate and objections.