Earlier quoted context omitted.
> The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL. For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.
>> so this is not breaking compatibility with apps there because it was never supported. It's not breaking GTK apps. If they want to say GNOME really only works with GTK apps that's fine and the toolkit will provide the decorations and nobody needs to care which part of the system draws them. But they want to support more than just GTK apps and rightly so.
Use Alacritty instead of Termite
211–220 of 331 posts
Re: Use Alacritty instead of Termite
#212Earlier quoted context omitted.
Electron uses Gtk and Games should use SDL2. They will support CSD, which is work, but it will happen. You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego. Btw: I'm a GNOME user who is against SSD.
The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. Same issue with tray icons, GNOME is expecting cross platform apps will use their shirty design OR their users will use only new GNOME apps. >You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego Is better that say all the 10 WM implement SSD (maybe as a fallba…
Old apps should dynamically link SDL / Gtk+ / Qt so they should work. For other old apps there's Xwayland which still provides SSD in GNOME.
Re: Use Alacritty instead of Termite
#213I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"
To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…
And FWIW, that website they're all referencing absolutely will not say a color contains mostly "yellow" (it reports the highest RGB value), no matter what you do [1].
Re: Use Alacritty instead of Termite
#214I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"
To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…
It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.
Re: Use Alacritty instead of Termite
#215Earlier quoted context omitted.
>How can they otherwise ignore such an obvious, massive load of complaints with such disrespectful and dismissive comments? [...] We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. I don't think the complaints were ignored, multiple other tickets with concrete work items were opened in response to the complaints. There is a ticket open to improve the speed…
You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the…
Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.
>I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.
Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.
Re: Use Alacritty instead of Termite
#216I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"
To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…
https://github.com/alacritty/alacritty#installation
Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.
Re: Use Alacritty instead of Termite
#217Earlier quoted context omitted.
You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the…
>It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to…
Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?
> I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.
Search could be faster if reading the directory was the FAST operation and displaying was the SLOW operation.
You can cook up situations where that is the case, like when the application has the directory cached in memory and / or the directory has (recursively) very few entries AND the display is actually on the other end of a remote desktop connection in the Siberian Sea so that it might matter whether you display 1 or 3 folder icons.
In more realistic cases, like where you have 10GB/s of memory access performance and a fast link to the GPU/display, but file systems that are still comparatively slow (especially with regards to filepath lookup, especially for directory trees that are routinely gigabytes in size / routinely have 1000s of entries in 100s of subdirectories), that will never be the case, not by a factor of 10s of 1000s.
Re: Use Alacritty instead of Termite
#218Earlier quoted context omitted.
>It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to…
> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? > I would think search would actually be faster, bec…
>And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?
The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.
Re: Use Alacritty instead of Termite
#219Earlier quoted context omitted.
> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? > I would think search would actually be faster, bec…
If you don't preload the folder contents and index it then type-ahead will also be arbitrarily slow there too. I don't know of any Linux filesystem that stores the files sorted and indexed on disk. >And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior shoul…
And it just goes through the list linearly, starting from the currently highlighted item, stopping at the first match.
It's a miniscule operation.
--
Speaking practically, have you ever experienced any file manager that has type-ahead (like most do) and the type ahead was not blazingly fast?
> The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.
If you're refusing to see that they achieved just the opposite and broke a totally sane implementation that was super predictable for any user that actually cared about their workflow, you can't be helped.
Re: Use Alacritty instead of Termite
#220Earlier quoted context omitted.
The other dev chiming in at the end with "I've heard only good things about Alacritty's default colorscheme so far" was also frustrating. Saying "well nobody else complained" is an awful reason to dismiss an issue.
Considering this is their reaction to someone pointing out that their green is actually yellow, I'm not surprised that they are in an echo chamber.
An insecure group member feels threatened by an outsider and lashes out. Another group member sees an outsider triggering a group member and he immediately jumps into help. Together, they attack the outsider and drive him off.
I think if the maintainer was less insecure and more able to take critique, the exchange wouldn't have aroused the "fight or flight" instincts of the group.