Live data from Hacker News

Gnome 40

forty.gnome.org

191–200 of 244 posts

Re: Gnome 40

#191

Earlier quoted context omitted.

This is a dead meme. Boring and annoying specially to the Gnome developers. I have used Gnome for many years now. Never have this been an issue. If you look at the issue tracker[1], they are open to pull requests to add the thumbnail, we just need one person who cares about this feature! There are many other issues with Gnome that actually is their decision and it is a problem. This specific one is a GTK issue. But f…

Various patches have existed for at least a decade but every time they're proposed some issue is found and they're not merged so the goal posts shift from 'just write your own patch' to 'just become a Gnome maintainer' with no guarantees that you'll get the assistance you need to implement the feature or whether it'll even be merged, and fair enough, the Gnome team really don't owe anybody anything, but in that case…

Maintainer refuses to merge bad work, shame on them?

Re: Gnome 40

#192

Earlier quoted context omitted.

I've lurked on HN for more than a decade but created an account to concur with this comment. Accidentally filtering for folders (who even wants this) instead of typing a filename is truly awful and affects me daily. I would bail on gnome for this issue alone if I didn't have to use it on a work machine. Does anyone know of an issue in their tracker with an official stance on it?

>I would bail on gnome for this issue alone if I didn't have to use it on a work machine. Both Google Chrome and Firefox use GTK's file picker (at least when "saving link as..." at least on Fedora 34 Prerelease) so what would you do for a web browser?

>what would you do for a web browser?

If your environment has a xdg portal port (KDE does), you can use the relevant portal. Set GTK_USE_PORTAL=1 , and then firefox uses the native file picker.

Re: Gnome 40

#193
post #32

Have they fixed the file chooser yet? Specifically, I want to be able to click around on directories to choose where to save a file, type the file name, then press enter. This should save the file, not filter the directory listing. Also, I don’t want it to default to overwriting some file I saved last week.

I've lurked on HN for more than a decade but created an account to concur with this comment. Accidentally filtering for folders (who even wants this) instead of typing a filename is truly awful and affects me daily. I would bail on gnome for this issue alone if I didn't have to use it on a work machine. Does anyone know of an issue in their tracker with an official stance on it?

[deleted]

Re: Gnome 40

#194

Earlier quoted context omitted.

I'm not trying to argue, I'm surprised and legitimately interested at your comment and would really like to understand where you're coming from. Are you a current Linux desktop user? How long have you been? What distros do you use? If Gnome had just paused or become what MATE is today, would we be better off? If you were suddenly emperor of the Gnome Foundation, what would you direct them to do?

I’ve been using Linux on the desktop since Mandrake 7. I mostly use Debian these days (ever since Ubuntu switched from Gnome 2 to Unity). For a while I just used tiling window managers (xmonad, stumpwm) because I couldn’t make Gnome 3+ work for me. Recently I tried Plasma again and I’ve mostly settled on that being good enough. At this point, I have no confidence in most of the people involved in the Linux desktop in…

Glad to see another person here aware of Trinity. I'm an active user. KDE3 just nailed the balance of power user + FOSS. Kmail3, Kdiff3, Kpdf, all these tools work wonderfully, intergrate well with Konqueror, the desktop usage is really quite enjoyable

Re: Gnome 40

#195
post #82

Earlier quoted context omitted.

Gtk4 already happened. Not sure if Gnome apps to it, however, but I'm pretty sure they'll just break extensions as they've always done. Most use internal APIs AFAIK after all, so they're designed to break.

Gnome shell doesn’t even use Gtk, or at least not for drawing and such. If it’s there, it’s completely abstracted away in their JavaScript layer. And yeah, most extensions broke from 3.38-40 already anyway.

I'm almost sure they do use it, through GJS. And those are the official JS bindings to Gtk.

And they definitely did break from 3.0 to 4.0 as I experienced by simply trying to get a sample application from the docs running, and failed to.

Re: Gnome 40

#196

Earlier quoted context omitted.

And when Gtk4 inevitably happens, or the gnome-shell toolkit is changed again, breaking about all the gnome-shell extensions, we'll just call it Gnome X.

Gtk4 already happened. Not sure if Gnome apps to it, however, but I'm pretty sure they'll just break extensions as they've always done. Most use internal APIs AFAIK after all, so they're designed to break.

Up-top-date Fedora Rawhide shows:

dnf repoquery --whatdepends gtk4-0:4.1.2-1.fc35.x86_64

breeze-gtk-gtk4-0:5.21.3-1.fc35.noarch fcitx5-gtk4-0:5.0.4-1.fc35.x86_64 gnome-chess-0:40~alpha-1.fc35.x86_64 gnome-extensions-app-0:40.0~rc-1.fc35.x86_64 gnome-shell-0:40.0-1.fc35.x86_64 gtk4-devel-0:4.1.2-1.fc35.x86_64 ibus-gtk4-0:1.5.24-3.fc35.x86_64

dnf repoquery --whatdepends gtk3-0:3.24.27-1.fc35.x86_64

... everything else (100's of packages)

Software/package version numbers are just a marketing name. It's the ABI version number on the library (e.g. libgtk4.so.1 vs libgtk4.so.0) that needs to be changed if functions or parameters to functions in the original ABI in the older libgtk4.so.0 library are modified or deleted. It's very common to have two libraries of the same name being used side-by-side with some applications compiled against a newer ABI, and other applications compiled against an older ABI.

The problem with Gnome development is that library ABIs are just one of many interfaces used. There are also GSettings/dconf interfaces, D-Bus interfaces, file formats, etc on top of the usual conflicts in package dependencies (e.g. two packages wanting to write two different unversioned files to disk).

Re: Gnome 40

#197
post #85

Earlier quoted context omitted.

No. I actually went to GNOME's IRC network the other day to talk to them about gtkfilechooser's multiple problems. Yours, and then the lack of text input for typing or pasting file paths. https://gitlab.gnome.org/GNOME/gtk/-/issues/938 . They said they have no one assigned to gtkfilechooser bugs and none will be addressed. I was able to download the debian source for a couple gtk applications (ie, gedit/pluma) and ap…

the main text entry ("Name", the one that starts out focused) lets you type/paste paths.

It loses focus once you switch directories. Restoring focus to the default state involves selecting the filename, but not the extension.

Re: Gnome 40

#198
post #187
post #131

Earlier quoted context omitted.

Clearly this isn't an issue that people care about enough to do anything about, otherwise someone would have gone and implemented it.

There are several submitted patches that add this functionality on the bug report but Gnome developers have not merged them. https://bugzilla.gnome.org/show_bug.cgi?id=141154&

Maybe they were just trying to get a stable 40.0 and will add in 40.1 ?

Re: Gnome 40

#199

Earlier quoted context omitted.

Various patches have existed for at least a decade but every time they're proposed some issue is found and they're not merged so the goal posts shift from 'just write your own patch' to 'just become a Gnome maintainer' with no guarantees that you'll get the assistance you need to implement the feature or whether it'll even be merged, and fair enough, the Gnome team really don't owe anybody anything, but in that case…

Maintainer refuses to merge bad work, shame on them?

If it was really bad work, then of course not.

The problem is that poor quality isn't the reason why they refuse. While not related to the file picker, I personally offered to port an important part of GTK3 to GTK4 (status icon support) and one of the maintainers told me flat out that he would not merge my work because "it was no longer in line with the direction GNOME is heading".

I suspect the real reason behind their refusal is purely subjective, unfortunately.

Re: Gnome 40

#200
post #88

Earlier quoted context omitted.

No. I actually went to GNOME's IRC network the other day to talk to them about gtkfilechooser's multiple problems. Yours, and then the lack of text input for typing or pasting file paths. https://gitlab.gnome.org/GNOME/gtk/-/issues/938 . They said they have no one assigned to gtkfilechooser bugs and none will be addressed. I was able to download the debian source for a couple gtk applications (ie, gedit/pluma) and ap…

I'm glad to hear putting hamburger menus in all the window title bars is prioritized over having a functioning UI.

This has been going on for a long time now and is to be expected. My real problem is that they completely remove existing functionality from UI without giving the users who relied on it any alternative.
Post reply on HN