[HN Gopher] Gnome has no thumbnails in the file picker and my to...
___________________________________________________________________
Gnome has no thumbnails in the file picker and my toilets are
blocked (2021)
Author : weberer
Score : 327 points
Date : 2022-06-17 14:13 UTC (8 hours ago)
(HTM) web link (jayfax.neocities.org)
(TXT) w3m dump (jayfax.neocities.org)
| marcodiego wrote:
| In case anyone is interested:
| https://gitlab.gnome.org/GNOME/gtk/-/issues/233
| bityard wrote:
| This was reported before some HNers were even born.
| honkler wrote:
| stick a note onto the commode or the toilet door that reminds
| your family members of the fact.
| binbag wrote:
| Dude, please, please get your drains fixed. It's bothering me
| now.
| onionisafruit wrote:
| I finished the article unclear whether or not the toilet story
| is a parable.
| marktangotango wrote:
| Wow, I just read a rant on a site that hosts static websites,
| damn I miss that! Sounds like this person needs to snake his
| sewer line.
| jrm4 wrote:
| Here is the _ultimate_ problem with GNOME. It is essentially a
| lie.
|
| What I mean: Imagine you bought a ticket for Matrix 4, and they
| showed John Wick.
|
| That's what GNOME 3 did. They made a new and different product;
| whether you like it more or less than the last one isn't the
| point. They betrayed the reliance we had on the old thing by a
| "lie of omission." A more honest approach would have been to name
| Gnome 3 something different (and perhaps hand the Gnome name off
| to the MATE people?)
| mr_beans wrote:
| Except John Wick has been better than all the Matrix movies but
| the first
| jrm4 wrote:
| That actually doesn't contradict my point. It's fine if you
| like it better, the problem is _pretending it 's the same
| thing._
| vladcodes wrote:
| Is that a blog of someone from Trolltech? Tell them their site
| doesn't support OS-managed dark theme switching.
|
| -- No, using custom CSS isn't "dark mode"
| smoldesu wrote:
| > No, using custom CSS isn't "dark mode"
|
| I mean, in this case, it _literally is_ as easy as adding an
| alternate CSS style and then managing the proper dark-mode
| switching.
|
| ...not that this is really a concern in the first place. If you
| read through someone 's blog and the best comment you have is
| on their website's OS integration, I think you've got your
| priorities misaligned.
| vladcodes wrote:
| Easy is a comparative evaluation.
|
| To someone it's easy to recompile Nautilus with one of the
| thumbnails support patches or implement thumbnails generation
| via an external script.
|
| Literally.
| shadowgovt wrote:
| > First of all, how do developers so casually ignore this issue?
|
| GNOME has never struck me as a project interested in
| implementating polish work. Polish work is disproportionately
| hard (it sometimes upends your understanding of the problem,
| forcing you to rethink your core structures, which impacts other
| features. In short, polish work has a tendency to explode).
|
| > Second of all, how do users so casually ignore this issue?
|
| GNOME users are accustom to polish not being the priority of the
| developers. Those who couldn't take it stopped using GNOME.
| jklinger410 wrote:
| Yet GNOME is the most polished Linux Desktop Environment.
| int_19h wrote:
| It's easy to polish something that doesn't have many visible
| parts.
| whywhywhywhy wrote:
| Thumbnails are not polish. They're an essential feature of
| working with images.
| shadowgovt wrote:
| The devil's advocate response is "How essential could they
| be? We went decades without 'em."
|
| I don't think it's the _right_ answer, but it 's an answer
| that works (GNOME continues to be the dominant Linux desktop
| environment in spite of lacking that feature).
| [deleted]
| jasonlotito wrote:
| Completely realizing you aren't actually making the
| "devil's advocate response," but I think the response to
| that is "We went for a millennia without electricity, too."
|
| Just because we went without something, doesn't mean we
| should accept life without it at this point.
| TillE wrote:
| GNOME has enjoyed the status of being basically usable, if
| not particularly good, throughout its history.
|
| I still remember KDE going through what felt like years of
| being unusably broken during its clumsy transition from 3
| to 4. That's a lot of the desktop Linux experience, really
| - everything constantly in flux, never quite usable. I
| don't blame anyone for this, it's hard to get stuff done
| without someone paying a team to do it, but it's really
| unfortunate.
| doubled112 wrote:
| After flip flopping a bunch, I ditched both GNOME and KDE
| for Xfce and haven't felt like I've missed much. It might
| need some better defaults, but you only have to fix them
| once on a new install.
|
| Nothing huge changes, and really, I'm not looking for
| much. A launcher. A way to switch windows. Volume and
| brightness buttons/applets are nice to have. A system
| tray.
|
| I've heard somebody somewhere along the lines call it the
| "Debian of DEs" and I can't argue with that.
| bombcar wrote:
| If Apple or Microsoft had something like this "misfeature" in
| their OS, they could and likely would lose sales.
|
| GNOME has no customers and can't lose sales, therefore they
| don't have to care at all.
| lelanthran wrote:
| > If Apple or Microsoft had something like this "misfeature"
| in their OS, they could and likely would lose sales.
|
| I disagree. Microsoft and Apple[1] had both had immense
| blunders that users hated, yet those users still paid money
| for the blunders.
|
| At least with Gnome, people switched.
|
| [1] I've used almost all the Window Managers and Desktop
| environments since 1995, I've used Windows since 1995. The
| current apple GUI is more painful to figure out than I had
| expected when I started using it last year. It's easily one
| of the least intuitive environments that I've come across,
| and watching non-tech users struggle with it reinforces my
| point.
| bombcar wrote:
| Sure - not everyone will stop using it, but some will, and
| that's lost sales. Even if it can't be quantified, the
| concept can be "sold" to some executive and get the problem
| fixed.
| gh02t wrote:
| I mean, GNOME is the default on several commercially
| supported distributions. Redhat is the largest contributor.
| Granted, a lot of those commercially supported distributions
| are for customers who don't care about GUI uses but Ubuntu
| and RHEL/Fedora have a decent number of workstation users.
| KDE/Plasma have much less commercial support (AFAIK) and are
| probably closer to what you're saying, but at least to my
| tastes manage to be much more sensible.
| bombcar wrote:
| But does anyone _buy_ those - the very term "commercially
| supported" implies it's being marketed toward companies
| (think: enterprise) and everyone knows enterprise software
| is the most user-friendly ever invented (oh wait, the users
| are the purchasers).
| toyg wrote:
| _> GNOME users are accustom to polish not being the priority of
| the developers._
|
| Wasn't the whole spiel of Gnome 3 that it was all about "UIXP"
| and perfection on defaults, sacrificing power-user
| functionality if necessary? That's effectively all about
| interfaces that do very little, but do it very well - i.e. they
| are super-polished, if less featureful.
|
| It is true, though, that a lot of people stopped using GNOME.
| In fact, despite Ubuntu and RedHat effectively pumping users
| into the ecosystem for years, most Linux folks I know use
| either KDE or boutique DEs.
| shadowgovt wrote:
| I don't know enough about GNOME's history, but I wonder if
| the people making those promises fell into the trap of
| believing that a more polished desktop environment would be
| one with cleaner code, and when they said super-polished they
| meant clean abstractions.
|
| A super-polished UI (in the sense of "well-rounded, meets
| expectations, minimizes user surprise, behaves predictably")
| has messy abstractions because humans are messy. I've never
| met one that looked good on the outside and didn't have ugly
| snaggy bits on the inside to get all that good-lookingness to
| actually work in the corner cases. Perhaps GNOME has fallen
| into the trap of sacrificing features for purity of form. If
| they're saying things like "We'll have thumbnails when
| someone can figure out how to do it cleanly" they've fallen
| into that trap.
| robonerd wrote:
| > _sacrificing power-user functionality if necessary?_
|
| Scratch "if necessary". Power users have privilege, so
| deliberately throwing them curveballs for the sake of
| equitable outcomes seems to be the GNOME way.
| bityard wrote:
| I want to downvote this for being outrageously cynical and
| mean-spirited, but also I'm afraid it could actually be
| true
| hedora wrote:
| I suggest searching for JWZ CADT for a 19 year old article
| describing the same class of problems with Gnome.
|
| My pet peeve: "<ctrl>-s filename <enter>" does something horrible
| instead of writing to filename.extension.
| ducktective wrote:
| At this point, it has become evident that they don't "want" to
| support this feature. So you're limited to what KDE has to offer
| if you need this.
|
| Personally, I've bailed on the whole DE thing. Take the tiling-
| wm-pill and move on. Now I have to deal with tumblerd random
| high-cpu usages and thunar's unexpected crashes.
| bityard wrote:
| > Take the tiling-wm-pill and move on.
|
| But that doesn't really solve the issue with the file picker...
| calvinmorrison wrote:
| I'm beyond grateful the Qt is not engineered by KDE.
|
| I am now running a hybrid setup with KDE + i3. It works really
| well because I get to have all my network settings, display
| settings, etc on the fly, I can use konqueror, and i still get
| i3 nicely.
| hallarempt wrote:
| Except... It is. There are a lot of contributions by KDE
| volunteers to Qt.
| synu wrote:
| Maybe you've tried it, but Xfce as DE plus i3 is for me the
| dream team.
| nobleach wrote:
| I've done this. First I did pure BSPWM, then pure i3.
| Frankly, it's just too light for me. I spent so much time
| having to handle all these one-off scenarios like, hot-
| plugging multiple monitors, bluetooth, audio volume (with
| switching output when I plug into my big monitor). I had
| cobbled together so many scripts and I was constantly
| fighting with something that had worked the prior day. Having
| an actual environment under the hood made it much nicer.
| bstar77 wrote:
| I've not seen anyone using a tiling window manage with 32" and
| larger 4k displays. It's just an awful experience.
|
| I would use a tiling window manager (and have) on something
| like a chromebook or if I'm a youtuber that does everything in
| a VM at 1080p. I have a hybrid approach that I use with XFCE
| (aggressive window snapping with custom shortcuts), but it's
| hardly a typical tiling window manager experience.
|
| Regarding Thunar, I don't have any issues, but if you are not
| using it in XFCE, you might want to try and see what plugins
| you are loading. Some expect XFCE and could be the root of your
| issues.
| tlamponi wrote:
| > I've not seen anyone using a tiling window manage with 32"
| and larger 4k displays. It's just an awful experience.
|
| I'm using i3 / sway on both, my Workstation's 40" 21:9
| (5120x2160) and my private 32" 16:9 4K displays, and see no
| reason why a bigger display, or one with a higher DPI, would
| make using a tiling window manager working worse, on the
| contrary, for me, it's all the more important to have good
| management if I got more "screen estate" to handle.
|
| IME using tiling WMs on bigger/HiDPI screens is a fantastic
| experience.
| colinsane wrote:
| i'm also enjoying sway specifically on large displays. 34"
| ultrawide (21:9) 3440x1440. i had gnome running on it for a
| while but i specifically switched to sway _because_ it's
| easier to make use of the ridiculous real-estate. i can
| have like 4 separate vertical splits before it gets
| cramped. no one wants to manually position 4 windows on a
| screen.
|
| i also run sway on my 14" laptop simply because i share my
| OS config between the two machines. i like its workspaces
| and notifications and being able to tweak `waybar` exactly
| how i want it, but the actual tiling functionality is
| pretty useless. at _most_ i'll do two panes per workspace
| -- at which point you're in territory any DWM would do well
| in.
| tomtheelder wrote:
| > I've not seen anyone using a tiling window manage with 32"
| and larger 4k displays. It's just an awful experience.
|
| I do this. How is it a bad experience? If anything I get more
| mileage out of my tiling WM on my large screen than I do on
| my laptop, where I tend to just use a lot of full screen apps
| and change tag/workspace a lot.
| z0r wrote:
| I don't (because I have 3 24" displays), but at least two of
| my coworkers have 32" and larger 4k displays and use i3
| kitsunesoba wrote:
| I've never been able to make tiling work for me regardless of
| screen size. Windows constantly end up being awkward sizes
| that cause scrolling that would be unnecessary in a floating
| WM, and I'm constantly tweaking window sizes to try to make
| it less awkward. It's very micromanage-y, and it drives me
| nuts.
|
| But I don't live in a terminal and/or text editor -- my most
| frequently used programs are IDEs, VCS UIs, and graphics
| editors... stuff with lots of panes and palettes and such.
| Simpler apps get use too, but it's skewed enough that popping
| some apps into floating mode in a tiling WM isn't enough. My
| ideal environment is floating-first with light optional
| tiling, like macOS with something like Moom installed.
| mayama wrote:
| You could do floating for all windows or for specific app
| in sway, that I'm using now, with for_window directive.
| kitsunesoba wrote:
| I could probably make it work, but I'm not fond of the
| ultra-minimal window chrome that's standard with tiling-
| first WMs. Much prefer more traditional mouse-centric
| window chrome with fancy styling like that of GNOME,
| XFCE, macOS, etc.
| smoldesu wrote:
| Yep, most tiling WMs come with _really_ solid floating
| window options. i3wm with floating windows by default is
| such a treat!
| ubercow13 wrote:
| Something like i3 would work great on a monitor like that.
| Something like dwm maybe less so.
| mayama wrote:
| I've had some weird issues with thunar too. Currently using
| spacefm after trying several options.
| amlib wrote:
| Meh, I'm so disilluded that I've resorted to using nautilus as
| my file picker and just drag 'n dropping files from it into the
| program I want to open the file with.
| dark-star wrote:
| Switched to KDE because of stupid crap like that. Never ever
| looked back
|
| My advice: download a live-system with a KDE desktop and give it
| a spin, maybe?
| clircle wrote:
| Can anyone explain why this bug has gone so long without a fix?
| Is it technically challenging to fix, or does the Gnome team
| disagree that thumbnails are necessary?
| spookthesunset wrote:
| I read over the ticket[0] and from what I could see it was
| mostly bickering about the format of the patch or something. I
| didn't really see any "ba humbug, command line is all you need"
| kinds of posts from some graybeard.
|
| So in short it looks more like an organizational problem than a
| technical or even political problem.
|
| [0] https://gitlab.gnome.org/GNOME/gtk/-/issues/233
| DonHopkins wrote:
| More like a disorganizational problem.
|
| https://en.wikipedia.org/wiki/Conway%27s_law
|
| >Conway's law is an adage that states organizations design
| systems that mirror their own communication structure. It is
| named after the computer programmer Melvin Conway, who
| introduced the idea in 1967. His original wording was:
|
| >Any organization that designs a system (defined broadly)
| will produce a design whose structure is a copy of the
| organization's communication structure.
|
| >-- Melvin E. Conway
|
| In Gnome's case, the structure of its design is a copy of its
| disorganized communication structure.
| aliswe wrote:
| the sad situation of desktop Linux is kind of reminiscent of
| democracy and how people work in general.
| Ruq wrote:
| This comment might come off a little off-topic but I think it's
| pretty related.
|
| The Gnome Project has always struck me of having this Apple-Like
| attitude of "We know Best", and subsequently ignoring/shrugging
| off user concerns/issues/etc.
|
| It's pretty obvious that Gnome is at the very least "inspired" by
| macOS. Heck Apple started version bumping by whole numbers at
| right about the same time Gnome switched from 3.x to 4x.
|
| I use it on my Touchscreen Convertible Laptop (with Wayland),
| since it supports multi-touch gestures (on the touchpad too), and
| as long as I install extensions to bend Gnome to my will, it
| seems to work pretty darn well for me. (For example, adding
| window tiling with the https://github.com/Leleat/Tiling-Assistant
| extension).
|
| Perhaps there is a better way that I should switch too, but
| currently I remain ignorant.
| justsomeguy123 wrote:
| Gnome people basically looked as how Apple managed to be firm
| about design and though they can be even tougher since they do it
| for free.
|
| Such reasonable / obvious requests linger for decades and after a
| while the system has been rewritten and bugs are auto-closed.
|
| I no longer report any bugs nor care.
| _jal wrote:
| > I no longer report any bugs nor care.
|
| Past that point years back, kept going.
|
| I just don't use anything Gnome related, if I can help it. I
| have found some things that unfortunately use the toolkit and
| somehow manage to not be intentionally irritating, but I assume
| that's an oversight to be corrected once I'm dependent on it.
|
| Like is too short to use irritating software.
| Avamander wrote:
| I loathe all auto-closing so much, it's such a cheap way out of
| issue triage. The ostrich method of project management. It's a
| good red flag though, I know not to waste my time on the
| project. Who knows what major issues have been auto-ignored.
|
| It can be especially inane if the issues are also locked
| automatically, you're already ignoring the issue why the f
| can't you let people discuss workarounds or request reopen.
| cuteboy19 wrote:
| Firefox Android did that and I stopped contributing. It's not
| even that I hold a grudge, but the ostrich method is
| extremely frustrating to the reporters
| heretogetout wrote:
| I keep hoping someone will be gutsy enough to build and
| deploy a bumpbot (or bots!) to combat stalebot.
| OJFord wrote:
| I keep hoping it will simply gain a way to say 'I still
| care, this is still an issue, there's no new information to
| add, (nor asked for!) it's just not being prioritised so
| please leave it open'. Or infer that after a couple of
| stale removals.
|
| Sure they close a lot of junk from drive-by question askers
| which helps maintainers, but they piss off a lot of good
| citizens providing information on actual bugs/feature
| requests that are just waiting for attention too.
| heretogetout wrote:
| Combine that with the CLA plague and you have a recipe
| for nothing but corporate-backed open source
| contributions. Individuals need not apply.
| politician wrote:
| An undead open-source project.
| apozem wrote:
| This is the thing - if you're going to be like Apple and
| dictate design, you have to get it right. macOS and Apple
| hardware is not to everyone's taste, and they make mistakes,
| but they prototype and dogfood and iterate like crazy and they
| have thumbnails in the damn file picker.
|
| When you're picking a file, you can even tap space to get a
| blown-up preview of an image or PRF. I use this feature almost
| every time I need to pick an image.
| [deleted]
| Filligree wrote:
| > When you're picking a file, you can even tap space to get a
| blown-up preview of an image or PRF. I use this feature
| almost every time I need to pick an image.
|
| Wait, what? That would have been super useful, but how was I
| supposed to find out?
| apozem wrote:
| It's not indicated anywhere visually. I don't even remember
| how I found out about it.
|
| This is a downside of macOS and iOS design - lot of hidden
| gestures. For example, you can right-click the text title
| of a Finder window to open a quick navigation to all the
| parent folders of the current directory.
| skykooler wrote:
| Wait, what? I knew about the spacebar thing but this one
| is new to me.
| brigade wrote:
| https://support.apple.com/en-us/HT201236 or
| https://support.apple.com/guide/mac-help/view-and-edit-
| files... I guess?
|
| First one also mentions the [?]-click on a window's title
| jamesgeck0 wrote:
| This works in every Finder window; if there's a window with
| files you can use Quick Look. I'm not sure if it's
| documented anywhere anymore, but it's been around 15 years.
| bityard wrote:
| One thing I'll give Apple credit for is in the early days of
| OS X, they had (and perhaps still have, if it's the same
| thing) a document called Human Interface Guidelines. They
| actually did real experiments with real people and came up
| with a set of UI patterns that were proven by science to make
| software features and UI discoverable, usable, and clear,
| with the least amount of cognitive load.
|
| Things like, the buttons on a dialog should should be a verb
| indicating the _action_ the user wants to take. Like "Run
| This" and "Go Back" instead of "Yes" and "No". (Or worse, the
| old Windows "OK" and "Cancel", which is rife with ambiguity
| in so many cases.)
|
| And the tone of the document was that it was intended to be
| useful to _all_ user interface designers of all software and
| on all platforms, not just OS X. I just skimmed over the
| current edition and as far as I can tell, these days it's
| basically just about how to stay "on brand" with the Apple
| experience when writing your own UI.
| int_19h wrote:
| Windows also had a similar document. E.g. here's one for
| Win7:
|
| https://docs.microsoft.com/en-
| us/windows/win32/uxguide/guide...
|
| The problem is getting the app developers to actually
| follow them.
| gtirloni wrote:
| This 1000x. Apparently it's called being "opinionated"
| nowadays.
| dang wrote:
| Related:
|
| _GNOME has no thumbnails in the file picker and my toilets are
| blocked_ - https://news.ycombinator.com/item?id=25719796 - Jan
| 2021 (724 comments)
| capitainenemo wrote:
| Huh... I just opened Pluma in MATE and used the file opener, and
| it had image previews in the list view. I never really paid much
| attention to this though, so no idea if the MATE team added it or
| what.
|
| They are a bit smaller than I'd like though... let's see if
| there's a configuration option for that.
| lelanthran wrote:
| > Huh... I just opened Pluma in MATE and used the file opener,
| and it had image previews in the list view. I never really paid
| much attention to this though, so no idea if the MATE team
| added it or what.
|
| But, MATE isn't Gnome. That's almost their slogan, how could
| you not know?
| capitainenemo wrote:
| Heh. Well, it's a fork of Gnome2 which was their main selling
| point. I just can't remember if these previews existed in
| Gnome2 before the fork or not.
| aidenn0 wrote:
| Per TFA:
|
| > No, individual file previews aren't "thumbnails."
| bstar77 wrote:
| This is a weird hill to die on. I've never cared much about the
| file picker and the individual file preview is "good enough" to
| ensure you pick the correct file. Now if Nautilus didn't have
| image previews in "icon view", then that's cause for rioting in
| the streets.
| weberer wrote:
| That just tells me that you never upload images, or that your
| image folder is not particularly large. If trackpad drivers
| were broken, that would still be a pretty big issue, even
| though you personally always use a mouse.
| cowtools wrote:
| I upload files all the time and for some reason I don't
| encounter this problem in gnome. Just give the files
| appropriate names?
|
| Seems like a channer problem. It's not suprising that no one
| from /g/ has made a patch yet.
|
| Edit: Actually, I just checked and apparently it's because
| the file picker actually _does_ show thumbnail icons, just
| very small ones. For example,
| https://files.catbox.moe/h3s3c3.png
|
| I guess I can usually make out what the image is from the
| small thumbnail icons!
| MatmaRex wrote:
| Consider reading the linked post, the author includes
| screenshots identical to yours and explains that that is
| not what they mean.
| compiler-guy wrote:
| "Appropriate file names"?
|
| grand-canyon-001.jpg grand-canyon-002.jpg grand-
| canyon-003.jpg grand-canyon-004.jpg ... grand-
| canyon-991.jpg
|
| Or maybe
|
| grand-canyon-east.jpg grand-canyon-west.jpg grand-canyon-
| north.jpg grand-canyon-south.jpg ... grand-canyon-
| northeast.jpg
|
| Thumbnails solve real problems and other guis have had this
| as a completely solved problem since literally the mid-
| nineties.
| cowtools wrote:
| I rename files as I download them (or copy them from my
| phone/camera) or I just remember the file name that I
| downloaded. I suppose it's a problem if you _have_ to
| deal with many unnamed images, but if it really came down
| to that I would just open up nautilus.
| johnchristopher wrote:
| > but if it really came down to that I would just open up
| nautilus.
|
| So, the downstairs toilet.
| cowtools wrote:
| I use the downstairs toilet is for bulk shits, the
| upstairs toilet is for petite loads.
| cookie_monsta wrote:
| Haha, nice but I bet that's going to puzzle some people
| who haven't read TFA
| rddd_police wrote:
| jklinger410 wrote:
| There can't be a more classical linux/developer response
| to a serious UI issue than "I just do this other
| repetitive manual task to solve the problem, don't see
| what the big deal is."
| weberer wrote:
| >It's not suprising that no one from /g/ has made a patch
| yet.
|
| They did. Apparently the Gnome devs didn't want it. You can
| get it from the AUR.
|
| https://gist.github.com/Dudemanguy/c172394e30e1e7d0f477ad15
| c...
|
| https://aur.archlinux.org/packages/gtk3-patched-
| filechooser-...
| true_religion wrote:
| Thumbnails in your file picker are table stakes at this
| point.
|
| Everyone has a cell phone capable of holding thousands of
| images, most of which won't get an appropriate title.
|
| For example, I'm tiling a bathroom now. It was very easy to
| just take dozens pictures of tiles send them off for
| approval, and get the top five back for a further price
| check. That entire workflow was enabled by thumbnails. If
| we had to check the filename of each image we were sending,
| it would have slowed things down immensely.
| robonerd wrote:
| > _Seems like a channer problem._
|
| Whether you like 4chan or think anybody who goes there is
| the devil incarnate, using 4chan as your excuse for
| dismissing such basic functionality as thumbnails in a
| _file picker_ is deranged. Why not abolish file pickers
| entirely, since 4chan uses it? In fact lets ban drinking
| water too, I hear nazis like to drink it. Ban air too, we
| wouldn 't want anybody using it to say something hateful.
| Is there any insanity _" but 4chan exists!"_ can't be used
| to justify?
| cowtools wrote:
| I don't really have anything against channers. I'm just
| saying it's a problem that one small group
| disproportionately complains about but does little to
| fix. I think that is pretty indicative of /g/ discourse
| which revolves around baiting other users into flamewars.
| robonerd wrote:
| Every mainstream desktop has thumbnails in the file
| picker. People who want this aren't the odd ones, those
| who dismiss it are.
|
| > _I don 't really have anything against channers._
|
| I seriously doubt that, since you're the one who brought
| them up in an absurd attempt to deflect a common sense
| criticism of an obvious shortcoming.
| cowtools wrote:
| >People who want this aren't the odd ones, those who
| dismiss it are.
|
| fair enough.
|
| >I seriously doubt that, since you're the one who brought
| them up in an absurd attempt to deflect a common sense
| criticism of an obvious shortcoming.
|
| See my defense of channers in these threads:
| https://news.ycombinator.com/item?id=31554117
| https://news.ycombinator.com/item?id=31554152
| https://news.ycombinator.com/item?id=31554112
| imwillofficial wrote:
| Seeing the picture you want to upload is a channer problem?
|
| You guess you just use proper file names?
|
| This attitude is EXACTLY what the author is describing, and
| why Linux on the desktops fails to take hold.
| cowtools wrote:
| The problem is that channers complain, but do not do
| productive things like file PRs. So problems that matter
| to channers will remain unresolved.
|
| If you want something done right, do it yourself.
| Commercial software is no exception to that.
|
| >why Linux on the desktops fails to take hold.
|
| Linux fails to take hold because it doesn't come
| preinstalled on laptops, and because it doesn't have the
| critical market share to take over. Basically nothing to
| do with file pickers.
|
| The ideal use case is just using drag-and-drop behavior
| from the file manager, instead of implementing the file
| manager twice. The reality is that products like Windows
| have shaped people into thinking about the desktop in a
| certain way, and linux has limited leeway in reshaping
| those ideas (including their idiosyncrasies like file
| pickers).
| anonymousab wrote:
| People don't make PRs because they've seen how difficult
| it is to get anything done with the GNOME project. So
| often is there a fix pr or patch that satisfies the code
| style and standards, but gets rejected despite user
| demand because, well, the maintainers don't want that
| thing fixed or changed. Or they do, but they want to make
| some sort of point by rejecting a change at that time.
|
| GNOME is one of the weirder and more difficult projects
| for a stranger to contribute to if your change does not
| fit into a very narrow and specific set of current
| priorities (unknown to the outside contributor, so good
| luck!). It is another world-of-wontfix poster child
| projects and I don't begrudge anyone who doesn't want to
| go through the hassle compared to most other open source
| projects they can spend their time on.
|
| Eventually, you're left with just pointing out how
| ridiculous something is with GNOME and moving on. You're
| just not going to be able to get a fix merged regardless
| of merit, quality or tact. It isn't worth the pain.
| Zpalmtree wrote:
| There have been PRs made to fix this issue which have
| been rejected, because Gnome hate their users.
| imwillofficial wrote:
| It is obscenely ridiculous to say that people complaining
| about a missing usability feature that every other tool
| on the market has, marks somebody as a channer.
|
| As clearly stated in the article, there had been an open
| issue for almost a decade, and PRs rejected.
|
| When windows is beating you in usability, you have a
| serious problem.
| petepete wrote:
| You'd expect the file picker and nautilus to share behaviour
| though, right? Also for me, if I open the file picker from
| Chrome/Edge/an Electron app it's forced full screen and there's
| no preview on the right either.
|
| I love GNOME, use it on both desktop and laptop, but this is
| one of those things that's just bad.
| bstar77 wrote:
| I definitely agree that it's strange that Nautilus can do
| this and the file picker can't. I also agree that consistency
| is important, but this issue has never caused me problems so
| I don't think anything of it. There are other things in Gnome
| that are keeping me from using it after being a vocal
| supporter for decades.
| cowtools wrote:
| I think the difference is that GtkFilePicker is a part of
| the running GTK program, like firefox for example. If you
| wanted to get all of nautilus' features, you would have to
| embed all of nautilus into your program, including features
| that would be innapropriate fir a file picker
|
| Maybe instead of just using GtkFilePicker on linux, it
| should first check if there's an available "xdg-file-
| picker" in the environment, which gnome sets to nautilus
| with some flags to run it in file-picker mode.
| int_19h wrote:
| Embedding Nautilus doesn't mean enabling all its
| features.
|
| That said, I don't know if that's a problem, either.
| Windows does exactly that for its file picker - it's
| basically embedded Explorer, complete with context menu
| integration etc. And it works.
| imtringued wrote:
| I don't have image previews ;)
| superkuh wrote:
| The biggest problem with GNOME right now is Gtk3 and
| gtkfilechooserwidget.c. It is so spaghetti and so many things
| rely on it that no one at GNOME is willing to work on it for fear
| of breaking something. And for the same reason they won't accept
| drive-by patches. It is, effectively, frozen broken, and has been
| for many years. This applies to any attempt to add thumbnails to
| the file chooser but there are far worse, actual bugs, beyond the
| lack of thumbnails.
|
| As of right now if you File->Open in any program using modern
| Gtk3 and try to paste a file path in you'll get an error instead
| of pasting your filepath in a text field to open, "The folder
| contents could not be displayed\nOperation not supported"
| http://erewhon.superkuh.com/gtkfilechooserwidget-paste-fail....
|
| It's unfixable behavior because the GNOME devs stopped respecting
| their own gsettings, org.gtk.Settings.FileChooser location-mode,
| to _FORCE_ the path-bar experience on everyone. Because no one
| needs to type file paths, apparently. So why bother respecting
| the settings for path-bar or filename-entry? Their demographic
| doesn 't care. Unfortunately gtk3 is used by far more than
| GNOME's demographic.
|
| They have fixed this bug in gtk4, for all the good that does.
| easytiger wrote:
| Suspect one of the impetuses behind such stagnation is that in
| reality not that many Linux users use GUIs to do file stuff as
| so many of us live in the command line.
| phkahler wrote:
| >> Suspect one of the impetuses behind such stagnation is
| that in reality not that many Linux users use GUIs to do file
| stuff as so many of us live in the command line.
|
| GTK is a GUI toolkit. It is literally made for building GUI
| applications. The Gnome developers are building a graphical
| DE. Your reasoning doesn't seem to sensible to me.
| llllllllllll9 wrote:
| the impetuses are shrouded in mystery, what with the
| metaphorical GTK+, and the whatever it is the gnomers are
| doing over there. a graphical DE it is not, but it has
| "graphics".
|
| _sigh_
|
| it could be so awesome if a non-schizo designer got
| involved. it's frustrating really. so much potential, such
| thick window bars.
|
| it is so stupid.
| easytiger wrote:
| I recall heavily using gnome 2?/KDE 2? (indeed I had to
| test things on them for work) Circa 2005 and indeed when
| Sun heavily invested in gnome to make the "java desktop"
| on Solaris to add accessibility etc so they could win
| institutional contracts. Was perfectly on the way to
| being great.
|
| Then the great childish "let's rewrite everything from
| scratch" for both Linux DEs happened. It was a decade?
| before KDE was remotely viable again.
|
| The gnome/gtk Devs focusing on zero configuration options
| possibly the most rubbish redesign I've ever seen.
|
| KDE/Plasma only became viable to me in the last 24
| months. Felt like a POC
| krylon wrote:
| I felt kind of lost when Gnome 3 landed, but I discovered
| MATE, which forked off of Gnome 2. Gnome 2, IMHO, was the
| peak Unix desktop experience, and I felt so relieved to
| discover it does live on.
|
| Gnome 3 confused (and continues to confuse) me to no end
| every time I tried it (which admittedly was not all that
| often. KDE 2 was cool, but I did not like KDE 3, although
| I do not remember why. I stopped paying much attention to
| KDE at that point. Xfce is nice, but not as nice as
| Gnome2/Mate.
| mbreese wrote:
| It makes sense to me. Developers work on a project (and
| most definitely open source developers) because they feel
| some friction with a system. Maybe it's a task they want to
| automate, or a bug in some software they need to use. But
| either way -- there must be some pain point that is causing
| them friction. This is what causes some program/feature to
| be written or updated or fixed.
|
| If those developers have a perfectly good work around, then
| there is no pain point _for them_. It doesn't matter if it
| is a pain point for their GUI-exclusive users. If they
| don't feel the pain, it won't be prioritized.[*]
|
| This isn't a criticism of Gnome per se, but rather a
| reality of time management. There is only so much time to
| go around, which means features and bugs get triaged. If
| none of the _developers_ feel like this is enough of a pain
| to get into the quagmire that is the GtkFileChooser (?)
| widget, then it will not be touched.
|
| [*] That is, of course unless they are being paid to do the
| work. If you are volunteering, then you get to choose what
| work to do. If you're getting paid, the suddenly _not_
| working on the file chooser could become a pain point for
| the developer (as they might not get paid). Which is the
| major advantage commercial OSes have over their open source
| competition.
| simion314 wrote:
| GNOME devs want the users to use drag and drop instead of
| the file pciker, in their mind file picker is outdated
| and should be removed, in their mind having thumbnails
| there is duplicating having thumbnails in the File
| manager.
|
| I am joking but I think they considered removing tabs
| because you should use multiple windows and ENJOY the
| cool Window manager their designed to switch between
| windows.
| smoldesu wrote:
| You're joking, but this is literally the line of logic
| that GNOME's maintainers have used for the past ~5 years.
|
| > "Xorg is outdated and should be removed, everyone port
| everything over to Wayland!"
|
| > "AppIndicator is outdated and should be removed, if
| anyone uses it (see: everyone), they can impliment it
| themselves!"
|
| > "Native packaging is outdated and should be removed,
| Flatpak is the future now!"
|
| > "Having a proper library of native widgets is outdated
| and should be removed, so we're replacing it with
| Libadwaita!"
|
| ...and so on and so forth...
| llllllllllll9 wrote:
| i find most (if not all) technical decisions of the gnome
| team sensible.
|
| but that fucking design and UI paradigm? WTF! the whole
| thing is so jekyll and hyde it beggars belief.
| staindk wrote:
| Seeing no one complain about broken drag-and-drop
| functionality (in Gnome File Manager) in this thread has
| had me realise I must have a somewhat unique problem.
|
| For the life of me I can't drag files out of File Manager
| into a program without a struggle.
|
| This is an issue for drag-and-dropping e.g. images from
| FM -> Chrome (Jira stories / Gitlab comments / etc) or
| from FM -> Slack. Don't think I have tried much dragging
| into other programs.
|
| What happens is either:
|
| (~90%) nothing is dragged
|
| (~7%) the file path is dragged and either causes an error
| or just pastes the path
|
| (~3%) the actual file is dragged as expected
|
| I've figured out some ways to improve the likelihood of
| the drag working - instead of just clicking and dragging
| the item, I first spin around in my chair twice, give a
| very specific exasperated sigh, and then use my arrow
| keys to select the file I want to drag and only _then_
| click and drag with my mouse. This works much more often
| - probably about 50% of the time.
|
| Recently started always trying copy in FM -> paste in
| destination program and that generally works.
|
| (I've had the issue for over a year, since the start of
| my OS install. Currently on latest Gnome (41? 42?) on
| Arch. Wayland. If someone sees this and has any ideas
| please let me know.)
| marcosdumay wrote:
| From what I can see, Gnome users do not complain. They
| know what works and what doesn't, and deal with it.
|
| Not seeing anybody complaining about some Gnome brokeness
| is perfectly normal.
| carlhjerpe wrote:
| You should give KDE a try, it's pretty frikkin good. The
| file manager defaults are a bit weird but it's OK.
| phkahler wrote:
| >> GNOME devs want the users to use drag and drop instead
| of the file pciker...
|
| That's funny. Just replace the file dialog with opening
| the file manager. Drag and Drop. Better yet, just modify
| the file manager to have an option to self-close after
| selecting a file and a way to pass that selection to the
| app (using MIME types would not allow the DE to get it to
| the correct app in all cases).
| superkuh wrote:
| Gtk3 filechooser worked fine until 2014. Distros with gtk3
| released before this have a gtk3 lib that handles pasting
| file paths in the file chooser and the gsettings still work.
| My last desktop with functional Gtk3 is Ubuntu 14.04 on
| Extended Service Mantainance (ESM) support. But it'll age out
| of support fairly soon.
| kgeist wrote:
| >The biggest problem with GNOME right now is Gtk3 and
| gtkfilechooserwidget.c. It is so spaghetti and so many things
| rely on it that no one at GNOME is willing to work on it for
| fear of breaking something.
|
| I wonder, why can't they introduce something like
| gtkfilechooserwidget2.c leaving the original widget intact?
| nine_k wrote:
| A lot of work, maybe? Also, bug-to-bug compatibility?
| kgeist wrote:
| It could be a cleaned up version of the widget minus the
| warts. Applications wouldn't need bug-to-bug compatibility
| if it was a conscious choice to upgrade to a new widget.
| lobocinza wrote:
| The biggest problem with GNOME is that the organization needs
| to get their shit together. Their priorities and design choices
| are awkward at best so I must say they don't care for their
| users at all.
| llllllllllll9 wrote:
| this is seriously a mystery to me. how do people use gnome?
| how can you be productive with it? i tried so hard:
| https://news.ycombinator.com/item?id=31782882
| marcosdumay wrote:
| How come does every distro default to it, make it
| incredibly hard to opt-out, and then decide it's the best
| one available because it has more than double the installed
| base of the next option?
|
| I simply do not understand people.
| lobocinza wrote:
| I use GNOME and honestly like it despite the many flaws.
| May be some sort of Stockholm syndrome, IDK. As I see I
| spent most of my time on the CLI or on the browser so the
| DE in itself doesn't matter that much and GNOME advantage
| is that I don't have to waste time troubleshooting and
| customizing it (not even possible sometimes) so I can focus
| on the things that matter. If you compare DEs pages on Arch
| Wiki, GNOME by far has the smaller 'Troubleshooting'
| section. Also when you use something for a long time you
| know how to workaround it's limitations and fix things
| while.
| danbolt wrote:
| I use GNOME technically, but in earnest I use whatever
| Pop!_OS decides to go with. It's been fine transitioning
| off LXDE and macOS for me. That said, I don't feel like a
| Linux power user or anything.
| bityard wrote:
| I use GNOME only because my favorite OS right now is Pop OS
| and it's what they ship by default. Otherwise, I'd still
| probably be laboring to get KDE, XFCE, or MATE to be a
| satisfactory experience.
|
| The only thing that makes GNOME bearable for me are a
| handful of extensions and post-install tweaks. Specifically
| Dash-to-Panel and ArcMenu.
|
| The biggest thing that still annoys me is the GNOME folks
| have this fetish about stuffing as many widgets as they can
| into the titlebars of windows.
| jsrcout wrote:
| You may know this, but if you type / in the file chooser
| window, it replaces the path buttons with a text bar that you
| can type or paste into. I discovered that by accident, probably
| a couple years after the text bar vanished...
| ugjka wrote:
| or ~ if you want to navigate $HOME
| hedora wrote:
| The file chooser has been broken since at least gnome 2, and
| was antiquated in the gnome 1 days. I don't believe it will
| work in gnome 4.
| [deleted]
| torginus wrote:
| This is a pet peeve of mine - why is it that in Linux it's
| idiomatic to start like 5 processes and pipe their outputs
| together to find a file containing a certain word from the
| shell, but something like a file chooser cannot be its own
| program?
| stjohnswarts wrote:
| It's a matter of human resources, gtk3 is an extremely small
| team compared to its influence.
| kelnos wrote:
| Haven't the GTK developers basically admitted that GTK
| exists to serve the needs of GNOME, and if anyone else gets
| good use out of it, that's accidental and unsupported?
|
| I really wish we had another popular GUI toolkit that isn't
| Qt.
| usrn wrote:
| GNOME often rejects the ideas from the rest of the ecosystem.
| jordemort wrote:
| You'd need some way to inform the window manager that
| "windows from this process should be considered modals over
| this window of mine" - probably something that's in the realm
| of the possible to hack together?
| XorNot wrote:
| "Here are my screen coordinates, I'm going modal while
| you're running" seems like a perfectly adequate answer to
| that.
| colejohnson66 wrote:
| How do message box (alert) popups work?
| pixelat3d wrote:
| in GTK when you instantiate the window you pass what is
| called the "transient for" property (https://docs.gtk.org
| /gtk4/method.NativeDialog.set_transient_...). That
| informs the dialog what it belongs to. If you were to re-
| engineer this to make the file picker its own process,
| then you would have to fundamentally change the way it
| functions, sadly.
|
| Edit: And I _think_ Wayland would make this impossible?
| Someone correct me if I 'm wrong here, but don't you lose
| basically all inter-window introspection with it? There
| may be some negotiation process, but I don't know how you
| would go about accessing an entirely separate
| application's context under that pipeline.
| no_time wrote:
| I bet this info isnt written down explicitly except in
| this comment.
|
| The freedesktop.org community really needs it's own
| Raymond Chen pass down all the accumulated arcane
| knowledge.
| mlyle wrote:
| > I bet this info isnt written down explicitly except in
| this comment.
|
| The comment links to the documentation, which says it
| explicitly...
|
| And then, many other places in the documentation, e.g.
| https://docs.gtk.org/gtk4/method.Window.set_modal.html
|
| > Modal windows prevent interaction with other windows in
| the same application. To keep modal dialogs on top of
| main application windows, use
| gtk_window_set_transient_for() to make the dialog
| transient for the parent; most window managers will then
| disallow lowering the dialog below the parent.
| My100thaccount wrote:
| > inter-window introspection
|
| This oxymoron is a pet peeve of mine. If it's inter-
| window, then it's just inspection. Introspection is when
| something inspects itself, but people seem to think it
| just means inspecting anything technical.
|
| Great post though, I just needed to get that off my chest
| OJFord wrote:
| Mine too! (Perhaps we should introspect each other to
| determine why we feel this way....)
|
| I find it particularly ironic or confusing because
| introspection seems so much less likely/more rarely to
| occur in anything technical; so why does it get that
| association? Because you're right, people do seem to use
| it as though it means 'highly technical inspection' or
| something.
| pixelat3d wrote:
| My100thaccount wrote:
| ginko wrote:
| >You'd need some way to inform the window manager that
| "windows from this process should be considered modals over
| this window of mine"
|
| Why though? Am I the only one that hates modal windows? Why
| does the parent window have to be blocked by the dialog
| window? Can't it be like the color picker dialog in GIMP?
| kevingadd wrote:
| What happens if I hit File->Save, then while the file
| picker helper process is spawning I get an urgent instant
| message and tab away, and when I alt-tab back focus
| returns to GNOME and I close the tab because I forgot I
| didn't finish saving? Does the file picker go away? If I
| type a filename in the picker afterward and hit Save,
| does it save the file even though I closed the tab?
| deepsun wrote:
| Just like webpages in browser can capture its closing and
| ask you if you really want to quit.
|
| Same with your proposed workflow, when you try to close
| the tab, the file picker will pop up again (within the
| visible area of the tab, not on another monitor), tab
| stays opened.
| hawski wrote:
| As much as I hate modals they are usually a product of
| single threaded or poor event loop design.
| bityard wrote:
| There are/were Linux window managers or desktop
| environments where the file picker was not held if focus
| above the main window. Or at least they can be configured
| that way. I know because I've done it.
|
| It turns out, that when that happens, the user can
| accidentally focus the main window while the file picker
| is up, and then the file picker gets hidden underneath
| it. As a fun bonus, the application now _probably_
| appears to be frozen/crashed because it's waiting for
| input from the file picker that the user can no longer
| see.
|
| It's just a bad idea, man. For most people anyway.
| shaky-carrousel wrote:
| Then, if the user interacts with the main window, just
| close the file chooser and don't freeze the application.
| dylan-m wrote:
| > ... but something like a file chooser cannot be its own
| program?
|
| That's happening! Gtk 3 and 4 include
| GtkFileChooserNative[1]. It works like a file dialog except
| the application doesn't know about its widgets. That means it
| can proxy another application.
|
| So if you're running a Gtk app in a sandbox like Flatpak or
| Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME,
| this is implemented by an application (in the host) which,
| itself, creates a GtkFileChooser. In the future, it could be
| a beefier application. One benefit of that taking a while to
| happen is, once the implementation gets fancier, there won't
| be too many weird mismatched applications.
|
| (Also, I mention GNOME, but it's important to notice the file
| chooser portal is itself platform neutral; KDE apps use this,
| too, and the implementation depends on what desktop you are
| running. Yay, decoupling!).
|
| Not _everything_ uses GtkFileChooserNative, but pretty much
| any recent Gtk app that doesn 't have weird requirements
| probably does. Off the top of my head, Firefox, Secrets,
| Bottles, GNOME Builder and GNOME Text Editor (although they
| still ask for access to all of the of the files for other
| reasons), ... even Slack and VS Code! (Electron switched over
| recently).
|
| [1] https://docs.gtk.org/gtk4/class.FileChooserNative.html
|
| [2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-
| org.free...
| dathinab wrote:
| What I don't understand is why it took so long.
|
| That bundling file chooser with a GUI framework is a bad
| idea should be obvious since well, ... Java Swing?.
|
| And a easy to use system interface for a file chooser isn't
| hard to make, could have been (preferable) a binary you
| call and communicate with pipes with or similar or could
| have been something else (e.g. shared object).
|
| It's kinda sad that the various Linux communities where so
| focused on their GUI framework being the best that it
| didn't happen until it was technically needed (for
| sandboxing) ...
|
| EDIT just to be clear 95+% of applications could use a cmd
| with Linux style arguments which once done emits the
| selected file(s) to stdout, but there are a minority of
| advanced use-cases which require a bit of two way
| communication. Through most of them are bad ideas anyway,
| so maybe that could have been ignored.
| dylan-m wrote:
| Was it a thing _anywhere_ except recently? Going through
| some different native Windows apps, I see a host of
| different file choosers (many of which were once "the
| one" for their version of Windows), and they all belong
| to the same process as their respective applications.
| Definitely not to a privileged service. (Unless Windows
| is doing something exceptionally fancy here?).
|
| A lot of this stuff was "decided" back when we had
| serious memory constraints, and less technology to manage
| them. Switching processes was costly. Running the file
| chooser in the same application was an excellent
| compromise. A _solution_. (I remember an article about
| this problem in the context of early MacOS, along with
| drag & drop and the like. Will share if I find it).
|
| In addition, having the file chooser in-process makes
| sense if you're trying to appease app developers, who
| think they want the ability to change everything. In
| particular, they'd really like to add a custom preview
| widget and some other gizmos to the file chooser.
| Photoshop puts all sorts of buttons in its Export dialog,
| for instance. And because Photoshop does it, a bunch of
| other applications think they should, too. And they still
| want to, even if they're using Gtk.
|
| Saying "this is dumb, we need this dialog to be a simpler
| interface for [reasons] and if your app has a weird file
| dialog you'll have to deal with it" is a very decisive
| action, and it is not without friction. So I think the
| reason this took so long is partly an accident of history
| (the bad solution stuck because it was too late by the
| time we could afford the good solution), and partly just
| luck: things reached an inflection point where app
| developers actually get something (sandboxing and clever
| app containers) in exchange for the inconvenience.
| amluto wrote:
| Try typing the name of a _folder_ that will be found by the
| integrated tracker search into a gnome file chooser that's
| trying to save a file. Then double-click that folder. The
| results are poor, to say the least.
| pixelat3d wrote:
| >> It's unfixable behavior because the GNOME devs stopped
| respecting their own gsettings, org.gtk.Settings.FileChooser
| location-mode, to FORCE the path-bar experience on everyone.
| Because no one needs to type file paths, apparently. So why
| bother respecting the settings for path-bar or filename-entry?
|
| Control + L will turn the path bar into a simple string w/
| autocomplete. Am I missing something here or are you talking
| about pasting a path into the filename portion of the dialog?
| bityard wrote:
| Hiding important features behind arbitrary keyboard shortcuts
| is definitely on my list of things I hate about modern
| desktop environments. (Not to mention, extremely unfriendly
| to accessibility.)
| kennywinker wrote:
| I understand how things get this way, but it is a super easy
| problem to fix:
|
| 1. spin up a new file picker: GTKFilePicker.c
|
| 2. add a deprecation warning to gtkfilechooserwidget.c
|
| 3. wait 20 years, then git rm gtkfilechooserwidget.c
| llllllllllll9 wrote:
| i installed a new debian box for work and i forgot to choose
| xfce4 so went with the default. gnome 3. i tried. i tried so
| hard to get used to it. for 2 horrible months i tried.
|
| i only need a terminal, emacs, browser, thunderbird, the
| occasional screenshot and it was still horrific.
|
| to be clear it was only the usability that was a nightmare. i
| experienced no bugs. it's solid. but wow it is unusable.
|
| please, please, please someone at gnome headquarters ... can
| you make it usable? look at win10, win11, macos, kde, chromeos
| they all work fine. can't you do something like that? i believe
| you have the best software stack out there, and you're throwing
| it away with that frightful design.
|
| this is tragic.
| kstrauser wrote:
| This is purely my impression and not something I could prove,
| but it feels like Gnome wanted to have an out-of-the-box Mac-
| like experience, while not really understanding while people
| like using Macs. "You don't have a million configuration
| options on a Mac, so neither should we!" doesn't account for
| Apple having whole departments working on UI things, choosing
| sane defaults, etc. People don't like macOS because it
| doesn't give them options, but because it tried to make good
| decisions and patterns so that they won't _need_ to tweak
| everything.
|
| I know lots of people don't like Macs because they're not
| super tweakable, and that's fine. It's still my impression
| that Gnome is aiming for that target, while not quite
| understanding why a lot of people _do_ like Macs.
| llllllllllll9 wrote:
| 100% my impression as well.
|
| and you're right. macos is fine from a usability point of
| view. everything in gnome UI feels like they started
| strong, stayed strong, and then gave up half way ... (so
| many examples there's no point listing them anymore) and
| yeah put the clock in the middle of the bar while we're at
| it too.
|
| and yet, you feel the potential no? no bugs whatsoever for
| me.
|
| :/
|
| back to xfce4. clunky, but consistent. some bugs. it's ok.
| kstrauser wrote:
| For sure. It's _so_ close to being amazing, which makes
| it all the more frustrating.
| guy98238710 wrote:
| No idea what problems you encountered, but I find Gnome to be
| a joy to use. It was such a relief after years on Windows.
| Gnome Boxes is such a smooth experience compared to
| VirtualBox. Maximizing content area by putting UI elements in
| the title bar is also something I appreciate.
| olyjohn wrote:
| The problem is that nobody puts the right elements in the
| titlebar. It has just become a place where they improperly
| put "SAVE" for dialog boxes, when there was plenty of room
| in the dialog to begin with. It's kind of just become a
| dumping ground to put the shit that everybody doesn't want
| to deal with. It's like the hamburger menu, it might have
| some benefits, but now everybody just throws all the shit
| in there that they don't wanna deal with. Why would you
| fill out a form going down the list, and then have your
| save button all the way at the top of the window? Why
| bother trying to make a good, intuitive UI, when you can
| just make a giant heap of shit and put all your leftover
| stuff there? And then to top it off, now I can't move the
| fucking window, because the titlebar is full of trash.
| stjohnswarts wrote:
| I don't get your last comment? Everything is going to move into
| gtk4 or move to other toolkits as gtk3 gets obsoleted, it's the
| way of the world.
| urlwolf wrote:
| I've used KDE all this time and never noticed. Try it, it's not
| heavier than LXDE nowadays, which is saying something!
| whalesalad wrote:
| kde gang
| bityard wrote:
| I love the fact that right there on KDE.org there's a
| screenshot of Kontact with that big obnoxious vertical "HTML
| Message" black bar in the middle of the screen. I remember
| reading a bug report some 10 or 15 years ago to allow it to be
| hide-able somehow at least with the author just flat-out
| refusing to do it or allow patches for it.
|
| I'll never use Kontact for this reason but I do like most of
| the rest of KDE.
| smoldesu wrote:
| KDE 5.25 is very exciting, it feels great being on a desktop
| that gets updates where features are _added_ instead of
| removed. Definitely the place to be in 2022!
| laerus wrote:
| > it's much easier to accept mediocrity than to pursue adequacy.
|
| pretty much describes most of today's software
| trynumber9 wrote:
| Luckily for the Gnome team, Microsoft ripped out features from
| their desktop interface in Windows 11. So Gnome might look
| comparatively functional when Windows 10 is EOL.
| tannhaeuser wrote:
| My top gtk3/gnome 30 wtfs:
|
| - the (all too well-known) file picker issue where when you type
| something it interprets it as file name filter rather than, you
| know, the file name you want to save under
|
| - missing top menu (but a bar is still there wasting space for a
| ... clock wtf)
|
| - general window positioning; like, if you open an app, rather
| than just opening a window as new top window, gnome opens it
| behind others and pushes a notification "FF is ready" wtf
|
| - mainstream desktop apps not ported to dark mode, so those icons
| look even more puzzling
|
| I could go on, but I'm definitely leaving gnome/gtk apps behind.
| I've eyed KDE Plasma which could give me everything I ever wanted
| from a DE, but I was using Ubuntu/gnome because it was mainstream
| enough that everything just works OOTB. I'm also totally not
| looking forward to wayland, containerize-all-the-things such that
| basic file workflows stop working, and other attitudes, all the
| while the apps I'm using are exactly the same I've used 15 or 20
| years ago, without new ones coming.
|
| I think I'm going back to Mac.
| bogwog wrote:
| > I've eyed KDE Plasma which could give me everything I ever
| wanted from a DE, but I was using Ubuntu/gnome because it was
| mainstream enough that everything just works OOTB
|
| I'm curious, what do you expect won't work under KDE?
| tannhaeuser wrote:
| Nothing in particular; maybe third-party apps like MS Teams
| (ugh) I need for my customer projects (which also didn't work
| right on gnome for years, and had trouble when switching
| logins/customers), that kind of stuff. I considered kubuntu,
| but thought I was leaving Ubuntu mainstream for good anyway,
| so why not go to eg Slackware w/ KDE Plasma and say goodbye
| to systemd, snaps, and containerized browser behemoths that
| want to update themselves all the time anyway. Don't want
| that shit on my main machine period. I'll be keeping my old
| (Ubuntu 16.04 ESM and 20.04 LTS) notebooks around just in
| case, but customers keep sending me shite notebooks, and
| MacBooks are more than capable to run Docker crap anyway.
| marcosdumay wrote:
| Getting rid of systemd is harder. But applications don't
| stop working because you switched a DE.
| bb010g wrote:
| What do you so heavily dislike about systemd? It's pretty
| useful.
| marcodiego wrote:
| > - general window positioning; like, if you open an app,
| rather than just opening a window as new top window, gnome
| opens it behind others and pushes a notification "FF is ready"
| wtf
|
| I like this behavior. It only happens for apps that take too
| long to start. When an app takes too long to start, it is usual
| for me to continue doing other things while it starts, when it
| starts, I don't want it stealing my focus. I think this feature
| works exactly as intended.
| bityard wrote:
| You prefer a notification to steal your focus instead? :)
| marcodiego wrote:
| The notification does not steals my focus, it may call my
| attention, but it will not steal my focus. Focus stealing
| is when the app I'm using is switched to another without
| any action from me.
| pjmlp wrote:
| Mine is that they kind of abandoned Vala and then started using
| their own JavaScript engine for everything beyond bare bones
| Gtk+.
|
| The slowness and leaks of not having a V8 class implementation,
| has made me embrace XFCE for the surviving device I still run
| GNU/Linux natively on.
|
| And to think 22 years ago I was arguing for GNOME, advocating
| for Gtkmm versus Qt.
| phkahler wrote:
| >> the (all too well-known) file picker issue where when you
| type something it interprets it as file name filter rather
| than, you know, the file name you want to save under
|
| That one drives me insane.
|
| >> general window positioning
|
| I want my applications to come up where they were when I last
| closed them. This used to be up to the app under X, and I'm
| fully on board with the Wayland idea that an application
| shouldn't know or be able to modify its window position. But
| that means putting things where they were is the DE/compositors
| responsibility now, and I fear they're going to fight that idea
| forever. I hope I'm wrong though.
| regularfry wrote:
| > I'm fully on board with the Wayland idea that an
| application shouldn't know or be able to modify its window
| position
|
| Why? Genuine question - that sounds like an _incredibly_
| opinionated position for the display server to force up the
| stack, and I don 't have a good intuition for why it should
| be necessary.
| phkahler wrote:
| >> Why? Genuine question - that sounds like an incredibly
| opinionated position for the display server to force up the
| stack...
|
| The security model in Wayland seems to keep the application
| largely isolated from its environment. No warping the mouse
| pointer, no reading pixels, no understanding of what the
| user might be doing _outside_ the application window. I can
| agree with all of that in principle. It is not the
| applications place to move anything on the desktop
| including itself. Those are to be done by the user. Also
| for consistency this kind of thing has to be done by the
| DE.
|
| It was also nonsensical to have have applications be
| responsible for remembering their own positions instead of
| the "window manager". Read that again "window manager" ;-)
| robonerd wrote:
| > _The security model in Wayland seems to keep the
| application largely isolated from its environment._
|
| I really don't see what good that is when considered in
| the greater context of the Linux desktop paradigm,
| wherein any application running under your user almost
| certainly has write access to your entire $HOME,
| including the ability to tamper with your shell
| configuration, edit your $PATH, and do all manner of
| nasty subversive shit. To get any real security benefit
| from Wayland over X, you'd have to abandon the entire
| Linux desktop paradigm and use a completely new ecosystem
| as different from the traditional linux desktop as
| Android is.
|
| If you just use Wayland as a drop-in replacement for X
| (as GNOME/Wayland and KDE/Wayland are essentially doing),
| you're still screwed six ways to Sunday.
| phkahler wrote:
| >> If you just use Wayland as a drop-in replacement for X
| (as GNOME/Wayland and KDE/Wayland are essentially doing),
| you're still screwed six ways to Sunday.
|
| No, you're only screwed 4 or 5 ways. Applications can't
| screen capture, and they can't monitor the keyboard input
| to other applications.
|
| Your points on other security issues are valid, but just
| because there are 6 different ways a program can dig into
| your system is no reason not to plug _some_ of those
| holes. Wayland does that.
|
| IMHO we need to restrict a bunch of system calls so they
| can only be used by the GUI toolkit. Then only files
| selected by the user could be accessed by an application.
| Of course CLI programs and other cases need permission
| too, so there is some complexity to work out. But this
| would allow a random application to use the system
| installed GUI toolkit and access only what the user
| specifically says through interactions.
|
| Better security doesn't have to be hard, but it does
| require that changes be made.
| ryukafalz wrote:
| > I really don't see what good that is when considered in
| the greater context of the Linux desktop paradigm,
| wherein any application running under your user almost
| certainly has write access to your entire $HOME,
| including the ability to tamper with your shell
| configuration, edit your $PATH, and do all manner of
| nasty subversive shit. To get any real security benefit
| from Wayland over X, you'd have to abandon the entire
| Linux desktop paradigm and use a completely new ecosystem
| as different from the traditional linux desktop as
| Android is.
|
| It doesn't require changes as deep as you're implying
| (although I would say moving away from the traditional
| UNIX permissions model would ultimately be a good thing).
| It can be beneficial with existing application
| confinement mechanisms like Flatpak. You can restrict a
| Flatpak app from accessing your $HOME, but if it's given
| access to your X server it has a lot more access than it
| likely needs. My understanding is the situation is better
| with Wayland, provided you only give it access to the
| Wayland socket and not the X11 socket.
| tannhaeuser wrote:
| Why do Linux heads this needless containerization thing
| to themselves? There are zero new desktop apps coming;
| those in use are F/OSS and have been thoroughly reviewed
| for like 20 years. What's the threat? At best, it
| disturbs user file-based workflows and puts additional
| work onto developers who are few and far between anyway.
| Distros have worked well for a long time - much better
| than Win or Mac sw updates. If you want to compile your
| own app, it's well supported. We don't have a rush of new
| unstable must-have libs to compile against all of a
| sudden.
| dman wrote:
| Just wait until systemd grows a ui toolkit :D
| nvrspyx wrote:
| > any application running under your user almost
| certainly has write access to your entire $HOME,
| including the ability to tamper with your shell
| configuration, edit your $PATH, and do all manner of
| nasty subversive shit.
|
| Not that I'm a fan of it or that knowledgeable about the
| subject, but isn't this sort of where Flatpak comes in
| where applications have to be given permission to access
| some of these?
|
| I know that Fedora is very clearly moving toward the
| Silverblue (OSTree) endgame where the underlying system
| is immutable and Flatpak is the default for user
| applications on top.
| olddustytrail wrote:
| More simply, because I say where the application goes. It
| absolutely does not get a say in the matter. It's my
| computer.
| occamrazor wrote:
| With multiple monitors, and multiple multi-monito
| configurations, window position becomes a complicated
| concept, full of pitfalls and corner cases. It is
| reasonable (although admittedly not the only possibility
| solution) to centralize the window position management in
| the wm.
| einpoklum wrote:
| Your conclusion doesn't follow from your premise.
|
| What does follow is that apps should have a library
| available which allows them to express their positioning
| desires while accounting for the complications and corner
| cases.
|
| Even if positioning were centralized, apps should still
| have been able to tell the WM "This is what I want to
| happen w.r.t. positioning, try to accommodate me".
| bityard wrote:
| Given the choice between the window manager making all of
| the positioning/size decisions and allowing the app to do
| it, I'll gladly pick the WM. In the opposite world, sure,
| most apps will behave sensibly but then occasionally
| you're going to run into that application where the
| author says, "hey, my app is so great, you're definitely
| going to want it full-screen all the time!"
|
| An exaggeration of course, but I have seen plenty of apps
| try to do "smart" things about window management on their
| own, and they always get it wrong. It's one of the
| reason's KDE WM allows you to to override and make
| permanent a surprising number of settings.
|
| (I also believe that websites should not be able to just
| do whatever the hell they want on my computer, but that
| battle seems to have been lost.)
| occamrazor wrote:
| I should have explained myself better. The old way of
| specifying a position (pixel coords in a plane) does not
| work well for complicated setups. Among the possible
| alternatives there is:
|
| 1. Assign responsibility to the wm (Wayland's way)
|
| 2. Create a new way to specify position preference in a
| complicated world. That's what you propose, IIUC. It's
| possible but complicated, and Wayland had a lot of other
| problems to worry about, therefore I understand why they
| didn't choose this way.
|
| 3.Leave the simple protocol in place, but let the wm
| override the application's choice when necessary. I guess
| a lot of apps would not work properly in such a system.
| mayama wrote:
| I got used to type slash(/) which opens file input field when
| ever I'm pasting file.
| spicybright wrote:
| With respect to the Wayland devs, as they've been fighting
| more than an uphill battle for a decade now, but that is so
| bone-headed.
|
| If their design philosophy is like this in general, no wonder
| no one is adopting it. It's just a worse X.
| behnamoh wrote:
| > I think I'm going back to Mac.
|
| This is poor conclusion imo. KDE might better suite your needs.
| Plus, macOS comes with its own wtf's:
| https://medium.com/@parttimeben/mac-it-just-works-horribly-c...
| tannhaeuser wrote:
| Yes I'm aware Mac OS isn't a panacea either (used
| MacBooks/PowerBooks and Mac mini on and off alongside Linux
| since 2003). But I had such a craptastic experience with PC
| hardware lately: on my 3rd Dell Latitude/Precision with
| battery and other hw defects ootb sent by customers for work
| within 8 months, and my 2019 Thinkpad has a stuck trackpad -
| miniscule as it is - due to completely unused mechanical
| parts (buttons, think point, and whatnot). Meanwhile, M1/2
| MacBooks leave x86 notebooks in the dust performance-wise,
| and have left PC notebooks behind in terms of screen
| resolution for a long time now, also wrt trackpad and
| keyboard, and value retention, it's not funny
| corrral wrote:
| I like to say that Apple providing a much better experience
| than the competition has less to do with Apple being
| amazing and more with the competition being shockingly bad.
| behnamoh wrote:
| Word.
| ajvs wrote:
| > I could go on, but I'm definitely leaving gnome/gtk apps
| behind. I've eyed KDE Plasma which could give me everything I
| ever wanted from a DE, but I was using Ubuntu/gnome because it
| was mainstream enough that everything just works OOTB
|
| Kubuntu was my first distro and posts like these reconfirm my
| decision to stick with KDE.
| sundarurfriend wrote:
| I wish it was mine too. I would have gone for Linux as my
| main OS lot earlier.
| lowercased wrote:
| I started with desktop linux with KDE2, and KDE3 was...
| seemingly perfect. I watched some colleagues move to KDE4 when
| it came out and it felt like a ... mess. I tried it myself for
| a few days and it was too foreign. Never cared for gnome as a
| main desktop, although I do recognize gnome foundation did
| provide a lot of useful software over the years, some of which
| I used.
|
| Moved to mac for main desktop around 2008. I look back some
| times and KDE5/plasma/whatever might be worthwhile to check out
| again. Mac annoyances are piling up over the years, but I
| suspect it would be "the grass is greener" somewhere else, and
| I'd find a lot of the KDE annoyances which led to me leave may
| still be there.
| bityard wrote:
| Same here. GNOME 2 was just about perfect.* KDE 3 was even
| better. Rock solid and lots of excellent, well-integrated
| functionality. Everything after those two have been a
| showcase of failed UX experiments.
|
| * (It's successor MATE has not aged gracefully,
| unfortunately.)
| int_19h wrote:
| Modern KDE is pretty good. Most importantly, it still lets
| you configure things to your own liking, instead of one-
| size-fits-all approach that GNOME espouses.
| bb010g wrote:
| If you're a KDE 3 fan, https://trinitydesktop.org/ is
| actively maintained.
| Phrodo_00 wrote:
| > general window positioning
|
| This has worked as expected to me. It generally opens windows
| on top of the stack unless the app takes too long to start and
| you've interacted with the window on top. In that case I
| appreciate it doesn't change focus (I could be typing something
| for example).
| squarefoot wrote:
| > - the (all too well-known) file picker issue where when you
| type something it interprets it as file name filter rather
| than, you know, the file name you want to save under
|
| I deeply hate this one, it always gets me when I'm saving in a
| hurry.
|
| And let's not forget about buttons on windows title bars.
| Someone please tell GTK developers that most of us aren't using
| tablets; computers with actual keyboards and mice are here to
| stay for a long time.
| Karunamon wrote:
| That one drives me absolutely fucking batty. Nobody uses
| GNOME on the touch screens that the UI was clearly designed
| for, and moving the default requestor buttons out of the
| bottom right where literally every single GUI of any note
| throughout history puts them is a particularly galling bit of
| NIH snowflakery.
| bogwog wrote:
| Gnome is what you get when you combine the worst parts of
| Windows 8 with the worst parts of MacOS. Bad ideas + bad
| execution, but most major distros ship it by default for
| some inexplicable reason.
| piyh wrote:
| I ran into not being able to open Nautilus as an admin without
| having to install some packages through apt. Why is Linux the
| only OS that doesn't allow me to edit or view a system file out
| of the box?
| teawrecks wrote:
| The writer seems willingly disingenuous. Not having a feature
| isn't the same as having a bug. The software is behaving exactly
| as designed. Do you say that older versions of windows develop
| "bugs" as soon as a newer version adds a new feature? Of course
| not.
|
| I agree with the conclusion though, these little missing
| conveniences add up to a worse experience for converts. I
| understand open source apps choosing not to do things exactly the
| same way as proprietary solutions, but we at least need something
| _as_ good.
|
| That said, it has always been the case that if a feature didn't
| exist in the pile of software that was freely and openly provided
| to you, you would either contribute the feature yourself or just
| go elsewhere. So the bounty would have sufficed, there is no
| point in being a shithead about it.
| 2OEH8eoCRo0 wrote:
| Yes it does. I'm looking at a thumbnail in my Gnome file picker
| right now. I'm on Fedora 36 (Gnome 42)
|
| Edit: It looks like the specific complaint is that the Gnome file
| picker does not allow icon view. That is true, but I still see
| two thumbnails: one next to the actual file, and one in the
| thumbnail pane.
|
| A better title might be "Gnome has no file picker icon view and I
| create flamebait titles."
| xdfgh1112 wrote:
| As a longtime gnome user I knew exactly what he meant. Icon
| view is what we want. The others are practically useless for
| quickly identifying a file.
| mohit052 wrote:
| Well written though
| robonerd wrote:
| A "thumbnail" that's one tenth the size of my _actual thumb 's
| nail_ is hardly deserving of the term.
| [deleted]
| JoeyBananas wrote:
| imwillofficial wrote:
| I found this article funny, engaging, and touched on a point that
| I've had for years about Linux on the desktop. (I won't spoil it)
| phanimahesh wrote:
| Gnome design is sometimes weird.
| epistasis wrote:
| The file picker has always been one of the weakest parts of our
| GUI paradigm, and it has been since the Mac.
|
| Navigating file system via GUIs is slow, painful, and for me
| takes a ton of cognitive effort after a short amount of time of
| accumulating files. Coming up with a system for organizing files
| is kind of hard in itself. Reorganizing as the number of files
| outgrows the system is also painful.
|
| And choosing a place to save a file is often the best time to
| start a reorganization. But if I save a file in a new location,
| having to switch apps and now go back to that same spot in the
| hierarchy and reorganize is painful.
|
| I don't have a good solution, just complaints, unfortunately. But
| after ~50 years of GUIs and hierarchical file systems I'm
| surprised somebody more clever than me hasn't come up with a
| better solution.
| pathartl wrote:
| This comment reminds me when Apple revamped Finder to include
| "All My Files". To me it felt like they were giving up. "FINE!
| Can't find something? HERE'S EVERYTHING!"
|
| These sort of pseudo-directories honestly bother me more than
| just plain old hierarchy. For example on Windows, "This
| PC/Documents" is really "%userprofile%/Documents", but to get
| to %userprofile% you have to go to C:\Users\<username>. But
| there's TONS of other stuff that lives in %userprofile%
| marcosdumay wrote:
| That's an example of a badly thought-out hierarchy. The
| pseudo-directories should be something like "This PC/My
| Files/Documents".
|
| But it's not a good reason why pseudo-directories are bad.
| epistasis wrote:
| There's few things I despise more than the "All My Files"
| view, because it is so useless to me. Perhaps it works for
| some, however!
| makecheck wrote:
| And it hasn't evolved with cloud/sandboxing/magic-
| paths/whatever. Like today on the Mac I used the popup
| directory path to try to navigate to the parent directory
| (since it showed it to me, and it was selectable) and it
| _couldn't_ ; it just threw me to my home folder as if that was
| my request. I can only assume it was some weird cloud thing but
| when path navigation _itself_ is a question mark we have
| problems.
| compiler-guy wrote:
| Someone remind me: When was the "Year of the Linux Desktop"?
| hallarempt wrote:
| 1994, for me...
| Ygg2 wrote:
| 20 years after heat death of the multiverse.
| aliswe wrote:
| For me it was around 2008, when kompiz came on Ubuntu ... those
| were good years.
| aidenn0 wrote:
| Since the comments here are rapidly turning into a "dump on
| GNOME" section, does anyone know if there is a master list of
| "What the GNOME documentation calls an application" <-> "What
| everybody else calls an application"
|
| e.g.
|
| - "Passwords and Keys" <-> "seahorse"
| einpoklum wrote:
| The Gtk file picker has for years offered a notoriously
| horrendous user experience. A lot of critical functionality is
| missing in the name of the GNOME people's vaunted simplicity or
| what-not.
|
| ... although reading superkuh's comment, maybe the explanation is
| more mundane (and sad) than that.
| someweirdperson wrote:
| ls doesn't show a preview either.
|
| When forced to use windows the first thing I do is turn this
| feature off. Something doesn't feel right when a tool to list
| files tries to process content of files (e.g. image processing
| did come with severe security holes in the past, and it probably
| still does today).
|
| Both of my toilets are working perfectly though.
| shadowgovt wrote:
| Your toilets work because you keep a jug of water next to them
| to pour directly into the bowl to flush it, because you
| disconnected the toilet tank. You've decided that a tool that
| tries to remove waste shouldn't also intake water. After all,
| intakes have failed in the past and flooded houses.
|
| Better to do that part by hand to be on the safe side.
|
| This is the nature of desktop UI. Your argument for purity of
| function is sound, but users want their desktop UI to read
| images for thumbnails and previews anyway because an image file
| means more to them, semantically, than a pile of inscrutable
| bits inside a file pointer. Desktops, over time, become a junk
| drawer of the features "most users want" for "controlling their
| computer" in the space between dedicated programs.
| cuteboy19 wrote:
| file-picker is a GUI tool whose language is visual instead of
| text. If ls must do text processing and formatting to output
| that colorful list, so too must file-picker do image processing
| to complete its function.
| butz wrote:
| With recent donation from Microsoft, GNOME will surely fix this
| critical issue, right?
| CommanderData wrote:
| Isn't this a problem with open source in general?
|
| It's hard to coordinate and improve software effectively among
| people with different ideas of what something should look like.
|
| This is why Windows and Mac will always remain dominant desktop
| operating systems, I think. It only takes a few issues like this
| for a user to give up and go back to the big two players.
|
| I'm not sure what the proper term is but having thousands of MS
| developers working and being led by managers, defined
| organizational processes and sense of direction vs hundreds of
| thousands open source developers led by their own ideas, what
| good and should look like, and different motiviation, a lack of
| coordination and a organisational process as big as a paragraph
| inside an obscure README.md
|
| Too many cooks in the kitchen sour the soup.
| olddustytrail wrote:
| > Too many cooks in the kitchen sour the soup.
|
| That sounds like a translation from another language? The
| English idiom is remarkably similar: "Too many cooks spoil the
| broth"
| DonHopkins wrote:
| Everybody wants to make it into the "Too Many Cooks" credits.
|
| https://www.youtube.com/watch?v=QrGrOK8oZG8
|
| (Is that RMS with the machete?)
| Ruq wrote:
| This is probably why Linux has been such a large success. For
| all the submissions, suggestions, filtering by those lower down
| the chain...at the end of the day it's Linus that says "Yes" or
| "No". (And/or chews people out for bad code.)
| sbuk wrote:
| That's the kernel. DE's are their own beast.
| formerly_proven wrote:
| Except for the part where tons of people are up in arms because
| MS removes or changes their UI. Fisher price, new control panel
| (XP), vista, UAC, start menu search, ads, mandatory logins, new
| control panel (8/10/11), new inflexible taskbar and so on
| em-bee wrote:
| so the technical question then is: how can i replace the file
| picker that the apps on my desktop use?
| em-bee wrote:
| a startingpoint for answers may be here:
| https://superuser.com/questions/944119/replace-gtk-file-dial...
|
| there is an xdg-desktop-portal feature that allows this, or
| pretend that a different desktop is used by setting
| XDG_CURRENT_DESKTOP for the application, as well as KGtk which
| is a library that can be loaded with LD_PRELOAD.
|
| either of these have to be applied per application though.
| jonathankoren wrote:
| > This bug has received over one hundred comments over the course
| of nearly two decades.
|
| This is best counter argument to the old saw that "Open source
| will always get better."
| izoow wrote:
| This reminds me of the problem with scrolling on Chromium, and
| now because of Electron a whole bunch of other programs. A single
| click of the scroll wheel moves the page by 100 px on Windows,
| for some reason it's only 53 px on Linux, which means scrolling
| is twice as slow. This is not just compared to Windows, but it's
| also much slower compared to other native Linux programs.
|
| If you search for this issue, there are countless discussions and
| half broken attempts to work around this problem, including
| Chromium bug reports including some that are now nearly 10 years
| old. It's 2022 and scrolling in Chromium and Electron apps with a
| mouse on Linux is still unbearably slow with no way to adjust
| that. There used to be a hidden CLI option, which was added for
| ChromeOS which probably had the same issue, but that was later
| removed.
|
| The best solution I found so far is running patched libinput that
| multiplies the scroll amount delta by whatever you want, and
| having a daemon running which watches the window that is
| currently being scrolled and alters that scroll multiplier
| accordingly. It's absurd that this is what I have to do to get
| acceptable scrolling behavior with a mouse on Linux.
| tiberious726 wrote:
| Have you tried disabling smooth scrolling?
| dpedu wrote:
| The program "imwheel" helped me work around an issue like this.
| dontbenebby wrote:
| This is a great example of "that's an explanation, not an
| excuse", albeit a weird one
|
| O_o
| ho_schi wrote:
| File picker horror? Use the built-in file picker of Javas own
| Swing-Toolkit.
|
| Integrating a GUI into a programming language library is
| inherently wrong. And while Sun was on the wrong path they
| doubled down and spread it across multiple platforms because they
| assumed their GUI was a solution. It wasn't and luckily Java
| based applications disappeared - with the exception of Java based
| developer tools.
| mikelward wrote:
| When I try to attach a file in Chrome on Linux, it shows a file
| picker that defaults to only showing files I recently uploaded,
| which is the exact opposite of what I want.
| fartcannon wrote:
| I came to Linux from a Windows world, so KDE always made more
| sense to me. I think, with the exception of 4.0, KDE has been
| fundamentally less bad than gnome since at least 2002. A sweet
| spot for me was KDE3.5 and then again current day KDE plasma. I
| like the customisability.
|
| I think the gnome foot is a better icon, though.
___________________________________________________________________
(page generated 2022-06-17 23:01 UTC)