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 having bad/buggy/outdated support for OpenGL (which alacritty extensively uses), and this is a legitimate frustration that many developers in the low-level graphics domain have. It’s already really maddening for the devs, the contributors shouldn’t nag too much about it (I understand people outside the domain might genuinely not know this - but it’s always good to read some of the previous Github issues before filing your own, to learn the general “vive” among the core contributors)
> To be fair, I thought the dev’s response was adequate here
No it wasn't. It was bad.
Granted, the original bug report could have been a bit clearer, but the reporter was more than happy to help out and promptly responded to the questions and even some checking of the RGB of the colour in question, and then offered to open up a new related issue. But the dev in this case took the worse interpretation of the reporter's intent and claimed they were rude, or disrespectful or whatever, and took their report as an attack on their choice of default palette. I can imagine that the reporter was surprised and puzzled to be called "entitled" here.
And from the dev's followup explanation it just feels like their default is that everyone is entitled so they react accordingly. That response sure came out of left field, and I think the dev is lacking a little self awareness. Taking a defensive stance from the beginning is just bound to cause unnecessary drama.
> Aparently the defaults are poor. The default green is 0xb9ca4a which is actually yellow. I think it would be a good idea to copy the default colors from urxvt.
IDK, the screenshot posted makes what is supposed to be pretty primary (OK secondary) color green look like yellow. Color in terminals is pretty important; if I configured something to use ANSI green and it came out like Alacritty rendered it, I'd think something was off. Why is the default theme not standard?
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].
>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
I went and looked at the issue, and the title is not "colors are wrong" but it is "Colors don't look as they should". Interesting how everyone comes away with what they this was said. Says a lot about the dev who responded, really.
Wow, that's very insightful, and explains the dev's response. He genuinely thought he was being insulted.
This says a lot about me, but I empathize with that. That the reason I strive to be perfect in everything is that I feel like I'm under attack. Illogically, because I was, as a child, continually insulted.
It's a shitty way of living, trust me. But I get it.
Yes, it can be frustrating when your users don't know as much about your product as you do and ask for help in a vague way. It's unintuitive that a color named green would correspond to the color on the left that I don't think most people would think to check.
It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.
Dubious indeed. I gave Alacritty a really good shot, as I was super excited to have a faster terminal. But my entire experience was plagued with slowdowns -- huge latencies, cat'ing huge files was very slow. I spent tons of time trying to tune things to make it good but it just never got there.
Basically every other "simple" terminal I've found behaves better -- xterm, urxvt, konsole, even iTerm2.
I did quite a bit of testing of alacritty, kitty, iTerm2, and default macos terminal.
Kitty shown best results even using test that alacritty is using (tree /)
vim is faster in kitty (by perception), both when ran without multiplexor and inside tmux session
> Benchmarks so far have just involved running find /usr on my Linux system with Alacritty, st, and urxvt, and on macOS against Terminal.app and iTerm2.
I must say I am very impressed by Kitty's number of open and closed issues on Github. And it has so many features. The developer also seems like a nice guy and open to suggestions. I have used urxvt for a long time but wanted to try something more modern out, and set Kitty up today with a nice small config. I like it a lot so far.
Thanks for calling this out. This is not something I would have thought to check myself. It's unfortunate the most common use of the word toxic is in a very abstract sense, but the behavior you identify is just plain unnecessary rudeness and a much more suitable use of the word.
Can we assume people are acting in good faith until we have reason to think otherwise? As highlighted by the green-is-yellow issue, it is OK to simply say, "Understood. The color scheme has been previously discussed, is popular and isn't currently considered for change. But you can configure it yourself by <link-to-documentation>..." The accusation of an entitled attitude appears a bit of a leap to me too. To be fair, while a tad rude in tone, the dev's second post is an improvement.
Or perhaps, "We don't have a lot of resources for this level of detail. Sorry." (Open-source honesty?) Or even, "If you wrote a patch taking the values from rxvt it would be considered but possibly rejected after discussing policy with lead devs."
> But you can configure it yourself by <link-to-documentation>...
The two first comments of the maintainer in the thread mentioned the configurability of alacritty, giving soft hints that maybe the user should just set it privately to comfort their private taste. I feel that discussions about taste choices can sometimes be the most tiring ones, because often people have different tastes and you can't give rational arguments why you like one taste more. That's why there is configurability in the first place, maintainers recognizing that people have a diversity of personal tastes. You can't ever do it right by everyone. Maybe the maintainer should have communicated that better more early on, but they did communicate something along those lines later on. They were still around to explain themselves.
TBH, I detect grumpiness from his initial comment. He might not be a bad person, but if it's in an office, I'd probably apologize first if it was me who said that.
The thing that got me annoyed was the bold claim that it‘s the fastest terminal emulator even though many people reported that other terminal emulators were faster. For instance, urxvt was 3 to 5 times faster last time I checked (in addition to also being rock solid).
> Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"
What are the devs supposed to do? Debug the proprietary driver? They might not even own a Mac device because they give the software away for free and don't want to spend thousands on their spare time hobby. OpenGL drivers, regardless of manufactuer btw, have massive issues with bugs. They were so serious in fact, that the original glium maintainer gave up maintaining it. Having taken over emergency maintainership of glium, the way I deal with such issues now is to close them with a response that PRs are welcome (unless my specific config can reproduce them).
Also, extremely often you see open source as well as proprietary software on hn that's mac only. Isn't that, too, maintainers saying "switch operating systems"?
Why do people insist on supporting the closed source horror show of os x aid beyond me.
Apple docs are some of the worst on the planet. It's like they intend on making the barrier to entry high so once you are in the club you somehow have prestige.
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.
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.
Re: macOS, I don't think the people currently maintaining Alacritty have the ability or the inclination to fix those issues, some of which have been widely reported. Users keep opening duplicate issues without realizing it. I was guilty of this myself; I'm one of many people to notice problems with font fallback on macOS. While I thought the dev who responded to me could have been a bit nicer, it's probably frustrating for them to go through the same routine over and over. I also didn't really understand, at first, what was causing the problem that I was seeing. So I was not only bothering them, but my sense is that I came off as an idiot. (After poking around a bit, I found that the problem is in Alacritty's crossfont library. I forked it, added a temporary fix, and built my own version of the app from source. It was a happy ending to a not-entirely-pleasant experience.)
I was experimenting with it this week as well, and that exact issue was what had me uninstall it. I guess this post doesn't add much value, but I thought the (synchronicity?) Of our experiences was interesting.
I imagine they would probably say the same thing to you.
You're really not willing to use an excellent piece of software because one time you saw a dev dismiss someone who didn't like the default color scheme? How is that not even more petty?
Hey, vote with your wallet. A lot of people here on HN go out of their way to avoid products from companies that they view as poisonous, this is no different really.
You mean products with closed source, made by people who cannot be trusted? Yes, I think it's different. How many people here refuse to run Linux because they don't like the way Linus talks on the mailing lists?
I also read some of their interactions with people having issues on Gnome Wayland.
I recently switched to Tilix. I realized multiplexing makes me a lot faster than gpu powered terminal. and if I'm supposed to use tmux, then alacritty is a lot slower with tmux and loses it's "speed" (it's another issue on their page that I had fun reading all the way through)
While I agree that 0xb9ca4a is not a good choice for a default green, I disagree with the claim that it's yellow. In fact, the website that user cited for their "which is actually yellow" claim doesn't say what that user claims. That website says:
> Color #b9ca4a contains mainly GREEN color.
To my eyes, it's puke green. And the shades and tints of this color shown on that page make it clear that this is green.
It's equally "toxic" imo to torpedo a project, and all the efforts because of some bad communication.
Sure, the dev did fly off the handle initially but if you read the whole tread, he comes around, and actually keeps responding - in other words he cares.
We already seldomnly argue the point anymore. Now it seems we don't even evaluate software at core value anymore, rather we must know the personality of its creators.
Yes. I opened alacritty for the first time, wondered why my greens were showing up as yellow and googled it. This was the first result.
I doubt my comment is going to torpedo anything. But I didn't put down alacritty for "personality" reasons. There are a lot of excellent terminal emulators out there. This github issue wasn't an isolated incident, and if the devs are regularly this hostile there's bound to be lots of issues like this that won't be fixed. Especially since my OS is only nominally supported.
2-3 years ago someone had a bad day so don’t use the project… I guess this is the today’s mentality. It is no longer enough that the software is good if they don’t publicly lynch every wrong thinker or mistake-maker who passes by they are guilty by association
Can it be that there is background between these people that we don’t know and it is not reflective of the general attitude? I am not justifying rudeness, but I understand the human relations, online or offline can be complex. Also if alacrity is really technically good do we tolerate bad behavior by its developers? A bit like House wanted to be the best partially because he did not want to care too much about his behavior.
Frankly, that is a total misrepresentation to call that verbal abuse. What it is, is frustrated devs dealing with a rudely worded and pointless issue.
That issue is literally just trying to start a bikeshed about a color in a standard color scheme they chose as the default. It could not be more useless. On top of that, they try to start that bikeshed by simply saying "the colors are wrong" and pointing to a terrible screenshot.
Open source devs have to deal with a ton of unproductive garbage issues that they are not paid to deal with which risks engendering total burnout. It is way too much to ask them to treat every single person with kid gloves especially when they are opening issues from a place of disrespect.
> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use.
Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.
Gnome has a fairly negative rep now, thanks in part to its repeated spurning of feature requests from developers and users.
I remember when the Gnome desktop was exciting; there were frequently new apps to try, things pushing niche workflows that the Gnome team didn't consider.
> things pushing niche workflows that the Gnome team didn't consider
On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. The laptop my partner uses at home is a slightly old Thinkpad I put Fedora on last year and it took her about 20 minutes to work out to use everything (less time than she took on a Mac).
I think the Gnome developers have been pretty hostile to outside input and could have done a better job. But the fact that they've had a clear direction and haven't implemented everybody's personal preference has resulted in a coherent result without unnecessary cruft.
Considering Cinnamon is a fork of Gnome 3, it seems to be significant evidence of Gnome 3's influence. And Plasma was first released in 2014, 3 years after Gnome 3.
Gnome 3 had a HUGE affect on desktop environments, due to Gnome 2's popularity.
Plasma's predecessor (KDE 3) is closer to Gnome that Plasma itself. Plasma is as close to an antithesis of Gnome as you could get (outside of tiling window managers) - everything is customizable/extensible
I need to spend more time trying other things - I got bored of distro hopping years ago when I discovered that Fedora would mostly Just Work.
One thing I will say is that it's not just down to the desktop - all the main pieces need to be good and compatible and configured correctly for an overall smooth and intuitive experience. Gnome on Fedora does that.
Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule.
To borrow a term or two, it's developed in the bazaar, but run like the cathedral. Maybe an open-air cathedral.
Firefox is another project that I'd put under this label. All the important discussions happen in the back rooms, and by the time something universally unpopular hits the bug tracker, it's too late for users or the wider dev community to have any say.
Are you familiar with Bryan Cantrill's "right to fork, but not the power" observation?
It deeply influenced me. Alas, I didn't find his post-mortem until after I already joined an FOSS effort (kauli.org). Which failed. For so many reasons. Neutering us contributors probably being foremost.
Copypasta:
OpenSolaris challenges • That certain critical bits had to remain proprietary made forking the operating system technically difficult... • And that virtually all Solaris implementation knowledge lived within Sunʼs walls made it a practical impossibility • The community had the right to fork, but not the power • This led down the primrose path to open source governance: governing boards, elections, constitutions • And because all development on the system realistically required copyright assignment to Sun, OpenSolaris (sadly) remained a Sun puppet • Worse, some among Sunʼs middle management fancied themselves puppeteers...
>Gnome is one of those projects that should be considered "free in license only". While the project is free to hack on as you wish for your own purposes, your chances of being able to influence the development of the main project are minuscule.
That's not been my experience at all. The outrage machine on social media tends to spread around the small handful of patches that do get rejected so they can get angry about it, but they never talk about the other thousands of patches that do get accepted. Go look through all the other MRs on the gitlab if you don't believe me. Yes sometimes patches get rejected, it happens in any open source project.
>I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.
Gnome kind of goes off and does it's own thing without thinking about or cooperating with other open source developers. [Here's](https://gitlab.gnome.org/GNOME/mutter/-/issues/217) an example where they make a technical decisions that massively inconveniences a bunch of well known open source projects like GLFW and SDL (low-level cross-platform GUI toolkits).
Gnome are not good citizens of the open source commons, they do things that make it much harder to create cross-platform/cross-DE apps. GTK used to be fairly vendor neutral, it was the "GIMP ToolKit", not the Gnome toolkit. It worked with any desktop environment you chose to use. Since then they've been making the toolkit much more dependent on Gnome specific features and actively been making the lives of everyone else more difficult.
Also there are a lot of controversial decisions that make developers lives annoying, like [refusing to implement classic typeahead](https://gitlab.gnome.org/GNOME/nautilus/-/issues/244) instead relying on their search daemon which is really annoying for a lot of developers, and of course makes running a GTK app in a non-gnome desktop much worse. There are a few outstanding issues that make it annoying for developers to work with file paths under Gnome.
So yeah, they've burnt a lot of developer good will and seem intent on continuing that trend. LXDE even switched to QT instead. Really made it so that the linux desktop is less of a stable/reliable thing to develop for.
By refusing to cooperate with other open source projects they're really making it harder for open source developers to get things done and make new apps. Instead of having a common platform we now have gnome and everyone else, and there really are a lot of very obvious examples of that happening over the years.
Your first link is an issue that was posted over 10 years ago and was long resolved in other areas. It's not an illustrative example. I really wish people would stop trying to revive these ancient flamewars without acknowledging the current state of things (not saying this is your fault, but a little diligence always helps).
The second two links you're posting are again, the exception, not the rule. The vast majority of patches are accepted, you just happened to stumble across two of the contentious ones that got a big outrage response on reddit. Please go look at the other thousands of issues and MRs against GTK if you don't believe me, it's not just GNOME people filing those.
I would say I thoroughly agree with the last article you posted. There has never been a "Linux platform." It was always Motif versus KDE versus GNOME versus Enlightenment versus all the rest. Historically they only cooperated with each other on certain things. If none of them refused to cooperate, we would still probably be using Motif. We can come up with various reasons for why this fragmentation happened but placing all the blame for that on GNOME for going its on way doesn't make many sense when this fragmentation always existed.
> Your first link is an issue that was posted over 10 years ago and was long resolved in other area
this issue https://gitlab.gnome.org/GNOME/mutter/-/issues/217 is proof that it hasn't been resolved at all. Just reading GNOME maintainer's entitled comments ("If individual applications rely on non-standard behavior from compositors, those applications should get fixed. ", "I mean Qt should use GTK to draw decoration.") make my blood boil
I don't see how that is entitled. If you have technical arguments for why you disagree then I'd love to discuss that. Qt linking against GTK is not such a strange idea either, I believe at one point there was GTK theme engine for Qt that used GTK drawing functions to draw Qt widgets.
Again this particular cultural problem was resolved a long time. Ubuntu and XFCE and GNOME have since all aligned on this matter. I see what you are trying to illustrate, maybe it was true 10 years ago, but it's not now. Cultures can change you know.
As someone who has to occasionally work on a Gnome desktop, I can confirm that they still haven't fixed type ahead in Nautilus. Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow. (I have multiple terminal windows open and switching between them is a pain, it has to be seen to be believed).
Two big annoyances, and reading that type-ahead thread quoted above is quite an experience. Being in my 30s, it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there.
And I strongly disagree with that sentiment "it's ours, go make your own if you don't like it". Point is, I do not want to use their crappy product but I have to, due to political forces that extend from Red Hat to what my employer has installed on that computer in the lab that I have to deploy and test my software on.
If I had a choice, I would prefer to install there my simple arcane plain window manager, xterm (fast and crisp), and just enough junk so I can do my work. My Thinkpad X220 with this setup is actually pleasant to use and has required basically 0 maintenance in the last 6 years.
>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there.
Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pain, but giving up and reverting to old type-ahead behavior will only ensure that the issue never gets a proper fix. It's very hard to have a conversation about this when people assert that the real cultural problem is that a particular feature they want isn't implemented.
>Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow.
I don't assume bad faith, following Hanlon's razor it's obviously stupidity and probably a culture of arrogance engrained into a larger group (I know very little about the organization there, but there has been a lot of heated debate for years about other groups connected to redhat).
How can they otherwise ignore such an obvious, massive load of complaints with dismissive and side-stepping comments?
> Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename
Please, explain to me, what exactly is confusing about that? That it matches precisely against the beginning of the filename?
It's the exact polar opposite of confusing, and furthermore it's extremely useful in my (and many others') workflow for navigating large directory trees where I know which path I want to take in advance (obviously this is a frequent situation for all the things I'm currently working on).
And I am convinced this is not a coincidence or a pecularity of my workflow, precisely because the behaviour of type ahead is simple and predictable and also matches how humans tend to remember names, which is most likely by their initial letters.
This old and proven workflow reduces a lot of stress coming from increased visual-motoric interaction, compared to the search behaviour in Nautilus where the screen gets updated in unpredictable ways (both in terms of the files that are displayed, and also in the time lag to when they are displayed and interactable). We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. Noone working in UI would disagree that operations should aim to take less than 100ms.
(by the way I don't dispute that more involved navigation facilities are useful sometimes, for example I like to use glob-patterns that start with a * or something from time to time. However prefix search is clearly the most accurate and fastest tool for like 90% of my navigation needs).
>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. The particular suggestion for a fix was dismissed, but that's a separate thing.
>Please, explain to me, what exactly is confusing about that?
I personally find it confusing, in large folders I often don't remember the exact name. I don't think this behavior is particularly bad if the user knows what is going on, but going back to making it the default and de-prioritizing search can make it hard to find some files.
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 speed of a full search to a point that it'll match the performance of a type-ahead style search.
>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 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.
> 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, 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.
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 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.
But why would you rely on the filesystem to implement Type-Ahead? The File Manager just goes through that little list of files that it has already cached because it is displaying them anyway.
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.
Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all the 'a' files happen to be stored at the end of the directory. You would have to rescan the whole list every time you type another letter.
>you can't be helped
This is not the way to have a constructive conversation, please stop. I gave an example of how it's confusing and not predictable for some, let's discuss ways we can make it more predictable.
See, you just iterate the list or array where you store the list items that you're pushing to the screen anyway. There is nothing at all that you need to add in terms of data structure. No index whatsoever.
> linear search will cause the same arbitrary slowness.
Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each list item causes a cache miss though (which is pessimistic), then (assuming a cache miss costs 100 nanoseconds) maybe we can visit roughly 10 million directory entries with the worst possible, dumb, serial implementation. Let's say we want to ensure a reasonable target of not wasting more than 1 millisecond for the search, we can still Type-Ahead through directories containing 10000 entries with incredible performance (1ms latency).
However, if the directory contents are stored only in a slightly reasonable structure (say, the developer spent the slightest thought at it, like caching the entries in a list of array chunks or so), then, I don't know, it might be closer to 100K entries per 1ms or even approach 1 million entries per 1ms with a little optimization.
It's not a problem at all, it's less than a piece of cake.
If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.
Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.
That's why it is so fast in practice, it's instantaneous (as far as screen refreshs go) on every file manager I've ever used.
Recursive search however, does have to touch the filesystem, and does have to touch it massively for directories that contain thousands of subdirectories. That's what a "search" is, the user expects the search results to be fresh from the file system, not just scraped from a cache internal to the File Manager.
That's why recursive search is so disturbingly slow, to the point where it routinely takes seconds, or could even minutes depending on the setup (spinning drive + bad filesystem + large directory tree...).
And that is why Nautilus is basically unusable for me and a lot of other people.
By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory. Nautilus' recursive search will just pull up a completely unrelated and unexpected file from somewhere in this tree.
That means, that if I mistype, I don't get any reasonable feedback from Nautilus, but instead get a warm "thank you" and a huge diskload. It's about as depressing as browsing some websites that bombard you with ads and never show the contents you searched for.
> Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.
So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.
>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.
That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.
I don't know, I haven't tested if that is fast, but I'm assuming it does hit the disk again (since they refused to add another "feature", if "Type Ahead" even deserves that name).
Even it was fast, which I assume it is not really, I would prefer to have usable defaults without having to hunt for an obscure setting on every computer I happen to walk to, which is usually not even my own.
And as many other commenters on that gitlab.gnome thread described, I would much prefer to not to have the list filtered.
And also, I would strongly prefer not to have to disable/toggle this setting again to actually do a recursive search.
I just don't understand how it can be so hard to communicate why the existing status was so much better. And why the current status is unusable. I guess only people who never actually used that earlier feature don't understand.
But I will try that setting out next time... I hope then, that they fixed their stupid settings manager, which, at least some years ago, was some daemon that wrote to a binary database, and that frequently crashed, and then forgot some of its settings.
> That could also be solved with an intentional search option to search by prefix, maybe bound to a certain key that makes it obvious and not confusing what's happening.
The current search does just that, it's extremely confusing. It doesn't have a real search box, it is triggered as soon as you type the first key (which might be accidental), at which point it switches to a different UI state - and it's "flickering", it takes ages for the process to complete, and what your following key presses do within that timespan is very much dependent on the timing of the updates from Nautilus...
I don't understand why you keep defending it. It's a huge disaster on all fronts. It would be soooo much better if they would just protect that messy imperfect search thing by a Ctrl+F combo, and otherwise do the simple Type-Ahead thing. It might be only like 20 lines of code to change it....
At least from my read of the gitlab issues, I don't think anyone is saying that the current solution doesn't have problems. The idea is to get those problems fixed instead of ditching the current solution entirely, or making it an optional toggle (which would make even more likely that nobody fixes the issues). For me personally, I did use type-ahead but my feeling is that a really good and fast search would make it obsolete.
That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.
I don't find there is a lot that could make sense to do. I believe computers running Win95 had like 16-128MB of RAM, it wouldn't be too wasteful for a file manager to store, say, 32-64K worth of cached file entries uncompressed in RAM. That could allow for maybe 1024 file entries (depending on the attributes that should be cached for each entry - more if we're really just storing a list of zero-terminated strings and maybe directory bits), which would already cover almost all realistic use cases at the time.
So it's literally a loop over that in-RAM cache in most cases.
It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation.
Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence.
Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk.
I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.
I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue:
I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.
I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
>The amount of condescension and misplaced confidence displayed in that thread is impressive.
I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter.
>I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.
To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting.
>If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.
You're right, condescension is the wrong word. I apologize.
I do think it's misplaced confidence, though. Look at the upvotes/downvotes on the comments in the type-ahead issue thread. What the gnome developers are saying is clearly unpopular, and what the person who filed the issue and others are saying is clearly popular. Yes, of course, that's not a representative sample of all users. But was there ever a representative sample taken? What gives them the confidence to declare that the search behavior is superior, and so far superior that it must completely subsume the old behavior without even an option? No evidence is presented in that thread. They only say "This was a decision made a while ago, because people believed that searching can provide the same functionality." On what evidence is that belief based on, and what would be sufficient to overturn it? How large of a user outcry would there need to be? If this were my software and 59 people thought that one of my decisions was wrong (the largest vote count in that thread), I would start to strongly question my assumptions. No such questioning appears to be happening here.
To respond to your specific replies:
> technical review
This is a design question, not a bug. It's not about the code. The complaint is obviously valid.
> I don't think it would be much benefit for there to be a setting
Of course, anyone who will keep a setting in one position doesn't see value in there being a setting. I don't either: I'd be even happier if it always worked the old way, instead of a setting. But that's what settings are for, where there's multiple valid ways for something to work and not everyone agrees.
> technically viable
The old behavior is obviously technically viable, it worked that way for many years. So again, that's irrelevant, unless you're arguing that a setting to switch the behavior is too technically difficult, which seems implausible.
> Once the decision has been firmly made, there's little purpose to accepting further feedback after that.
Of course there is! If you don't accept further feedback, how will you ever know if your decision was wrong? This is the crux of it: a decision was "firmly" made by some developer based on who-knows-what criteria, and then no feedback is accepted, no matter how loud.
> losing users
I'm not a gnome user and never will be, but I'm forced to accept these decisions because they affect the gtk file dialogs also, and I can't exactly quit every piece of software that uses gtk.
I love how that thread is full of well-intentioned, respectful responses with deep technical knowledge and details; and the Gnome developers just won't budge.
When, finally, it becomes clear that the user demands cannot be met and Gnome is woefully inadequate as a modern desktop due to their design decisions, the final post is:
> Enough spam for today. Locking the issue.
Gnome is dead. It has been taken over by toxic developers.
I don't see why you are saying that has something to do with some attitude from GNOME. There are several Wayland compositors that don't implement that feature.
I don't follow all the Wayland compositors but Enlightenment doesn't, and Weston matters here. If somebody really wants this to become standard, implementing it in Weston should be priority.
Every compositor library I've looked at also considers this optional, e.g. mir, qtwayland, wlroots.
Considering it got xdg prefix and was included in wayland-protocols that should be as standard as it gets. Weston is barebones "reference" compositor. It's not for normal use. Mir is dead. The xdg-decoration is based on KDE's own protocol, it was later refined and pushed to wayland-protocols by wlroots devs. Now kde uses the xdg-decoration too.
>Every compositor library I've looked at also considers this optional
Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.
Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...
>application have to explicitly ask for compositor to decorate the window.
My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
>My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
Yes this is correct too. I assume it was mainly put there for GNOME :) I honestly don't fathom why you would want to be CSD only in general purpose compositor aimed for desktop users. It can make sense in specialized cases. But then again I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality.
This is all made worse with the low-level libraries and programs that don't use the gnome toolkit, end up just drawing some very primitive title bar (sometimes even without any buttons), just so people can drag the window around under gnome compositor. I guess this is the kind of end user experience gnome devs want? Nah, they'll just tell users to use only their apps instead next.
That would pave the way for GNOME shell extensions to implement window decorations (and other wayland extensions) in a way that doesn't burden upstream maintainers and make them have to support every custom wayland protocol that is only used by a handful of apps.
>I guess this is the kind of end user experience gnome devs want?
I can't speak for them but I think they would suggest that those low level libraries all collaborate on a shared library to implement nice looking CSD, that way there is no code duplication and no dependence on GNOME libraries. Another option would be for them to copy the approach used by firefox, and use dlopen to access gtk functions and draw the CSD that way when it's detected they're running in a GNOME environment. Such functionality could be put in a library and wrapped up in 1-2 function calls, to make it easy to use. SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
What actually will happen is that those developers either will ignore gnome, force the application to run under xwayland if it detects mutter, or implement a really primitive decoration that will make users open bug reports "why is the decoration so weird?". They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs".
>SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
Surely zero code in client is the "simplest". It also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?
And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so
Here is also very good technical writeup on CSDs from author of yet another display server, that's not wayland nor X11
>They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs".
I'm not sure I understand where that happened, the issue you posted is closed, and mpv has since implemented client side decorations.
>Surely zero code in client is the "simplest".
There aren't any zero code solutions, implementing xdg-decoration in the clients is more than zero lines of code. If you violate the spec and ignore the protocol requirement that the client must provide a CSD fallback then it's not a lot of code but again, you could also provide a library that allows clients to draw a prefab CSD around themselves in a very small amount of code.
>it also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?
I've seen other ways those can be achieved without SSD. Implementing a good looking and good behaving SSD that works well with every app is not simple either, and it's always going to be necessary to solve that because the core problem of making good decorations is always the same.
>And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so
The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries. This I believe is how SDL already operates under the hood for some things.
Needless to say, mpv prefers xdg-decoration if compositor supports it.
>There aren't any zero code solutions
It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_.
>The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries
Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.
I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I actually prefer them to SSD because they take less space, and they are consistent with the way the mpv decorations work in macOS.
>It's zero-code for client if the compositor actually handled the border.
With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.
>Yes and hope those libraries actually implement stable ABI.
Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.
SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur.
>This is if they actually are.
They are, you would see terrible breakage with every app if they weren't. Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
>SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur.
This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com
>Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date. There's also some other unrelated issues that can rise from this, like package maintainers having trouble to figure out what the real dependencies (or even the optional dependencies) of the application actually are, I've been there.
I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.
>That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it
I don't know what you mean, this feature was never supported in GNOME's Wayland session. It never had that existing behavior, the decorations were a private KDE extension that was picked up by mir and wlroots and then much later put into wayland-protocols. It doesn't make sense for KDE to implement a feature and then declare GNOME to be broken because some others copied that feature but GNOME didn't.
>meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be
I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.
>What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date.
The API and ABIs for those libraries are stable across major versions, they guarantee that. All Linux distros would see major breakage if they didn't, since they don't necessarily recompile the applications along with library upgrades.
>I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.
It feels like we are just going in circles now. Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".
>I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.
Yeah I don't believe KDE or GNOME are ever gonna use arcan either personally. It's users most likely will be power users only. Considering it's reaching soon full Xorg compatibility however, it's probably possible to run X11 WM inside it. That said I'd personally would have no problem with the LUA. The whole arcan philosophy is kind of reverse of wayland, taking care of all the heavy lifting, making the actual development straightforward and less boilerplatey, even more so than X11. Heck, it's even a multimedia server for audio and video. Something jack can only dream of and pipewire trying to do.
>Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".
I'm sorry I'm confused. I was responding to your suggestion earlier about making it SSD only, which I think is much less feasible than having it be CSD only. I believe I've said my position regarding the option already: If the problem is the apps don't want to write their own code for drawing window decorations, there are multiple solutions to that aside from SSD, that would require about the same amount of code in clients as SSD would. So to me it's not really an issue of the app working in mutter or not, or needing to link against gtk, or whatever. It can all be handled transparently with the right solution. Maybe eventually someone could create a version of libwayland that handles decorations transparently, with no changes needed to the apps at all.
Sure you can do everything with a library, and that's how you end up with library hell, or dependencies that will be hard to get rid of or replaced later, because how big they become or how broken the API was (e.g. fontconfig). But being the only ecosystem where that's needed is pushing some heavy boilerplate on developers. Why would games, or non-gnome apps care about decoration? There's plenty of good examples of applications where the decoration being forced on them doesn't make sense. The protocol is also standardized and gnome is the only wayland compositor that refuses to implement it, this is not the only case where gnome devs just decide to be jerks.
Things like these are why I think I'll never will be using wayland as it just breaks everyone's existing applications and workflows. wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". And I speak as someone who wrote one of the first wayland compositors, and one of the first wayland compositor libraries, which code partially still exists in wlroots.
>Why would games, or non-gnome apps care about decoration?
I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations.
>this is not the only case where gnome devs just decide to be jerks.
Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers.
>wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision".
I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.
Considering the bug report has lots of examples of why they need SSD or at least some other solution (libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native"), also including constructive feedback, but the gnome devs close it with reply "Enough spam for today. Locking the issue.", I consider them to be quite the jerks indeed.
If you don't care about drawing decorations I don't see why you would care if it looks native.
It can never really look or behave natively on Gnome since client-side decorations are more than a boarder and window buttons. It's also about having an integrated toolbar and more draggable area.
> "If you don't care about drawing decorations I don't see why you would care if it looks native."
Don't you have this completely backwards? If I want my application to have special custom decorations, then it makes sense for my application to draw the decorations. But if I want my application to have the standard decorations of the system, why should I want my application draw them?
GNOME supporting SSDs would not diminish the ability of GNOME's applications to use CSDs. So objections about the utility of CSDs imply a false dichotomy.
>libgtk doesn't work for all the use cases, e.g. vulkan, libdecoration doesn't look "native"
The solution there would be to fix gtk to support vulkan, and to fix libdecoration so it looks better.
>I consider them to be quite the jerks indeed.
Please stop, this is assuming bad faith and it's not helpful. The mutter bug tracker is an inappropriate place to give this unrelated feedback about this, when those issues you talked about are problems in libgtk and libdecoration. That's why the issue is closed. If you are just going to throw flames and don't want to discuss real technical solutions to the problem then I'm going to end the conversation.
When is it appropriate to assume bad faith? I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
Saying "you have to use our library and also fix it for free" is a dick move regardless.
If some person openly said to you that they wanted to hurt you, then I would assume bad faith. Please let someone know if that happens, in most open source projects that would probably be a code of conduct violation. I don't think people who say such things often would be very welcome in GNOME.
>I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
I'm sorry I don't get what you're saying. You can decide not to support or depend on something without (incorrectly) assuming bad faith. This stuff is all open source, nobody can force you to use a library that you're not interested to use.
> This stuff is all open source, nobody can force you to use a library that you're not interested to use.
That's not strictly speaking true, especially when politics and money get involved. Unless you're using a very loose definition of "force" which doesn't include any kind of network effect at all.
I feel your pain, I wish it were cheaper to develop software, but sadly the costs to compete with Microsoft and Apple are great. GNOME and KDE and such are already giving you all the code basically for free, I don't know what else they could do to help you out there. Accepting all feature requests that come their way is not a solution, because that usually tends to increase development costs even more.
Someone posting a fairly reasonable use case and solution problem summary, and then getting the response of "Spam. Closed." does not seem like a reasonable project by any stretch of the imagination.
Quite frankly, taking 5 minutes to put up a page saying "We will never support SSD and we acknowledge the use cases but do not care about them." would be far more forthright.
And now Qt, Electron, games , old programs will need to do extra work to satisfy a GNOME designer ego. you could always tell the window manager not to paint the decorations and you could have your own cool decorations (using a library if you want). From my point of view this looks that GNOME is force pushing their vision to all their users and all GTK users unfortunately.
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 fallback for old or non native apps) rather then force all toolkits and old apps have to implement this how they think (won't you get apps that will look like XP or OSX because you forced the app to paint the buttons). As a developer myself feels rather stupid not to just provide the SSD for old apps , really feels like "let's make this old and non native apps look and work like shit so people use my cool design.
But I could see an argument that GNOME devs are not that competent though, they implemented a shell that will kill all your apps if there is an error in an exception(on wayland)... so incompetence could explain why they are not capable to provide both SSD and CSD too.,
>> 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.
From what I have seen, I don't believe they ever intended to support those apps that didn't provide decorations. The move towards CSD was intentional for them and started 10 years ago, and supporting those CSD apps is the primary focus. This wasn't a problem for Qt apps either because Qt does provide decorations.
>> Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
In a wayland system the compositor IS the desktop shell. Window placement is not up to the application, so moving them and hence putting "handles" on them in the form of decorations is a natural fit for the compositor.
Another feature that belongs in the compositor is remembering where each application was last placed and sized and replicating that when starting them. I agree with the Wayland ideas that programs do not have the ability to warp mouse pointer or know about their environment, but once that model has been adopted there are useful features that need to move (or for decorations should move) into the compositor.
This is exactly why I’m sticking with X as long as possible. CSD makes absolutely no sense to me: under no conceivable circumstances do I want the window decorations to depend on which toolkit someone chose to use: it works out ok on macOS, I guess, but Windows/Linux each have their own issues with apps not having a consistent look and feel, and this just exacerbates that.
I've never understood all the love and excitement and attention that GNOME has gotten ever since Canonical got behind it and dropped Unity. All the cheerleading over what seem like really basic fixes that haven't been a problem on other DEs, like "now the single-threaded shell crashes to login less often! Horray!"
That's only intensified with 3.40 (Now hailed as "40" like a pop star using only their first name.) Apparently the top hot new feature is "horizontal workspaces"...mind-blowing.
I know it's fun for people to hate on GNOME but if you actually read the bug reports, the feature was not rejected. The patch was rejected in favor of a different way to implement the feature.
Having observed this for a while that often seems to be just the way Gnome works. Patches that help non-Gnome projects are held to a much higher (sometimes unobtainable) standard than patches that help members of the Gnome foundation. It seems very insular, and if you want to "scratch your own itch" as an outsider expect to take 5-20x as much effort for the same feature.
There will always be a reason why this patch isn't acceptable, despite the overall code-quality in gnome projects being... what it is. I'd bet if a Gnome app needed this feature that patch would have been quickly and quietly accepted.
Again if you actually read the bug report, it contradicts what you're saying. This patch was rejected because it created unnecessary work for terminals outside the GNOME project. The favored solution would help all terminals using that widget.
I'm a lot less sure, and the lack of clear requirements makes me even less certain.
Also things like
>adding only hooks for you means that all the other terminals get no benefit.
Makes me quite concerned since these hooks weren't just for termite, as evidenced by tilix showing interest in this patch set.
>Implementing this in VTE would mean ruling out having any flexibility in the terminal using the library. [...] an implementation inside VTE won't satisfy the use case.
I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having, and the maintainer responded with a simple "wontfix" and no more discussion.
This is kind of the thing we're talking about. One project said they needed this, another project said they'd also appreciate this feature, and instead of discussing how to make this work, setting clear requirements and the like, it took 2 years to respond to the first patch submission and then the issue was just randomly closed in the middle of a discussion.
> I'm a lot less sure, and the lack of clear requirements makes me even less certain.
If you are interested to work on this patch, it wouldn't hurt to ask the maintainer for clarification.
>as evidenced by tilix showing interest in this patch set.
That's two of them, there are other terminals that use VTE.
>I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having
I don't think so, the termite developer is making that assumption before the new patch was even completed. Additional options could be added with the suggested approach.
I feel like you're not actually reading what I posted, which is frustrating. Like this:
>Additional options could be added with the suggested approach.
doesn't make any sense when the maintainer closed the ticket with "wontfix" in the middle of the discussion? Are we both reading the same thread? It seems like we're disagreeing about some fundamental facts here, but actually reading the ticket makes the facts pretty clear?
I'm sorry, I think I could have been more clear. Yes the ticket was closed. The place to discuss options in the new approach would be in the new ticket. Even though that particular patch was rejected as a solution, newer potential solutions to the same problems could still be discussed in the new ticket. Is there some fact that I missed? That new ticket still seems to be open for discussion, and it doesn't look like they are opposed to solving the problem at hand, they're only opposed to that one particular solution that won't solve the problem in all cases.
I was also disappointed by the recent removal of static linking support in GTK [1].
It worked for a long time and now was made impossible.
The reason given was "don't want to support it".
That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mind will link to internal symbols anyway.
In my opinion, an application developer should be able to choose how to link their program; toolkit developers should not forbid one way if there isn't a good technical reason.
Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson.
If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
Many programming languages do not use Meson as a build system (examples: Go, Rust, Haskell). Some C or C++ projects may use autoconf or CMake, in which case you cannot use Meson subprojects either.
Distros use `-Ddefault_library=both` or `=static`, and let Meson install the built archive files; this is what is broken in that issue. It is surprising that this flag does nothing for GTK when it works as expected for all other Meson projects.
You could copy the archive file behind the Meson install action's back, but the maintainers' point on the issue is: "GTK isn't meant to be built as a static library" and "why do you think you need a static build of GTK4?".
If they do not want to support it, there's no guarantee the .a file will still be there tomorrow. That's what "upstream support" means.
For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk build to begin with.
I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do.
I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.
I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.
Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.
> if they could keep that libgtk_static around
Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.
> I'd be interested to hear if static linking GTK even has that many benefits
One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.
Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.
This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.
I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look:
> In reply to Daniel Micay from comment #10:
> > Implementing this in VTE would mean ruling out having any flexibility in the
> > terminal using the library. I haven't responded any more here because an
> > implementation inside VTE won't satisfy the use case.
>
> Implementing keyboard selection inside vte means that *every* terminal based
> on vte benefits; adding only hooks for you means that all the other terminals
> get *no* benefit.
This seems like a pretty shallow argument. What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? Or, stated another way, why is gnome terminal entitled to receive all the features built on top of GTK component apis used by other projects? He's stating the conclusion that VTE is the correct layer to implement the end-user highlight/selection feature without actually making an explicit case for it, and without acknowledging that there's an argument that the layer above could actually be a better location to implement the feature.
>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available?
They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
Yes that's the case Christian was making (implicitly).
Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.
I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either.
From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.
>> GTK+ is really just a toolkit for GNOME projects. All other users are secondary.
They do seem to be paying more attention to MacOS and Windows with GTK 4.
I find the notion that GTK is just for GNOME rather funny since most the GNOME apps are very basic. The Software app is notoriously crap, but that's due to a lack of people to work on it. Their map app isn't much more than a GTK window frame on google maps or something. The video player... I mean can't they adopt VLC as the "official" media player and just make the GTK version of that really nice? VLC could use a better GUI. Same for web browser, why have a GNOME one that will never be able to keep up? Why make all these little toy apps anyway? Maybe I'm conflating gnome with a small linux distro. But once they move beyond system and config tools that's what it starts to become.
GTK4 still doesn't support native rendering of window controls, so unless you're willing to create a faux "native" theme, your application will look like it doesn't belong on anything other than a Gnome desktop. I think it's idiotic and childish that the devs stick to their guns like this when there's clearly a high demand for a crucial feature like this. I dislike the project as a developer.
Don't get me wrong, I'm using a Gnome desktop for my day to day work. As a user, I enjoy the end result and I'm very happy with the way the system looks, but the absolute refusal to allow for any SSR has so far prevented me from ever seriously considering GTK for any cross-platform desktop application I'd like to write.
I don't really have a problem with the Gnome apps. There's nothing special about them, but they work and they're there. I quite like the software tool when it works, I've never managed to get Discover working for more than a few days so at least Gnome Software is stable in comparison. I also don't have any trouble with MPV for video playback. Sure, it doesn't contain a lot of power user features, but I only need it to play video files when I double click them, for anything else there's VLC.
Gnome, as a package to build a diatro around, works quite well. With a full Gnome setup, you can do almost everything you need to do on a computer. KDE is similar in that regard, although I really dislike the general UX of the KDE ecosystem for some reason.
On a side note, VLC is getting a (controversial) new UI that makes it look more slick and modern than the current design.
> GTK4 still doesn't support native rendering of window controls
Sorry, this ship has sailed, and I find that bringing "native" into an argument simply invalidates the argument.
That "native" has changed so much over the years shows that there isn't one "truth". The fact that things like Electron and Flutter and other toolkits exist clearly demonstrates that end users don't give one iota of damn whether a control is native or not.
Users don't get a choice whether a control is native or not, that doesn't mean they don't have a preference.
There's a few code editors out there integrating heavily with macOS that get featured here on HN once a while, and every time the comments are filled with people complimenting how well it works with the operating system and how nicely it integrates.
People also complain all the time about how Google sticks to material design on iPhone, even though the rest of the device follows an entirely different standard. If users really didn't care about native controls, that wouldn't be a problem at all.
When an application fits into the system, it's generally celebrated, but we've reached the point where we stopped expecting any form of integration anymore because every application is Javascript wrapped into a copy of Chromium now, if you even get a desktop version of the application in the first place.
the fact that Electron and Flutter and React Native and others exist clearly demonstrates that developers don't give one iota of a damn whether a control is native or not. These are tools of developer comfort, not of user comfort. Users don't care what you use to build your applications, as long as your app does the things they want to do well.
I don't see anyone celebrating the diversity of ways the different X buttons on their desktop looks, but I do see people enjoying the native look. To me, that seems like proof that this is a feature people are missing but not vocalising rather than that people don't care about.
In the end, people enjoy native experiences more, but native experiences cost more time and effort to produce and therefore more money. Consumers want free or cheap apps so businesses use cross-platform toolkits to reduce cost and effort, but these platforms certainly don't prove that users don't give a damn. They prove that they value having an app for cheap over having a good app for more money.
> the fact that Electron and Flutter and React Native and others exist clearly demonstrates that developers don't give one iota of a damn whether a control is native or not.
Because devs rarely have the time to do their frontend work 3-5 times over and over for each different platform. Cross-platform is the best choice, especially if you want anything to be available outside of Windows or rarely macOS.
> but I do see people enjoying the native look
I don't. It reminds me of the good old days on Windows XP when you couldn't tell a program from another because they were all "native" and looked the same. I prefer an app to keep a cross-platform look - e.g. Google's stuff looks the same on the web and on mobile, so you aren't stuck rediscovering everything when you switch platforms.
It may be that this is not implemented yet for some backends (I think it is not implemented in the Windows one) but they probably would accept a patch to implement it there if you know how to do it. Please avoid making these hostile assumptions about open source developers without having the full information. From what I have seen, there is a push recently to make GTK4 a better cross platform toolkit than GTK3 was.
Allowing for SSR is a good step, but does this also render the other controls in their native style? The window border is one important place for styling, and I'm glad GTK4 will improve the situation once it hits the mainstream distros, but as far as I can tell, the rest of the controls (buttons, textboxes, etc.) are still rendered by the application rather than by the system.
I've given GTK4 a try on Windows, and all enabling the top level decorations seem to do is to disable the window border. All controls are still Adwaita, so you'd still need to fake a Windows UI style if you want to make the application feel any kind of native.
I'm sorry, I misunderstood. I thought you meant the toplevel window controls like close, minimize, maximize. There is currently no way to make all the widgets render using the Win32 API to look like Windows widgets. You probably don't want to do that anyway, it will start to look and act really inconsistent when an application uses custom widgets.
Somebody could definitely fake a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. That to me is a much more viable option. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.
To give another perspective, that presentation is from 7 years ago and does not reflect the current state of things. The situation has improved and currently some GNOME functionality is being moved out of GTK into a new library, so GTK can focus on being its own library: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...
No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
I don't meant to say it doesn't have bugs, of course it does. Every project has bugs. As with all open source, submitting patches to fix those bugs will usually go farther than patiently waiting and hoping that another volunteer will get frustrated enough by the bug to fix it eventually. The obvious segfault bugs that affect everyone badly will tend to get fixed pretty fast, the more obscure ones that arise from weird use of widgets (and need a lot of in-depth debugging) are a harder thing to ask a volunteer to spend their time on.
I'm sorry to hear that. I'll reiterate that if someone was rude and hostile to you, that would probably be considered a code of conduct violation, and it would be appreciated if that was reported so it doesn't happen again.
Sadly, I don't know of a good alternative to GTK. Qt, being C++ is more difficult to bind to from other languages, and doesn't seem to integrate quite as well with XDG/Linux standards, unless you use KDE which is a much heavier dependency.
I wish blender's UI toolkit was separated into own library. It's pretty much the best UI I've used, and I like blender for other reasons too (it doesn't open multiple windows, popups or nags, everything's contained in it).
Immediate mode UI framework that actually supports accessibility stuff would be neat too.
And people form tribes, and tribal allegiance becomes very important to them.
In this case, both tribes (GNOME and Wayland) have a vision of the perfect way for software to work. They have each captured enough weak allegiance/users to prove to themselves that they are right. Therefore, the other side is wrong.
The problem with this analogy is that nobody knows that Gnome != wayland. Not even gnome developers know gnome != wayland. As a result, a lot of people hate wayland because of gnome's failed switch to wayland. And a lot of people hate gnome for their pretentiousness.
I find this kind of interaction interesting having used both termite and alacritty. Honestly I would have never expected maintainers of what I perceived as a fairly popular terminal to just go, welp use the other guys. This is kind of neat.
I had already been using alacritty for a while because it had wayland support, even though it has some weird bugs on my current i3 setup where creating a new terminal just creates an unresponsive window that has to be killed through htop. Other than that it's been great, and there is something satisfying about cat /udev/random and the text that flies by with GPU acceleration.
I mean I get that, but they could have just said we're no longer developing this, because we're tired or whatever. I just think it's interesting they made such a strong stand.
Does Alacritty still require you to copy terminfo to remote servers in order for backspace to work? I loved Alacritty, but copying terminfo every time gets old pretty quickly.
ncurses/terminfo is pretty fundamentally broken for the modern SSH/Tmux use-case.
For example a few years ago I tried to enable 24-bit ("truecolor") support...
For one thing, the terminfo reporting for 24-bit color support wasn't universally recognized: terminfo added an 'RGB' capability to report this, but because this was added only "recently" (as far as terminals are concerned), not all programs relied on it. For example, Emacs or Vim didn't seem to use this capability.
For another thing, there can be a mismatch between what the local and remote terminfo databases (provided by ncurses) support in terms of recognized capabilities. I had tried to copy the xterm-direct terminfo to the remote, but it wasn't recognized! Turned out it had to be compiled with the remote server's tic.
Supposedly the Terminals Working Group [1] was looking into overhauling the ancient terminfo system to support this, but there was no clear path forward. I suppose one of the problems is the massive backwards-compatibility requirement. (There is probably nothing else in the software ecosystem that requires such backwards compatibility as terminals, they literally trace their ancestry to the 19th century! [2] )
I should add that TermInfo databases, still present in Linux & macOS system today, are really interesting to compare with modern configuration systems. Nowadays we have no problem using verbose formats like TOML, JSON, YAML, or XML (plists!), because our computers are fast, have lots of storage and memory! We've traded efficiency for convenience.
Terminfo is a remnant from when computers were slow and disk/memory constrained, and it made every byte count. It was hard to efficiently encode a database of all the capabilities of the terminals at the time! The trade was in favor of efficiency at the expense of convenience.
Look up the manpage for tic, toe, infocmp & family.
alacritty's default terminal is indeed still quite foreign to most machines but it can fallback to xterm compatibility by overriding the TERM variable in your alacritty.yml:
I can just imagine me chatting with devops people:
- Hi Jeff, I know you have a todo queue from here till the next century, but please add one more item, having all our VMs, however they built, to include this set of files. I need it ASAP since without it if I log in to a server, I can't use backspace.
- What? Why? This looks like lots of work to modify each one of our 10000 deployments. It also may create some bugs and using non-standard deployment packages is time-consuming. What's wrong with plain old ssh, it works everywhere? What's wrong with your backspace, maybe I should order you a new keyboard?
- Well, ssh is fine but you see, I've got this new OpenGL super-fancy terminal emulator, and if I use it to ssh into a random server my backspace doesn't work. So if you changed every deployment we have to support it, that would be great, mmmkay? Oh and longer term I also need you to maintain a custom package for every linux distribution we might use that fixes this issue.
- Are you high? Did you check you temperature lately - maybe you have a high fever and your mental capacities are compromised?
- Hold on, Jeff, don't you think me using a fancy terminal program than can scroll 35% faster worth the effort? And it's also written in Rust! You could use it too, it's really awesome unless you need the backspace key for some weird reason.
- clickety click I've disabled all your shell access to all our servers until your mental health improves, and asked HR to issue you a week of sick days. Please get well soon.
When stepping away from KDE to sway, tried diffrent terminal emulators, but especially compared konsole, termite & alacritty. Back then (October 2020) I found alacritty to have really slow startup times on high-end machines (and got confirmation that's it's not my fault on IRC). Even massive Konsole started up faster. It also treats Wayland badly. So I settled with Termite, which I really like so far. It's sad that it's discontinued, but it's a shame that alacritty should be _the_ replacement for it.
This is a weird aside, and almost certainly not your problem since it sounds like you're using Wayland, but for anyone else reading, I had slow start up times with alacrity myself, and sometimes getting a blank window, and it turned out to be a problem with xserver providing weird numbers for my monitor when it tries to figure out DPI, and `WINIT_X11_SCALE_FACTOR=1 alacritty` solves it.
Best I can figure its not really a winit/alacritty bug, but some gremlin with my particular monitor/gpu/nvidia drivers.
Dumb question perhaps, but why does startup time matter much for a terminal emulator of the tabbed / multi-window variety? E.g. Konsole uses one process for all windows and tabs, so it only really starts when you close every terminal.
Konsole being a KDE app lets you disable internal tabbing. It's still single-process, so opening new terminals is just opening a new window from the same process.
There does seem to be some machines that Alacritty runs poorly on, but there doesn't seem to be a pattern of hardware vendor/OS or anything. On one of 3 machines I run it on (work MBP, personal laptop on Arch, personal desktop on Arch), I see the slow startups people comment on. I always assumed it was just a mac port issue, but I've seen others comment that it works fine on Mac, or that it doesn't work fine on Linux. It's not directly spec related either, as the work MBP is more powerful than my personal laptop
I’ve been on Sway for a few weeks now. Copy and paste worked immediately in Alacritty (without installing wl-clipboard), and it starts in less than 100ms with a warm cache (on a new and powerful laptop).
Personally, I can't see a difference for startup times between urxvt and alacritty, both of which are near instant on my i3 setup, but I have heard of some users experiencing long startups on mac. I'd wager theres a bug there to be found.
Urxvt normally opens in ~.2s on my ancient laptop and uses ~15M RAM. Though running it in daemon/client brings that time down to ~.04s and memory to ~1.5M per window, the possible hang/crash freezing/killing all terminals in the process probably isn't worth it.
I use it with sway on a laptop that doesn't support OpenGL well enough for other terminals, it's okay, but I miss some features, and other <indows could snoop on it. I also had to install xwayland for it.
I have no beef with gtk/gnome and the like, but I find it really funny when developers use such colorful language.
Still, as a heavy terminal user, I fail to understand what's the big deal with the choice of terminal. I have used only xterm for more than 20 years (with a short stint with gnome-terminal, and I didn't find any relevant difference). It starts instantaneously and doesn't make any fuss while it's running. Is there anything important that I'm losing?
For me the killer feature is truecolor support. 256 color is rather limiting, and with truecolor you can also use gui syntax highlighting color schemes. My actual shell runs in a neovim :term, with neovim running in alacritty, so I dont care about fancy terminal features other than rendering and colors.
I used to use tmux but the vim commands were incomplete, and even with vim integration plugins, the separate buffers and separate window splitting gets in the way. I wanted to just use the same pane splitting and navigate and use the terminal output the same way I use my text in vim. Neovims term was good for the purpose, supported all the term stuff I needed, and I could open straight into it unlike in vim, so I switched to neovim. I've had no issues with terminal
stuff since so I've no desire to switch. I also prefer the scrollback history in nvim over built in terminal emulator scrollbacks that I've used.
There is also the transparency support, colors.
What I liked with Termite was the Vim-like navigation and mode (visual mode, selection mode, insert mode). It's both useful and pratical. Also, Termite was simple, fast and small (in terms of number of lines).
It doesn't come with features we don't need.
I switched to termite when I rethought my setup to minimize my usage of the mouse. I don't think I would have changed for cosmetic features or benchmark reasons.
I used to use termite, but switched to kitty for ... reasons I can't remember now.
Does alacritty support ligatures yet? I've been using kitty because it does, but then I have issues with tmux in kitty ... I know, I want my cake and eat it
> contrary to what they blowhard they response time to keys is very large
They state explicitly on their README that they're measuring throughput, not latency. Besides that, all three of your complaints are true as far as I'm aware, and they are major dealbreakers.
> ... and not to mention it's one of the slowest (yes! contrary to what they blowhard they response time to keys is very large) terminals out there.
This is intriguing to me. You're not the first I've seen complaining about this, so there must be something to it.
But in my case, on a fairly low-end machine, what I type shows up instantaneously[0] on the screen, even when the CPU is busy compiling.
I'm running an i5-6500 with integrated hd 530 graphics and a 4K screen. I use i3 (so X11) and Picom with a bunch of effects.
---
[0] I have a mechanical keyboard, and if I push the key all the way down, I hear the sound of the key bottoming out after I see the character on the screen.
Nothing with computers is instantaneous. I strongly suspect that there is at least 15ms of latency in your setup, and probably much more. Different people have different sensitivity to latency, just because you don't notice it doesn't mean it isn't there.
Well, you're right, technically. But in that case, all terminal applications have latency, so is your point that the parent's complaint is unfounded?
In these kinds of discussions, the talk is usually about perceived latency not absolute latency. If it feels like there's basically none, then it's good enough. It doesn't mean there's absolutely 0.0 ns latency.
> Different people have different sensitivity to latency
This I can get behind. But I doubt that what seems instantaneous to me would seem "terribly long a time" to someone else, especially since I look specifically for this. As you pointed out, no terminal app has absolute 0 latency, so if one particular software has terrible latency compared to another one, the difference would have to be pretty huge.
Do note that I'm not talking about being bothered by the latency. I know a lot of people who will notice the latency when pointed out to them, but they don't really care. Personally, I hate when things lag, even if I may happen to have a worse perception than average (don't actually know if that's the case).
> But in that case, all terminal applications have latency, so is your point that the parent's complaint is unfounded?
All terminals have latency, but that doesn't mean that all terminals have equal latency. Point was that anecdotes about subjective instantaneity are pretty meaningless, especially without any reference point.
It would be much more meaningful to substantiate the discussion with actual data; the measurements done by danluu are one example https://danluu.com/term-latency/
Of course there can be quibbles about the specific methodology, but its still much better than having no data at all. Especially for something that is as measurable as latency is.
In general if you claim something is fast, back that claim up with some numbers.
Some applications using OpenGL or Vulkan and Wayland compositing end up with latency related to one or two frames of the screen refresh. Which means that characters appear onscreen much faster on a 144 or 240 Hz display.
Not really a surprise but something to be aware of.
kitty has lower latency than Alacritty. Alacritty is optimized for throughput and is the best for that, but I don't understand who would prefer throughput over latency in a terminal setting.
I switched from kitty to wezterm. I don't have an official benchmark like the below [1], but low latency is an explicit goal of the project and it seems on par with kitty.
What issues? Attaching to a session created in another emulator? I tried switching from kitty to alacritty and it was definitely not worth it, kitty's docs, and features, are just absurdly better.
I've been running kitty and tmux for over a year now and if I have any issues with tmux I've been inured to them. Oh wait, I think a lot of kittens don't work and that might be related? What problems do you have?
Alacrity works well on MacOS also. It gives you enough control that you can send meta (command) properly to readline, emacs, and whatever else is running in the terminal while letting some command chords be handled outside the terminal (e.g., command-tab, copy/paste, rectangle).
Command-tab is slightly broken for me. When Alacritty is full screen, command-tab often switches to the desktop instead of Alacritty. It’s my only complaint, but it’s pretty annoying and disruptive. https://github.com/alacritty/alacritty/issues/3659
I’ve tried alacritty a few times and found it not ready for daily use. My work has me on Windows and I’ve been pleasantly surprised with the newer Windows Terminal app.
Uses the GPU for rendering (iirc the basis for alacritty’s performance claims).
I wouldn't go that far. Most distros have switched to GNOME on Wayland by default, and Fedora 34's KDE spin has switched to Wayland too. Sway is niche but not insignificant anymore (I use Sway).
X11 is definitely not dead yet, though. FLTK programs, Wine, and some game engines still require X11.
I keep going back to X11 for various reasons. I was close last time, but google chrome still has various problems with wayland if one has more than one window open. I know that this is a chrome bug, but it ruins the experience and for this use case I can not use Firefox.
Same. I'm slowly switching from GNOME to Sway, but I'm not going 100% until Chromium's Wayland support is better, since I spend 98% of my time in Chromium or VS Code. The good news is they are actively working on it since ChromeOS will (does?) use Wayland so they can split the Chromium browser from the Chromium that runs the OS shell.
TL;DR: Drag and drop involving chromium or electron windows has been buggy. wlroots/sway has not implemented _NET_CLIENT_LIST_STACKING, and both the fallback code inside Chrome/Chromium and the way sway has been stacking Xwayland windows have been buggy. A patch has been submitted to Chromium to fix the faulty fallback, the sway bug will be fixed, and wlroots will also support _NET_CLIENT_LIST_STACKING, so by the time the next sway release comes out everything should be ironed out.
Maintenance on the xorg server code base has all but ground to a halt. The next release is nowhere to be seen. Eventually Red Hat just said fuck this shit and started rolling xwayland-only releases.
+1 for Foot. Much faster than Alacritty (esp. with PGO), supports ligatures and colored emojis (and any charset [inc. emojis] uses font fallback at a configurable custom size so you can get emojis to fit in one cell), and also supports an optional client-server mode in which all terminals share the same processes to massively improve startup times.
It's also much faster to build than Alacritty on a low-end machine, which is appreciated.
RiR wouldn't be a meme and so controversial if the Rewriters didn't often rewrite common tools strongly opinionated, excluding everyone from a potential merge discussion of new features.
I have been using Tilix[0] - pretty happy with it. Nice tab features, profiles/theming, quick startup, excellent rendering. Nothing to complain so far.
Tilix is an excellent terminal emulator, but it's not adding any new features until it gets a new maintainer. Anyone familiar with the D programming language (similar to C/C++) is welcome to apply.
I have never used Termite but I used Terminator many years for more features but mostly the window splits, I have also done a lot of Rust development so when I heard about Alacritty I gave it a test drive. One thing I did was run `find /` with Terminator and Alacritty side by side and Alacritty finished about an order of magnitude faster.
So I switched to tmux for tiling and use Alacritty now, not that I regularly dump so much text so quickly on the terminal but I was impressed with the engineering. I have been happy with it.
Is there any indication of the energy impact using a GL context to render plain old text? These concepts seem incompatible in the context of a laptop, and who needs GL here when the bottleneck is biological. One of my favourite working modes is shutting down everything and just hacking away in vim, partly for distraction management but primarily because of battery.
There is at lease one open issue¹ with the clipboard crate that causes a high amount of wakeups (under Wayland at least). Whatmore, the wakeups scale with the number of terminals open. The project is ruthless about performance[latency] regressions, but not so much about performance[energy] overhead.
Yes, which seems very very weird to me. When it launched they immediately marketed it as super fast, but just typing into it had noticeable latency. Throughput is great if a command is producing massive amounts of output, but it's not like you're going to read at that speed. I can usually pipe into less instead.
I hope latency has improved to be much better. Haven't tried it in a few years.
I'd be incredibly surprised if mobile power management did not account for the difference between "blitting array of 2D pixels" and "running massively parallel shader". Even if not done for energy conservation, it might be for TDP profile.
Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory.
In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?
These days a lot (most ?) of rendering toolkits are GPU accelerated, including things like your browser - you'd likely hit those issues with other apps as well then.
You could hit drivers bugs for sure, but that means in your particular config GL will be worse so you need to test, doubt this translates to a general scenario.
I think a lot of people assume because your default GL setup is to use immediate mode to re-render everything at refresh rate that's the only way to do rendering and that's why GL apps get the reputation for being power hungry.
Well it can't be known for certain without performing benchmarks to test it, but I would presume a hardware-accelerated renderer is far more efficient than a software-based one.
It's technically possible to create a wayland compositor without GL/GLES/Vulkan, but only SHM clients will work, unless you go with mixed approach which wouldn't be zero-copy. (Or of course you could also use llvmpipe or something to do software emulation of GL, but that will be very slow and ineffective). I'm not aware of any such wayland compositor however.
This is a beautiful example of FOSS culture at work.
In what world would corporate, closed-source software engage in this kind of earnest truth-telling without the propellers of mergers, acquisitions, or takeovers?
Used to use termite for years before moving to alacritty, I'm glad it has keyboard hints navigation now. Thanks thestinger for the great terminal emulator.
hyperlinks-- programs can emit an escape code that would be interpreted as hyperlink. so you can do `ls --hyperlink=auto` (yes, it's so useful that a coreutils util has included it) and click on the hyperlink to open the file using xdg-open.
I’ve tried xterm, terminator, termite, urxvt, st, kitty, and gnome-terminal but Alacritty is my go to because of it’s speed and simplicity. Alacritty has no menus, no tabs, no scroll bars, and configuration is done via a single config file. I pair it with tmux. The only minor thing I wished Alacritty would support is font ligatures.
I liked termite because of the keyboard based selection mode and the minimal functionality. Wasn't aware that Alacrity supports that now. Alacrity is my choice for Windows, but unfortunately I cannot use it on WSL2, because it needs GLX features, which are not available. I hope I can soon use the new WSL2 graphics support
I’m confused by what you’re saying here, because I can’t think of any particularly compelling reason to run Alacritty inside WSL beyond ease of installation.
You can run the Windows Alacritty from WSL2 with no trouble (like any other .exe file), and you can run WSL stuff inside Alacritty.
Admittedly spawning something WSL-side inside Alacritty from the WSL side becomes a smidgeon more complicated, because you’ll need to rewrite any `alacritty --command …` to run it through wsl.exe or your distro-specific launcher. But even if you need to do that, that should be pretty much set-and-forget with a little wrapper shell script.
I tried to switch maybe a year ago, but alacritty was measurably slower and heavier than termite, so I dropped it.
Now I concede that I did not personally notice any difference, aside from the usual config changes, but surely there is still a case for a CPU side VTE based terminal? Or am I wrong?
Alacritty is very slow on startup, I use a tiling manager and spawn new terminals frequently so this is very noticeable. I use st which is super fast and has everything I need available through patches
Can you quantify that? Are you talking multiple countable seconds to open? It seems to open instantly for me but I can't tell if your talking about 0.5s or 5s being slow.
tmux doesn't cut it for me. I use tmux on remote machines and really don't want to nest tmux sessions, and it looks like tabbed will spawn an alacritty process per tab.
Can you group tabs in Sway? I have a lot of tabs open and each window represents a specific group. I navigate primarily by keyboard, and having grouped tabs keeps me organized.
I'll give Kitty a shot. I've been using konsole recently and it works for the most part, except when sending files through picocom. ctrl-a+s pops up a message about terminal flow control even though the keystroke is intercepted by picocom and not used for flow control.
Yes. Sway represents the world as a tree. You can nest containers as you like. e.g. H[firefox T[Alacritty Alacritty]] describes a horizontal split with Firefox on the left side and a tab container of two Alacrittys on the right side. If you want H[S[T[T[Alacritty Alacritty] H[Alacritty Alacritty] Alacritty] V[Alacritty Alacritty]] Alacritty], go wild!
When you subsequently want to move a group of things around, you can focus the parent container and move it around as though it were a window. (Out of the box, Super+a is `focus parent`, though curiously there’s no `focus child` binding in the default config, so to return to a child you pretty much have to focus a sibling or another container, or use the mouse.)
For what it's worth, my habit in i3/sway is usually to represent "groups of tabs" as single tabbed containers on different desktops, and rarely to have multiple tabbed containers next to each other on a single desktop. Although occasionally I do the latter, too.
I don't know why would anyone use Alacritty. Don't tell me that tabs aren't important, and don't tell me to "use tmux" as a replacement. Plus, Alacritty is slow as fuck compared to every other terminal I've used (I haven't used iTerm2). Its only selling point is "written in Rust" which isn't enough for me.
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"
And please note that Mac OS is NOTORIOUS for having bad/buggy/outdated support for OpenGL (which alacritty extensively uses), and this is a legitimate frustration that many developers in the low-level graphics domain have. It’s already really maddening for the devs, the contributors shouldn’t nag too much about it (I understand people outside the domain might genuinely not know this - but it’s always good to read some of the previous Github issues before filing your own, to learn the general “vive” among the core contributors)
No it wasn't. It was bad.
Granted, the original bug report could have been a bit clearer, but the reporter was more than happy to help out and promptly responded to the questions and even some checking of the RGB of the colour in question, and then offered to open up a new related issue. But the dev in this case took the worse interpretation of the reporter's intent and claimed they were rude, or disrespectful or whatever, and took their report as an attack on their choice of default palette. I can imagine that the reporter was surprised and puzzled to be called "entitled" here.
Sounds a little bit entitled to me..
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].
[1]: https://www.color-hex.com/color/feff00
I went and looked at the issue, and the title is not "colors are wrong" but it is "Colors don't look as they should". Interesting how everyone comes away with what they this was said. Says a lot about the dev who responded, really.
This says a lot about me, but I empathize with that. That the reason I strive to be perfect in everything is that I feel like I'm under attack. Illogically, because I was, as a child, continually insulted.
It's a shitty way of living, trust me. But I get it.
https://github.com/alacritty/alacritty#installation
Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.
It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.
I used Kitty for a while instead, which is very similar. More recently I've been trying out Foot: https://codeberg.org/dnkl/foot
Basically every other "simple" terminal I've found behaves better -- xterm, urxvt, konsole, even iTerm2.
I have no idea how they can claim "fastest".
> Benchmarks so far have just involved running find /usr on my Linux system with Alacritty, st, and urxvt, and on macOS against Terminal.app and iTerm2.
https://github.com/alacritty/alacritty/issues/289#issuecomme...
They decided to continue marketing it as the fastest terminal emulator anyway.
> > Correct accuracy of first sentence in README #798
> >
> > As documented in #289 it's not currently the fastest-- only a small number of terminals running a single task for initially benchmarked.
>
> nah
https://github.com/alacritty/alacritty/pull/798
To be clear, we’re talking about Kovid here, right?
Can we assume people are acting in good faith until we have reason to think otherwise? As highlighted by the green-is-yellow issue, it is OK to simply say, "Understood. The color scheme has been previously discussed, is popular and isn't currently considered for change. But you can configure it yourself by <link-to-documentation>..." The accusation of an entitled attitude appears a bit of a leap to me too. To be fair, while a tad rude in tone, the dev's second post is an improvement.
Or perhaps, "We don't have a lot of resources for this level of detail. Sorry." (Open-source honesty?) Or even, "If you wrote a patch taking the values from rxvt it would be considered but possibly rejected after discussing policy with lead devs."
The two first comments of the maintainer in the thread mentioned the configurability of alacritty, giving soft hints that maybe the user should just set it privately to comfort their private taste. I feel that discussions about taste choices can sometimes be the most tiring ones, because often people have different tastes and you can't give rational arguments why you like one taste more. That's why there is configurability in the first place, maintainers recognizing that people have a diversity of personal tastes. You can't ever do it right by everyone. Maybe the maintainer should have communicated that better more early on, but they did communicate something along those lines later on. They were still around to explain themselves.
What are the devs supposed to do? Debug the proprietary driver? They might not even own a Mac device because they give the software away for free and don't want to spend thousands on their spare time hobby. OpenGL drivers, regardless of manufactuer btw, have massive issues with bugs. They were so serious in fact, that the original glium maintainer gave up maintaining it. Having taken over emergency maintainership of glium, the way I deal with such issues now is to close them with a response that PRs are welcome (unless my specific config can reproduce them).
Also, extremely often you see open source as well as proprietary software on hn that's mac only. Isn't that, too, maintainers saying "switch operating systems"?
As you said, "The maintainers don't own macs; PR's welcome. You might also file an issue with Apple." would be a perfectly reasonable response.
Apple docs are some of the worst on the planet. It's like they intend on making the barrier to entry high so once you are in the club you somehow have prestige.
No, you have Stockholm syndrome.
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.
It's a curious hill to die on, so to speak.
You're really not willing to use an excellent piece of software because one time you saw a dev dismiss someone who didn't like the default color scheme? How is that not even more petty?
You sure aren't running out of creative synonyms to make drama over a pretty insignificant incident.
> "The default green is 0xb9ca4a [which is actually yellow](https://www.color-hex.com/color/b9ca4a)."
While I agree that 0xb9ca4a is not a good choice for a default green, I disagree with the claim that it's yellow. In fact, the website that user cited for their "which is actually yellow" claim doesn't say what that user claims. That website says:
> Color #b9ca4a contains mainly GREEN color.
To my eyes, it's puke green. And the shades and tints of this color shown on that page make it clear that this is green.
It's equally "toxic" imo to torpedo a project, and all the efforts because of some bad communication.
Sure, the dev did fly off the handle initially but if you read the whole tread, he comes around, and actually keeps responding - in other words he cares.
We already seldomnly argue the point anymore. Now it seems we don't even evaluate software at core value anymore, rather we must know the personality of its creators.
I doubt my comment is going to torpedo anything. But I didn't put down alacritty for "personality" reasons. There are a lot of excellent terminal emulators out there. This github issue wasn't an isolated incident, and if the devs are regularly this hostile there's bound to be lots of issues like this that won't be fixed. Especially since my OS is only nominally supported.
I wish Kitty had more hype going for it, it deserves it more IMO.
I'd be insulted too. Wording choices matter.
Frankly, that is a total misrepresentation to call that verbal abuse. What it is, is frustrated devs dealing with a rudely worded and pointless issue.
That issue is literally just trying to start a bikeshed about a color in a standard color scheme they chose as the default. It could not be more useless. On top of that, they try to start that bikeshed by simply saying "the colors are wrong" and pointing to a terrible screenshot.
Open source devs have to deal with a ton of unproductive garbage issues that they are not paid to deal with which risks engendering total burnout. It is way too much to ask them to treat every single person with kid gloves especially when they are opening issues from a place of disrespect.
Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.
I remember when the Gnome desktop was exciting; there were frequently new apps to try, things pushing niche workflows that the Gnome team didn't consider.
That all stopped with Gnome3.
On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly. The laptop my partner uses at home is a slightly old Thinkpad I put Fedora on last year and it took her about 20 minutes to work out to use everything (less time than she took on a Mac).
I think the Gnome developers have been pretty hostile to outside input and could have done a better job. But the fact that they've had a clear direction and haven't implemented everybody's personal preference has resulted in a coherent result without unnecessary cruft.
It works like Windows, which they are accustomed to.
Edit: I don't get why this was down-voted, but OK.
I think Plasma and Cinnamon also belong in this group.
Gnome 3 had a HUGE affect on desktop environments, due to Gnome 2's popularity.
One thing I will say is that it's not just down to the desktop - all the main pieces need to be good and compatible and configured correctly for an overall smooth and intuitive experience. Gnome on Fedora does that.
To borrow a term or two, it's developed in the bazaar, but run like the cathedral. Maybe an open-air cathedral.
Firefox is another project that I'd put under this label. All the important discussions happen in the back rooms, and by the time something universally unpopular hits the bug tracker, it's too late for users or the wider dev community to have any say.
Very interesting. Thanks.
Are you familiar with Bryan Cantrill's "right to fork, but not the power" observation?
It deeply influenced me. Alas, I didn't find his post-mortem until after I already joined an FOSS effort (kauli.org). Which failed. For so many reasons. Neutering us contributors probably being foremost.
Copypasta:
OpenSolaris challenges • That certain critical bits had to remain proprietary made forking the operating system technically difficult... • And that virtually all Solaris implementation knowledge lived within Sunʼs walls made it a practical impossibility • The community had the right to fork, but not the power • This led down the primrose path to open source governance: governing boards, elections, constitutions • And because all development on the system realistically required copyright assignment to Sun, OpenSolaris (sadly) remained a Sun puppet • Worse, some among Sunʼs middle management fancied themselves puppeteers...
https://www.usenix.org/legacy/events/lisa11/tech/slides/cant...
That's not been my experience at all. The outrage machine on social media tends to spread around the small handful of patches that do get rejected so they can get angry about it, but they never talk about the other thousands of patches that do get accepted. Go look through all the other MRs on the gitlab if you don't believe me. Yes sometimes patches get rejected, it happens in any open source project.
For example take a look here: https://trac.transmissionbt.com/ticket/3685#no1
>I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.
Gnome kind of goes off and does it's own thing without thinking about or cooperating with other open source developers. [Here's](https://gitlab.gnome.org/GNOME/mutter/-/issues/217) an example where they make a technical decisions that massively inconveniences a bunch of well known open source projects like GLFW and SDL (low-level cross-platform GUI toolkits).
Gnome are not good citizens of the open source commons, they do things that make it much harder to create cross-platform/cross-DE apps. GTK used to be fairly vendor neutral, it was the "GIMP ToolKit", not the Gnome toolkit. It worked with any desktop environment you chose to use. Since then they've been making the toolkit much more dependent on Gnome specific features and actively been making the lives of everyone else more difficult.
Also there are a lot of controversial decisions that make developers lives annoying, like [refusing to implement classic typeahead](https://gitlab.gnome.org/GNOME/nautilus/-/issues/244) instead relying on their search daemon which is really annoying for a lot of developers, and of course makes running a GTK app in a non-gnome desktop much worse. There are a few outstanding issues that make it annoying for developers to work with file paths under Gnome.
So yeah, they've burnt a lot of developer good will and seem intent on continuing that trend. LXDE even switched to QT instead. Really made it so that the linux desktop is less of a stable/reliable thing to develop for.
---
https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linu...
By refusing to cooperate with other open source projects they're really making it harder for open source developers to get things done and make new apps. Instead of having a common platform we now have gnome and everyone else, and there really are a lot of very obvious examples of that happening over the years.
The second two links you're posting are again, the exception, not the rule. The vast majority of patches are accepted, you just happened to stumble across two of the contentious ones that got a big outrage response on reddit. Please go look at the other thousands of issues and MRs against GTK if you don't believe me, it's not just GNOME people filing those.
I would say I thoroughly agree with the last article you posted. There has never been a "Linux platform." It was always Motif versus KDE versus GNOME versus Enlightenment versus all the rest. Historically they only cooperated with each other on certain things. If none of them refused to cooperate, we would still probably be using Motif. We can come up with various reasons for why this fragmentation happened but placing all the blame for that on GNOME for going its on way doesn't make many sense when this fragmentation always existed.
this issue https://gitlab.gnome.org/GNOME/mutter/-/issues/217 is proof that it hasn't been resolved at all. Just reading GNOME maintainer's entitled comments ("If individual applications rely on non-standard behavior from compositors, those applications should get fixed. ", "I mean Qt should use GTK to draw decoration.") make my blood boil
What I'm describing is a cultural problem. If you don't think that link is illustrative than you don't understand what it is I'm trying to illustrate.
Two big annoyances, and reading that type-ahead thread quoted above is quite an experience. Being in my 30s, it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there.
And I strongly disagree with that sentiment "it's ours, go make your own if you don't like it". Point is, I do not want to use their crappy product but I have to, due to political forces that extend from Red Hat to what my employer has installed on that computer in the lab that I have to deploy and test my software on.
If I had a choice, I would prefer to install there my simple arcane plain window manager, xterm (fast and crisp), and just enough junk so I can do my work. My Thinkpad X220 with this setup is actually pleasant to use and has required basically 0 maintenance in the last 6 years.
Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pain, but giving up and reverting to old type-ahead behavior will only ensure that the issue never gets a proper fix. It's very hard to have a conversation about this when people assert that the real cultural problem is that a particular feature they want isn't implemented.
>Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow.
Has this been reported?
How can they otherwise ignore such an obvious, massive load of complaints with dismissive and side-stepping comments?
> Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename
Please, explain to me, what exactly is confusing about that? That it matches precisely against the beginning of the filename?
It's the exact polar opposite of confusing, and furthermore it's extremely useful in my (and many others') workflow for navigating large directory trees where I know which path I want to take in advance (obviously this is a frequent situation for all the things I'm currently working on).
And I am convinced this is not a coincidence or a pecularity of my workflow, precisely because the behaviour of type ahead is simple and predictable and also matches how humans tend to remember names, which is most likely by their initial letters.
This old and proven workflow reduces a lot of stress coming from increased visual-motoric interaction, compared to the search behaviour in Nautilus where the screen gets updated in unpredictable ways (both in terms of the files that are displayed, and also in the time lag to when they are displayed and interactable). We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. Noone working in UI would disagree that operations should aim to take less than 100ms.
(by the way I don't dispute that more involved navigation facilities are useful sometimes, for example I like to use glob-patterns that start with a * or something from time to time. However prefix search is clearly the most accurate and fastest tool for like 90% of my navigation needs).
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. The particular suggestion for a fix was dismissed, but that's a separate thing.
>Please, explain to me, what exactly is confusing about that?
I personally find it confusing, in large folders I often don't remember the exact name. I don't think this behavior is particularly bad if the user knows what is going on, but going back to making it the default and de-prioritizing search can make it hard to find some files.
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 speed of a full search to a point that it'll match the performance of a type-ahead style search.
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.
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.
>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.
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.
>you can't be helped
This is not the way to have a constructive conversation, please stop. I gave an example of how it's confusing and not predictable for some, let's discuss ways we can make it more predictable.
> linear search will cause the same arbitrary slowness.
Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each list item causes a cache miss though (which is pessimistic), then (assuming a cache miss costs 100 nanoseconds) maybe we can visit roughly 10 million directory entries with the worst possible, dumb, serial implementation. Let's say we want to ensure a reasonable target of not wasting more than 1 millisecond for the search, we can still Type-Ahead through directories containing 10000 entries with incredible performance (1ms latency).
However, if the directory contents are stored only in a slightly reasonable structure (say, the developer spent the slightest thought at it, like caching the entries in a list of array chunks or so), then, I don't know, it might be closer to 100K entries per 1ms or even approach 1 million entries per 1ms with a little optimization.
It's not a problem at all, it's less than a piece of cake.
That's why it is so fast in practice, it's instantaneous (as far as screen refreshs go) on every file manager I've ever used.
Recursive search however, does have to touch the filesystem, and does have to touch it massively for directories that contain thousands of subdirectories. That's what a "search" is, the user expects the search results to be fresh from the file system, not just scraped from a cache internal to the File Manager.
That's why recursive search is so disturbingly slow, to the point where it routinely takes seconds, or could even minutes depending on the setup (spinning drive + bad filesystem + large directory tree...).
And that is why Nautilus is basically unusable for me and a lot of other people.
By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory. Nautilus' recursive search will just pull up a completely unrelated and unexpected file from somewhere in this tree.
That means, that if I mistype, I don't get any reasonable feedback from Nautilus, but instead get a warm "thank you" and a huge diskload. It's about as depressing as browsing some websites that bombard you with ads and never show the contents you searched for.
So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.
>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.
That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.
Even it was fast, which I assume it is not really, I would prefer to have usable defaults without having to hunt for an obscure setting on every computer I happen to walk to, which is usually not even my own.
And as many other commenters on that gitlab.gnome thread described, I would much prefer to not to have the list filtered.
And also, I would strongly prefer not to have to disable/toggle this setting again to actually do a recursive search.
I just don't understand how it can be so hard to communicate why the existing status was so much better. And why the current status is unusable. I guess only people who never actually used that earlier feature don't understand.
But I will try that setting out next time... I hope then, that they fixed their stupid settings manager, which, at least some years ago, was some daemon that wrote to a binary database, and that frequently crashed, and then forgot some of its settings.
> That could also be solved with an intentional search option to search by prefix, maybe bound to a certain key that makes it obvious and not confusing what's happening.
The current search does just that, it's extremely confusing. It doesn't have a real search box, it is triggered as soon as you type the first key (which might be accidental), at which point it switches to a different UI state - and it's "flickering", it takes ages for the process to complete, and what your following key presses do within that timespan is very much dependent on the timing of the updates from Nautilus...
I don't understand why you keep defending it. It's a huge disaster on all fronts. It would be soooo much better if they would just protect that messy imperfect search thing by a Ctrl+F combo, and otherwise do the simple Type-Ahead thing. It might be only like 20 lines of code to change it....
Hell, the whole 9x era of Windows would run laps around all these "modern" desktops.
So it's literally a loop over that in-RAM cache in most cases.
It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation.
Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence.
Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk.
I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.
I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.
I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter.
>I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.
To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting.
>If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.
I do think it's misplaced confidence, though. Look at the upvotes/downvotes on the comments in the type-ahead issue thread. What the gnome developers are saying is clearly unpopular, and what the person who filed the issue and others are saying is clearly popular. Yes, of course, that's not a representative sample of all users. But was there ever a representative sample taken? What gives them the confidence to declare that the search behavior is superior, and so far superior that it must completely subsume the old behavior without even an option? No evidence is presented in that thread. They only say "This was a decision made a while ago, because people believed that searching can provide the same functionality." On what evidence is that belief based on, and what would be sufficient to overturn it? How large of a user outcry would there need to be? If this were my software and 59 people thought that one of my decisions was wrong (the largest vote count in that thread), I would start to strongly question my assumptions. No such questioning appears to be happening here.
To respond to your specific replies:
> technical review
This is a design question, not a bug. It's not about the code. The complaint is obviously valid.
> I don't think it would be much benefit for there to be a setting
Of course, anyone who will keep a setting in one position doesn't see value in there being a setting. I don't either: I'd be even happier if it always worked the old way, instead of a setting. But that's what settings are for, where there's multiple valid ways for something to work and not everyone agrees.
> technically viable
The old behavior is obviously technically viable, it worked that way for many years. So again, that's irrelevant, unless you're arguing that a setting to switch the behavior is too technically difficult, which seems implausible.
> Once the decision has been firmly made, there's little purpose to accepting further feedback after that.
Of course there is! If you don't accept further feedback, how will you ever know if your decision was wrong? This is the crux of it: a decision was "firmly" made by some developer based on who-knows-what criteria, and then no feedback is accepted, no matter how loud.
> losing users
I'm not a gnome user and never will be, but I'm forced to accept these decisions because they affect the gtk file dialogs also, and I can't exactly quit every piece of software that uses gtk.
When, finally, it becomes clear that the user demands cannot be met and Gnome is woefully inadequate as a modern desktop due to their design decisions, the final post is:
> Enough spam for today. Locking the issue.
Gnome is dead. It has been taken over by toxic developers.
Can you list some that aren't weston or dead projects?
Every compositor library I've looked at also considers this optional, e.g. mir, qtwayland, wlroots.
>Every compositor library I've looked at also considers this optional
Because that's the point of it. If compositor doesn't implement it, application would have to fallback to CSD (however very inconvenient for many apps, or users who suddenly will not see a decoration due to purely _technical reasons_), and even when it's implemented, application have to explicitly ask for compositor to decorate the window.
>application have to explicitly ask for compositor to decorate the window.
My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.
Yes this is correct too. I assume it was mainly put there for GNOME :) I honestly don't fathom why you would want to be CSD only in general purpose compositor aimed for desktop users. It can make sense in specialized cases. But then again I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality.
This is all made worse with the low-level libraries and programs that don't use the gnome toolkit, end up just drawing some very primitive title bar (sometimes even without any buttons), just so people can drag the window around under gnome compositor. I guess this is the kind of end user experience gnome devs want? Nah, they'll just tell users to use only their apps instead next.
I would not say this is true, GNOME just handles extensibility differently. If you want to help with this, please consider working on this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1053
That would pave the way for GNOME shell extensions to implement window decorations (and other wayland extensions) in a way that doesn't burden upstream maintainers and make them have to support every custom wayland protocol that is only used by a handful of apps.
>I guess this is the kind of end user experience gnome devs want?
I can't speak for them but I think they would suggest that those low level libraries all collaborate on a shared library to implement nice looking CSD, that way there is no code duplication and no dependence on GNOME libraries. Another option would be for them to copy the approach used by firefox, and use dlopen to access gtk functions and draw the CSD that way when it's detected they're running in a GNOME environment. Such functionality could be put in a library and wrapped up in 1-2 function calls, to make it easy to use. SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
https://github.com/mpv-player/mpv/issues/3646
>SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.
Surely zero code in client is the "simplest". It also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?
And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so
Here is also very good technical writeup on CSDs from author of yet another display server, that's not wayland nor X11
https://arcan-fe.com/2018/01/27/argumenting-client-side-deco...
I'm not sure I understand where that happened, the issue you posted is closed, and mpv has since implemented client side decorations.
>Surely zero code in client is the "simplest".
There aren't any zero code solutions, implementing xdg-decoration in the clients is more than zero lines of code. If you violate the spec and ignore the protocol requirement that the client must provide a CSD fallback then it's not a lot of code but again, you could also provide a library that allows clients to draw a prefab CSD around themselves in a very small amount of code.
>it also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?
I've seen other ways those can be achieved without SSD. Implementing a good looking and good behaving SSD that works well with every app is not simple either, and it's always going to be necessary to solve that because the core problem of making good decorations is always the same.
>And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so
The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries. This I believe is how SDL already operates under the hood for some things.
Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186
Needless to say, mpv prefers xdg-decoration if compositor supports it.
>There aren't any zero code solutions
It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_.
>The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries
Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.
>It's zero-code for client if the compositor actually handled the border.
With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.
>Yes and hope those libraries actually implement stable ABI.
Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.
I'm not exactly sure how they look like currently, as I don't use gnome (nor wayland), but that was the latest PR regarding CSD I was able to find.
>With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.
Sure in wayland's case. But this is only because both systems needs to be supported. But it could be even more simpler with SSD only.
>Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.
This is if they actually are. With dlopen/dlsym, you effectively get rid of all type-checking making the code more fragile.
>This is if they actually are.
They are, you would see terrible breakage with every app if they weren't. Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com
>Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.
What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date. There's also some other unrelated issues that can rise from this, like package maintainers having trouble to figure out what the real dependencies (or even the optional dependencies) of the application actually are, I've been there.
I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.
>That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it
I don't know what you mean, this feature was never supported in GNOME's Wayland session. It never had that existing behavior, the decorations were a private KDE extension that was picked up by mir and wlroots and then much later put into wayland-protocols. It doesn't make sense for KDE to implement a feature and then declare GNOME to be broken because some others copied that feature but GNOME didn't.
>meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be
I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.
>What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date.
The API and ABIs for those libraries are stable across major versions, they guarantee that. All Linux distros would see major breakage if they didn't, since they don't necessarily recompile the applications along with library upgrades.
It feels like we are just going in circles now. Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".
>I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.
Yeah I don't believe KDE or GNOME are ever gonna use arcan either personally. It's users most likely will be power users only. Considering it's reaching soon full Xorg compatibility however, it's probably possible to run X11 WM inside it. That said I'd personally would have no problem with the LUA. The whole arcan philosophy is kind of reverse of wayland, taking care of all the heavy lifting, making the actual development straightforward and less boilerplatey, even more so than X11. Heck, it's even a multimedia server for audio and video. Something jack can only dream of and pipewire trying to do.
I'm sorry I'm confused. I was responding to your suggestion earlier about making it SSD only, which I think is much less feasible than having it be CSD only. I believe I've said my position regarding the option already: If the problem is the apps don't want to write their own code for drawing window decorations, there are multiple solutions to that aside from SSD, that would require about the same amount of code in clients as SSD would. So to me it's not really an issue of the app working in mutter or not, or needing to link against gtk, or whatever. It can all be handled transparently with the right solution. Maybe eventually someone could create a version of libwayland that handles decorations transparently, with no changes needed to the apps at all.
Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
Things like these are why I think I'll never will be using wayland as it just breaks everyone's existing applications and workflows. wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision". And I speak as someone who wrote one of the first wayland compositors, and one of the first wayland compositor libraries, which code partially still exists in wlroots.
I don't think they would which is why the low level toolkits like SDL are the ones that have to handle it. Unfortunately that's the way it is, libwayland is very barebones and doesn't have a way to draw decorations.
>this is not the only case where gnome devs just decide to be jerks.
Please do not assume bad faith and suggest that someone is being a jerk to you personally because they didn't implement a feature that you were interested in. This is a sure fire way to cause burnout and stress to open source developers.
>wlroots and sway developers are doing good work to try to bring wayland and its tools to same level as X11, but then we have these other groups that just actively reject anything that doesn't go along with their "vision".
I have seen wlroots and sway developers reject patches and features that don't go along with their vision too, so I am not sure what distinction you're trying to draw.
It can never really look or behave natively on Gnome since client-side decorations are more than a boarder and window buttons. It's also about having an integrated toolbar and more draggable area.
Don't you have this completely backwards? If I want my application to have special custom decorations, then it makes sense for my application to draw the decorations. But if I want my application to have the standard decorations of the system, why should I want my application draw them?
GNOME supporting SSDs would not diminish the ability of GNOME's applications to use CSDs. So objections about the utility of CSDs imply a false dichotomy.
The solution there would be to fix gtk to support vulkan, and to fix libdecoration so it looks better.
>I consider them to be quite the jerks indeed.
Please stop, this is assuming bad faith and it's not helpful. The mutter bug tracker is an inappropriate place to give this unrelated feedback about this, when those issues you talked about are problems in libgtk and libdecoration. That's why the issue is closed. If you are just going to throw flames and don't want to discuss real technical solutions to the problem then I'm going to end the conversation.
When is it appropriate to assume bad faith? I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
Saying "you have to use our library and also fix it for free" is a dick move regardless.
>I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
I'm sorry I don't get what you're saying. You can decide not to support or depend on something without (incorrectly) assuming bad faith. This stuff is all open source, nobody can force you to use a library that you're not interested to use.
That's not strictly speaking true, especially when politics and money get involved. Unless you're using a very loose definition of "force" which doesn't include any kind of network effect at all.
Quite frankly, taking 5 minutes to put up a page saying "We will never support SSD and we acknowledge the use cases but do not care about them." would be far more forthright.
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.
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 fallback for old or non native apps) rather then force all toolkits and old apps have to implement this how they think (won't you get apps that will look like XP or OSX because you forced the app to paint the buttons). As a developer myself feels rather stupid not to just provide the SSD for old apps , really feels like "let's make this old and non native apps look and work like shit so people use my cool design.
But I could see an argument that GNOME devs are not that competent though, they implemented a shell that will kill all your apps if there is an error in an exception(on wayland)... so incompetence could explain why they are not capable to provide both SSD and CSD too.,
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.
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.
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.
In a wayland system the compositor IS the desktop shell. Window placement is not up to the application, so moving them and hence putting "handles" on them in the form of decorations is a natural fit for the compositor.
Another feature that belongs in the compositor is remembering where each application was last placed and sized and replicating that when starting them. I agree with the Wayland ideas that programs do not have the ability to warp mouse pointer or know about their environment, but once that model has been adopted there are useful features that need to move (or for decorations should move) into the compositor.
That's only intensified with 3.40 (Now hailed as "40" like a pop star using only their first name.) Apparently the top hot new feature is "horizontal workspaces"...mind-blowing.
There will always be a reason why this patch isn't acceptable, despite the overall code-quality in gnome projects being... what it is. I'd bet if a Gnome app needed this feature that patch would have been quickly and quietly accepted.
Also things like
>adding only hooks for you means that all the other terminals get no benefit.
Makes me quite concerned since these hooks weren't just for termite, as evidenced by tilix showing interest in this patch set.
>Implementing this in VTE would mean ruling out having any flexibility in the terminal using the library. [...] an implementation inside VTE won't satisfy the use case.
I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having, and the maintainer responded with a simple "wontfix" and no more discussion.
This is kind of the thing we're talking about. One project said they needed this, another project said they'd also appreciate this feature, and instead of discussing how to make this work, setting clear requirements and the like, it took 2 years to respond to the first patch submission and then the issue was just randomly closed in the middle of a discussion.
If you are interested to work on this patch, it wouldn't hurt to ask the maintainer for clarification.
>as evidenced by tilix showing interest in this patch set.
That's two of them, there are other terminals that use VTE.
>I think that the termite developer explained very clearly why the approach suggested by the VTE maintainer wouldn't actually solve the problem they were having
I don't think so, the termite developer is making that assumption before the new patch was even completed. Additional options could be added with the suggested approach.
>Additional options could be added with the suggested approach.
doesn't make any sense when the maintainer closed the ticket with "wontfix" in the middle of the discussion? Are we both reading the same thread? It seems like we're disagreeing about some fundamental facts here, but actually reading the ticket makes the facts pretty clear?
It worked for a long time and now was made impossible.
The reason given was "don't want to support it".
That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mind will link to internal symbols anyway.
In my opinion, an application developer should be able to choose how to link their program; toolkit developers should not forbid one way if there isn't a good technical reason.
[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109943...
If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
Distros use `-Ddefault_library=both` or `=static`, and let Meson install the built archive files; this is what is broken in that issue. It is surprising that this flag does nothing for GTK when it works as expected for all other Meson projects.
You could copy the archive file behind the Meson install action's back, but the maintainers' point on the issue is: "GTK isn't meant to be built as a static library" and "why do you think you need a static build of GTK4?".
If they do not want to support it, there's no guarantee the .a file will still be there tomorrow. That's what "upstream support" means.
I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do.
I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.
Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.
> if they could keep that libgtk_static around
Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.
> I'd be interested to hear if static linking GTK even has that many benefits
One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.
Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.
This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.
[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...
Thoughts?
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12
They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.
From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.
I agree. This presentation convinced me:
https://youtu.be/ON0A1dsQOV0?t=2468
GTK+ is really just a toolkit for GNOME projects. All other users are secondary.
They do seem to be paying more attention to MacOS and Windows with GTK 4.
I find the notion that GTK is just for GNOME rather funny since most the GNOME apps are very basic. The Software app is notoriously crap, but that's due to a lack of people to work on it. Their map app isn't much more than a GTK window frame on google maps or something. The video player... I mean can't they adopt VLC as the "official" media player and just make the GTK version of that really nice? VLC could use a better GUI. Same for web browser, why have a GNOME one that will never be able to keep up? Why make all these little toy apps anyway? Maybe I'm conflating gnome with a small linux distro. But once they move beyond system and config tools that's what it starts to become.
Don't get me wrong, I'm using a Gnome desktop for my day to day work. As a user, I enjoy the end result and I'm very happy with the way the system looks, but the absolute refusal to allow for any SSR has so far prevented me from ever seriously considering GTK for any cross-platform desktop application I'd like to write.
I don't really have a problem with the Gnome apps. There's nothing special about them, but they work and they're there. I quite like the software tool when it works, I've never managed to get Discover working for more than a few days so at least Gnome Software is stable in comparison. I also don't have any trouble with MPV for video playback. Sure, it doesn't contain a lot of power user features, but I only need it to play video files when I double click them, for anything else there's VLC.
Gnome, as a package to build a diatro around, works quite well. With a full Gnome setup, you can do almost everything you need to do on a computer. KDE is similar in that regard, although I really dislike the general UX of the KDE ecosystem for some reason.
On a side note, VLC is getting a (controversial) new UI that makes it look more slick and modern than the current design.
Sorry, this ship has sailed, and I find that bringing "native" into an argument simply invalidates the argument.
That "native" has changed so much over the years shows that there isn't one "truth". The fact that things like Electron and Flutter and other toolkits exist clearly demonstrates that end users don't give one iota of damn whether a control is native or not.
There's a few code editors out there integrating heavily with macOS that get featured here on HN once a while, and every time the comments are filled with people complimenting how well it works with the operating system and how nicely it integrates.
People also complain all the time about how Google sticks to material design on iPhone, even though the rest of the device follows an entirely different standard. If users really didn't care about native controls, that wouldn't be a problem at all.
When an application fits into the system, it's generally celebrated, but we've reached the point where we stopped expecting any form of integration anymore because every application is Javascript wrapped into a copy of Chromium now, if you even get a desktop version of the application in the first place.
the fact that Electron and Flutter and React Native and others exist clearly demonstrates that developers don't give one iota of a damn whether a control is native or not. These are tools of developer comfort, not of user comfort. Users don't care what you use to build your applications, as long as your app does the things they want to do well.
I don't see anyone celebrating the diversity of ways the different X buttons on their desktop looks, but I do see people enjoying the native look. To me, that seems like proof that this is a feature people are missing but not vocalising rather than that people don't care about.
In the end, people enjoy native experiences more, but native experiences cost more time and effort to produce and therefore more money. Consumers want free or cheap apps so businesses use cross-platform toolkits to reduce cost and effort, but these platforms certainly don't prove that users don't give a damn. They prove that they value having an app for cheap over having a good app for more money.
Because devs rarely have the time to do their frontend work 3-5 times over and over for each different platform. Cross-platform is the best choice, especially if you want anything to be available outside of Windows or rarely macOS.
> but I do see people enjoying the native look
I don't. It reminds me of the good old days on Windows XP when you couldn't tell a program from another because they were all "native" and looked the same. I prefer an app to keep a cross-platform look - e.g. Google's stuff looks the same on the web and on mobile, so you aren't stuck rediscovering everything when you switch platforms.
FYI this is not entirely correct. There is a flag for this in GDK4: https://developer.gnome.org/gdk4/4.0/GdkToplevel.html#gdk-to...
It may be that this is not implemented yet for some backends (I think it is not implemented in the Windows one) but they probably would accept a patch to implement it there if you know how to do it. Please avoid making these hostile assumptions about open source developers without having the full information. From what I have seen, there is a push recently to make GTK4 a better cross platform toolkit than GTK3 was.
I've given GTK4 a try on Windows, and all enabling the top level decorations seem to do is to disable the window border. All controls are still Adwaita, so you'd still need to fake a Windows UI style if you want to make the application feel any kind of native.
Somebody could definitely fake a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. That to me is a much more viable option. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.
[0] https://github.com/B00merang-Project/Windows-10 [1] https://github.com/B00merang-Project/Windows-7
Immediate mode UI framework that actually supports accessibility stuff would be neat too.
In this case, both tribes (GNOME and Wayland) have a vision of the perfect way for software to work. They have each captured enough weak allegiance/users to prove to themselves that they are right. Therefore, the other side is wrong.
I had already been using alacritty for a while because it had wayland support, even though it has some weird bugs on my current i3 setup where creating a new terminal just creates an unresponsive window that has to be killed through htop. Other than that it's been great, and there is something satisfying about cat /udev/random and the text that flies by with GPU acceleration.
> VTE is a terrible base for building a modern, fast and safe terminal emulator. It's slow, brittle and difficult to improve.
It sounds like the maintainers of termite had a miserable time dealing with VTE, and are glad to see the back of it.
Make sure to scroll all the way down to comment #26 where the devs say:
> This bug is closed and this patch rejected […] Adding keyboard selection to vte will be done inside vte, see bug 78291 [1]
– a bug which is 19 (in words: nineteen) years old.
[0]: https://bugzilla.gnome.org/show_bug.cgi?id=679658
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=78291
the laziness to find supposedly good libraries to work atop.
and his impatience at a resistant, inflexible library resulted in them warding others off againat similar folly.
a three virtues mini saga if I've heard of one,
http://threevirtues.com/
For example a few years ago I tried to enable 24-bit ("truecolor") support...
For one thing, the terminfo reporting for 24-bit color support wasn't universally recognized: terminfo added an 'RGB' capability to report this, but because this was added only "recently" (as far as terminals are concerned), not all programs relied on it. For example, Emacs or Vim didn't seem to use this capability.
For another thing, there can be a mismatch between what the local and remote terminfo databases (provided by ncurses) support in terms of recognized capabilities. I had tried to copy the xterm-direct terminfo to the remote, but it wasn't recognized! Turned out it had to be compiled with the remote server's tic.
Supposedly the Terminals Working Group [1] was looking into overhauling the ancient terminfo system to support this, but there was no clear path forward. I suppose one of the problems is the massive backwards-compatibility requirement. (There is probably nothing else in the software ecosystem that requires such backwards compatibility as terminals, they literally trace their ancestry to the 19th century! [2] )
[1] https://gitlab.freedesktop.org/terminal-wg
[2] https://en.wikipedia.org/wiki/Teleprinter
Terminfo is a remnant from when computers were slow and disk/memory constrained, and it made every byte count. It was hard to efficiently encode a database of all the capabilities of the terminals at the time! The trade was in favor of efficiency at the expense of convenience.
Look up the manpage for tic, toe, infocmp & family.
long-term: Maintain an alacritty package in your distro of choice so the terminfo is automatically included
- Hi Jeff, I know you have a todo queue from here till the next century, but please add one more item, having all our VMs, however they built, to include this set of files. I need it ASAP since without it if I log in to a server, I can't use backspace.
- What? Why? This looks like lots of work to modify each one of our 10000 deployments. It also may create some bugs and using non-standard deployment packages is time-consuming. What's wrong with plain old ssh, it works everywhere? What's wrong with your backspace, maybe I should order you a new keyboard?
- Well, ssh is fine but you see, I've got this new OpenGL super-fancy terminal emulator, and if I use it to ssh into a random server my backspace doesn't work. So if you changed every deployment we have to support it, that would be great, mmmkay? Oh and longer term I also need you to maintain a custom package for every linux distribution we might use that fixes this issue.
- Are you high? Did you check you temperature lately - maybe you have a high fever and your mental capacities are compromised?
- Hold on, Jeff, don't you think me using a fancy terminal program than can scroll 35% faster worth the effort? And it's also written in Rust! You could use it too, it's really awesome unless you need the backspace key for some weird reason.
- clickety click I've disabled all your shell access to all our servers until your mental health improves, and asked HR to issue you a week of sick days. Please get well soon.
Best I can figure its not really a winit/alacritty bug, but some gremlin with my particular monitor/gpu/nvidia drivers.
How does it misbehave on Wayland?
I use it with sway on a laptop that doesn't support OpenGL well enough for other terminals, it's okay, but I miss some features, and other <indows could snoop on it. I also had to install xwayland for it.
Still, as a heavy terminal user, I fail to understand what's the big deal with the choice of terminal. I have used only xterm for more than 20 years (with a short stint with gnome-terminal, and I didn't find any relevant difference). It starts instantaneously and doesn't make any fuss while it's running. Is there anything important that I'm losing?
As the terminal is the most used app for many here, it's natural for many to care about the small details.
Aesthetics and speed are important to me and to that end Kitty is my choice. Not that there's anything wrong with xterm
Clickable links.
Does alacritty support ligatures yet? I've been using kitty because it does, but then I have issues with tmux in kitty ... I know, I want my cake and eat it
1) If you scale certain fonts using fontconfig, alacritty would ignore that.
2) No emoji colors, no ligatures (and thus no flags), also emoji size has problems
... and not to mention it's one of the slowest (yes! contrary to what they blowhard they response time to keys is very large) terminals out there.
List is endless, termite had its place, but there is no doubt that there is so much ego in OSS that one solution canot fit all
Personally I'm keeping an eye out for wezterm, it seems all the good things of alacritty without the self-congratulation part
They state explicitly on their README that they're measuring throughput, not latency. Besides that, all three of your complaints are true as far as I'm aware, and they are major dealbreakers.
This is intriguing to me. You're not the first I've seen complaining about this, so there must be something to it.
But in my case, on a fairly low-end machine, what I type shows up instantaneously[0] on the screen, even when the CPU is busy compiling.
I'm running an i5-6500 with integrated hd 530 graphics and a 4K screen. I use i3 (so X11) and Picom with a bunch of effects.
---
[0] I have a mechanical keyboard, and if I push the key all the way down, I hear the sound of the key bottoming out after I see the character on the screen.
In these kinds of discussions, the talk is usually about perceived latency not absolute latency. If it feels like there's basically none, then it's good enough. It doesn't mean there's absolutely 0.0 ns latency.
> Different people have different sensitivity to latency
This I can get behind. But I doubt that what seems instantaneous to me would seem "terribly long a time" to someone else, especially since I look specifically for this. As you pointed out, no terminal app has absolute 0 latency, so if one particular software has terrible latency compared to another one, the difference would have to be pretty huge.
Do note that I'm not talking about being bothered by the latency. I know a lot of people who will notice the latency when pointed out to them, but they don't really care. Personally, I hate when things lag, even if I may happen to have a worse perception than average (don't actually know if that's the case).
All terminals have latency, but that doesn't mean that all terminals have equal latency. Point was that anecdotes about subjective instantaneity are pretty meaningless, especially without any reference point.
It would be much more meaningful to substantiate the discussion with actual data; the measurements done by danluu are one example https://danluu.com/term-latency/
Of course there can be quibbles about the specific methodology, but its still much better than having no data at all. Especially for something that is as measurable as latency is.
In general if you claim something is fast, back that claim up with some numbers.
Not really a surprise but something to be aware of.
Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf
cat randomfile
and see the output correctly, at least.
Comments: 1
I switched from kitty to wezterm. I don't have an official benchmark like the below [1], but low latency is an explicit goal of the project and it seems on par with kitty.
[1] https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty
Uses the GPU for rendering (iirc the basis for alacritty’s performance claims).
X11 is definitely not dead yet, though. FLTK programs, Wine, and some game engines still require X11.
TL;DR: Drag and drop involving chromium or electron windows has been buggy. wlroots/sway has not implemented _NET_CLIENT_LIST_STACKING, and both the fallback code inside Chrome/Chromium and the way sway has been stacking Xwayland windows have been buggy. A patch has been submitted to Chromium to fix the faulty fallback, the sway bug will be fixed, and wlroots will also support _NET_CLIENT_LIST_STACKING, so by the time the next sway release comes out everything should be ironed out.
It's also much faster to build than Alacritty on a low-end machine, which is appreciated.
[0]: https://gnunn1.github.io/tilix-web/
https://github.com/gnunn1/tilix/issues/1700
So I switched to tmux for tiling and use Alacritty now, not that I regularly dump so much text so quickly on the terminal but I was impressed with the engineering. I have been happy with it.
[¹https://github.com/alacritty/alacritty/issues/3108]
I hope latency has improved to be much better. Haven't tried it in a few years.
Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory.
In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?
You could hit drivers bugs for sure, but that means in your particular config GL will be worse so you need to test, doubt this translates to a general scenario.
I think a lot of people assume because your default GL setup is to use immediate mode to re-render everything at refresh rate that's the only way to do rendering and that's why GL apps get the reputation for being power hungry.
In what world would corporate, closed-source software engage in this kind of earnest truth-telling without the propellers of mergers, acquisitions, or takeovers?
Also, vim: `help modifyOtherKeys`.
emojis
I’m confused by what you’re saying here, because I can’t think of any particularly compelling reason to run Alacritty inside WSL beyond ease of installation.
You can run the Windows Alacritty from WSL2 with no trouble (like any other .exe file), and you can run WSL stuff inside Alacritty.
Admittedly spawning something WSL-side inside Alacritty from the WSL side becomes a smidgeon more complicated, because you’ll need to rewrite any `alacritty --command …` to run it through wsl.exe or your distro-specific launcher. But even if you need to do that, that should be pretty much set-and-forget with a little wrapper shell script.
Have I misunderstood the reason for your remark?
Latte bugs are not though :(
Now I concede that I did not personally notice any difference, aside from the usual config changes, but surely there is still a case for a CPU side VTE based terminal? Or am I wrong?
Can you quantify that? Are you talking multiple countable seconds to open? It seems to open instantly for me but I can't tell if your talking about 0.5s or 5s being slow.
https://i.redd.it/5buckgok5lx61.png
What am I to do???
https://codeberg.org/dnkl/foot
a) use an OS besides Linux (and whichever other unix-likes that have wayland compat now, last I hear FreeBSD had ... some degree of support), and/or
b) don't use wayland. Alacritty even works on Windows!
(Look at the box drawing characters.)
You can use tabbed[1] or a multiplexer like tmux, or you can use a different terminal emulator like kitty[2].
For example, instead of launching `alacritty`, you would launch `tabbed -c alacritty --embed`.
1. https://git.suckless.org/tabbed/
2. https://sw.kovidgoyal.net/kitty/
Kitty it is.
I'll give Kitty a shot. I've been using konsole recently and it works for the most part, except when sending files through picocom. ctrl-a+s pops up a message about terminal flow control even though the keystroke is intercepted by picocom and not used for flow control.
When you subsequently want to move a group of things around, you can focus the parent container and move it around as though it were a window. (Out of the box, Super+a is `focus parent`, though curiously there’s no `focus child` binding in the default config, so to return to a child you pretty much have to focus a sibling or another container, or use the mouse.)