Use Alacritty instead of Termite
github.com
github.com
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"
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.
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)
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].
It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.
https://github.com/alacritty/alacritty#installation
Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.
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..
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.
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.
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
To be clear, we’re talking about Kovid here, right?
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.
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.
> "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'd be insulted too. Wording choices matter.
I wish Kitty had more hype going for it, it deserves it more IMO.
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.
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.
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.
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.
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
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...
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.
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.,
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.
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.
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.
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.
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.
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?
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.
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.
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.
It works like Windows, which they are accustomed to.
Edit: I don't get why this was down-voted, but OK.
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.
Immediate mode UI framework that actually supports accessibility stuff would be neat too.
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.
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
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.
> 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.
Thoughts?
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.
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...
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.
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,
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.
env:
TERM: xterm-256color env:
TERM: xterm-256color
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.
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] )
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.
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.
Best I can figure its not really a winit/alacritty bug, but some gremlin with my particular monitor/gpu/nvidia drivers.
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?
Clickable links.
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
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.
Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf
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.
cat randomfile
and see the output correctly, at least.
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.
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.
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.
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???
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.)
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.)
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`.
Kitty it is.