Use Alacritty instead of Termite(github.com)
github.com
Use Alacritty instead of Termite
https://github.com/thestinger/termite
301 comments
I agree, but also in the corporate world there would be incentives for innovation to better compete or finding niche markets. It's not all bad
However, that competition might come in the form of a more effective sales force, rather than a more effective product
In the floss world that competition could come from more active social media presence, which is marketing - nothing else.
That can still be done better by people paid to do it full time.
Worth noting that the bad behaviour in question they're finally giving up on is from a FOSS project.
Which is why many people have left Xorg. Just because it has outlived its course doesn't reflect negatively on the open source project as a whole.
> 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.
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.
That all stopped with Gnome3.
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.
Gnome developers actively hate their users and non-gnome developers. This issue takes the cake: https://gitlab.gnome.org/GNOME/mutter/-/issues/217
If that's your best argument against Gnome it seems like they are doing pretty well.
Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.
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.
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.
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.
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.
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.
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.
>this is assuming bad faith and it's not helpful.
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.
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.
>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.
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.
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.
Electron uses Gtk and Games should use SDL2. They will support CSD, which is work, but it will happen.
You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego.
Btw: I'm a GNOME user who is against SSD.
You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego.
Btw: I'm a GNOME user who is against SSD.
The issue is that Electron and SDL will fix this 10 years later, old apps will still not work.
Same issue with tray icons, GNOME is expecting cross platform apps will use their shirty design OR their users will use only new GNOME apps.
>You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego
Is better that say all the 10 WM implement SSD (maybe as a 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.,
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 issue is that Electron and SDL will fix this 10 years later, old apps will still not work.
The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL.
For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.
The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL.
For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.
>> so this is not breaking compatibility with apps there because it was never supported.
It's not breaking GTK apps. If they want to say GNOME really only works with GTK apps that's fine and the toolkit will provide the decorations and nobody needs to care which part of the system draws them. But they want to support more than just GTK apps and rightly so.
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.
> The issue is that Electron and SDL will fix this 10 years later, old apps will still not work.
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.
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.
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.
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.
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.
>> 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.
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.
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.
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.
>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.
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.
As a programmer Gnome has really damaged their relationship with a lot of developers.
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.
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.
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.
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.
> It's not an illustrative example.
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.
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.
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.
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.
Has this been reported?
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?
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 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 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.
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.
> 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
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.
> "free in license only"
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...
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...
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.
>There are several Wayland compositors that don't implement that feature.
Can you list some that aren't weston or dead projects?
Can you list some that aren't weston or dead projects?
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.
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.
>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.
>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.
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 believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality.
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.
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.
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".
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...
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...
>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.
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.
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.
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 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.
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.
Did they ever implement that solution?
It doesn't look like it, I'm sure they would be open to patches to help out there.
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.
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.
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?
>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'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.
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.
> 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.
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.
> On the other hand Gnome3 is the first Linux desktop that I think is really non power user friendly.
I think Plasma and Cinnamon also belong in this group.
I think Plasma and Cinnamon also belong in this group.
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.
Gnome 3 had a HUGE affect on desktop environments, due to Gnome 2's popularity.
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.
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.
My non-power-user wife, father and mother all prefer MATE.
It works like Windows, which they are accustomed to.
Edit: I don't get why this was down-voted, but OK.
It works like Windows, which they are accustomed to.
Edit: I don't get why this was down-voted, but OK.
time agnostic rule #1: people are people
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.
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.
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.
Immediate mode UI framework that actually supports accessibility stuff would be neat too.
This is why people use electron.
> don't make the mistake of thinking their libraries are meant for others to use
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.
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.
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/...
Are you affiliated with GNOME?
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.
Based on my personal interactions with GNOME developers and unresolved bugs, I suspect your experience is the exception, not the broad norm.
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.
Agreed with the sibling comment. My own experience with GTK and their developers have been awful.
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.
>> 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.
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.
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
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.
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.
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'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.
[0] https://github.com/B00merang-Project/Windows-10 [1] https://github.com/B00merang-Project/Windows-7
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
> 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.
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.
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.
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.
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:
Thoughts?
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12
> 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?
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12
>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...
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.
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.
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.
These things are certainly reasonable to consider. Thanks for adding additional context.
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.
[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109943...
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...
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.
Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).
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.
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.
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 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.
[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...
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've been using Alacritty in Garuda Linux and having a blast with it! It is really awesome!
Latte bugs are not though :(
Latte bugs are not though :(
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.
i haven’t observed that behavior at any time.
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:
env:
TERM: xterm-256colorYou can fix this by setting the following values in .config/alacritty/alacritty.yml:
env:
TERM: xterm-256color
short-term: Add the terminfo file to your vm provisioning tooling: ansible, terraform, etc
long-term: Maintain an alacritty package in your distro of choice so the terminfo is automatically included
long-term: Maintain an alacritty package in your distro of choice so the terminfo is automatically included
Sometimes we have to deal with VMs admin'd by other people.
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.
- 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.
[deleted]
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] )
[1] https://gitlab.freedesktop.org/terminal-wg
[2] https://en.wikipedia.org/wiki/Teleprinter
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
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.
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.
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 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 think the explanation lies here:
> 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.
> 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.
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.
dev started with the hubris to try to do better.
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/
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/
Given with how the conversation went in the Bugzilla ticket[0] that Daniel Micay linked, I can't say that I blame him.
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
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
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 didn't know alacrity was supported on Windows. Can it be used in place of putty as well?
Is it better than native Windows terminal?
> unfortunately I cannot use it on WSL2
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?
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?
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
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.
Everything is a GL context under wayland isn't it?
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.
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.
[¹https://github.com/alacritty/alacritty/issues/3108]
[¹https://github.com/alacritty/alacritty/issues/3108]
They seem to care more about throughput than latency.
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 hope latency has improved to be much better. Haven't tried it in a few years.
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.
Why would GL rendering be any less efficient ? You don't have to rerender the entire screen in GL or render at MAX FPS if nothing changed.
[deleted]
It may or may not be - it certainly should be tested.
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?
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.
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.
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.
I've been using Alacrity/Sway for at least that long, and it's been perfect. Maybe I have a low end machine.
How does it misbehave on Wayland?
How does it misbehave on Wayland?
I believe it was about copy/pasting with wl-clipboard, which didn't worked. May have to try it now again.
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).
I retried and it now works fine on all my new and old machines. Seems like the bugs are solved.
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
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.
Because of tiled window managers. Having many terminals open is often more ergonomic than the terminal's tab support.
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.
are you trying urxvt? it have a daemon mode so each new terminal create only window but not whole new instance.
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.
It's not wayland-native, though.
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 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.
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.
Best I can figure its not really a winit/alacritty bug, but some gremlin with my particular monitor/gpu/nvidia drivers.
I settled on kitty, personally. I quite like it, and its image supports works very well with ranger!
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.
Drew DeVault just started recommending foot over Alacritty. You might want to check it out.
How about Foot? https://codeberg.org/dnkl/foot
It's Wayland-only, right? Alacritty OTOH not only works on X11, but is cross-platform.
X11's been EOL'd, dude.
And yet everybody still uses it except the developers.
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.
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.
If last time you tried using Wayland was Sway, maybe this is the issue you were running into: https://github.com/swaywm/wlroots/issues/2889
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.
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 actually this issue here: https://gitlab.gnome.org/GNOME/mutter/-/issues/1563
+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.
It's also much faster to build than Alacritty on a low-end machine, which is appreciated.
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
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
Lots of things alacritty cannot do-
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
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
> 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.
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.
> 2) No emoji colors
Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf
Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf
Colored emojis work fine, but for ligatures you need kitty as far as I'm aware. I ran into this when attempt internationalization of a website.
> ... 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.
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).
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.
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.
Not really a surprise but something to be aware of.
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?
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.
[1] https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty
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
Same here, kitty is amazing. It supports ligatures and also BiDi. Both of which alacritty don't support. I wish kitty had sub-pixel rendering though.
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.
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
This might have something to do with the GPU you use. Alacritty spawns instantly for me on AMD GPU with mesa drivers.
> Alacritty is very slow on startup
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.
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.
It's slow when relying on opening to be instantaneous so 0.5s feels very slow. I need it to be around 0.05s.
Alacritty is obsoleted by Foot: https://www.reddit.com/r/swaywm/comments/n6kznh/yes_welcome_...
https://codeberg.org/dnkl/foot
https://codeberg.org/dnkl/foot
Not if you:
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!
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!
If you get it added to the standard Arch repo then I'll try it out.
alacritty's lack of tabs absolutely killed it for me. They are not open to the idea of adding tabs, either.
True, but tabs are something built into tiling window managers like Sway. If you want a fast terminal with tabs then I'd recommend kitty.
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.
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, you can do it through the config or by using shortcuts to switch a group of windows into tabs. I'd also recommend tmux and tmuxp.
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.)
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.
The maintainers would prefer to "do one thing well" and let other programs handle this sort of feature.
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/
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/
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.
Kitty it is.
Kitty it is.
It also depends on your window manager too. I use BSPWM and tabs just always felt off when I could quickly flip to another workspace.
"Obsoleted" is a word? I've only heard "made obsolete" before, or replaced/discontinued/deprecated.
I guess obsolete got verbed...
Verbing weirds language.
yes, it is. Even in dictionaries, e.g. https://www.merriam-webster.com/dictionary/obsolete
Yeah wow TIL it's been around least since the 1730s. https://books.google.com/ngrams/graph?content=obsoleted
I've seen "obviate" or "obviated" used in these situations.
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?
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?
Tabs, panes, scrollback search, if you're not using tmux & co. (not talking about alacritty, but about more advanced terminals, in general).
Clickable links.
Clickable links.
Speed. A terminal’s job is most just to print text on the screen. You might be surprised at just how slowly that can be done.
Many terminals lack ligatures. Once I started using a monospace font with ligatures I could never go back.
Best font + terminal combinations to try this with?
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.
Hey, use what you like!
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
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
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.
Why inside neovim? What's the benefit?
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.
Unfortunately, Alacritty seems broken to me. See https://files.catbox.moe/0agd5p.png
(Look at the box drawing characters.)
(Look at the box drawing characters.)
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.
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've been running urxvt with tmux in a tiling window manager for the last decade. What features from these new terminal emulators am I missing out on?
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.
Also, vim: `help modifyOtherKeys`.
emojis
Also, vim: `help modifyOtherKeys`.
emojis
kitty has ligatures and inline images support. Inline images go right out the window if using a terminal multiplexer though, unfortunately.
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?
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?
I have been using Tilix[0] - pretty happy with it. Nice tab features, profiles/theming, quick startup, excellent rendering. Nothing to complain so far.
[0]: https://gnunn1.github.io/tilix-web/
[0]: https://gnunn1.github.io/tilix-web/
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.
https://github.com/gnunn1/tilix/issues/1700
https://github.com/gnunn1/tilix/issues/1700
I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic.
Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime:
https://github.com/alacritty/alacritty/issues/1561
Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"
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"
That was my conclusion as well after my limited interactions with them. I no longer use it.
Oof, that interaction was uncomfortable. Definitely a very bad look for that dev.
The other dev chiming in at the end with "I've heard only good things about Alacritty's default colorscheme so far" was also frustrating. Saying "well nobody else complained" is an awful reason to dismiss an issue.
Considering this is their reaction to someone pointing out that their green is actually yellow, I'm not surprised that they are in an echo chamber.
Echo chamber is one term, another would be tribe.
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.
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.
An open source project with a closed source mentality.
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).
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)
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)
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].
[1]: https://www.color-hex.com/color/feff00
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
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.
It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.
If MacOS support is terrible, then they could either not advertise it[1] or disclaim it results in poor UX.
https://github.com/alacritty/alacritty#installation
Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.
https://github.com/alacritty/alacritty#installation
Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.
> 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.
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.
> 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.
Sounds a little bit entitled to me..
Sounds a little bit entitled to me..
Opinionated, maybe. Entitled?? That's way out of line.
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.
[deleted]
Adequate, meaning good enough, but with room for improvement?
Yeah, obviously not “perfect”, but totally understandable if the dev’s stressed out a bit.
>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.
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.
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.
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)
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.
It's a curious hill to die on, so to speak.
It's a curious hill to die on, so to speak.
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?
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.
poisonous, toxic, abuse....
You sure aren't running out of creative synonyms to make drama over a pretty insignificant incident.
You sure aren't running out of creative synonyms to make drama over a pretty insignificant incident.
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?
Yeah, this was my take away as well. Also, iirc their claims of Alacritty being the "fastest" are dubious at best.
I used Kitty for a while instead, which is very similar. More recently I've been trying out Foot: https://codeberg.org/dnkl/foot
I used Kitty for a while instead, which is very similar. More recently I've been trying out Foot: https://codeberg.org/dnkl/foot
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 have no idea how they can claim "fastest".
Basically every other "simple" terminal I've found behaves better -- xterm, urxvt, konsole, even iTerm2.
I have no idea how they can claim "fastest".
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
alacritty is GPU accelerated terminal. It may not be faster depending on your setup. xterm is also one of the fastest software terminals out there.
Yeah but their slogan isn't "fastest terminal depending on your setup."
Yeah, their original benchmarks were, uh...
> 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
> 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
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.
Yeah, I side with the devs on that one.
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.
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.
clever. review project issues before investing time in using project.
Wow, that's an ugly dev response.
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."
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.
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.
In this case, it’s not even taste preference but color perception, which is even harder to objectify.
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.
Boohoo. Maybe call the git police?
> 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"?
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"?
> What are the devs supposed to do? Debug the proprietary driver?
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.
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.
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.
No, you have Stockholm syndrome.
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.
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
From that github discussion:
> "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.
> "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.
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.)
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.
A quick look found you a 3 year old closed issue?
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.
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.
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.
The issue says the color choice was poor, effectively critiquing the ability of the person who chose that color.
I'd be insulted too. Wording choices matter.
I'd be insulted too. Wording choices matter.
Another example of the bad attitude of the core devs (there are many, just look through some of the closed issues): https://github.com/alacritty/alacritty/issues/5029
I wish Kitty had more hype going for it, it deserves it more IMO.
I wish Kitty had more hype going for it, it deserves it more IMO.
iterm2 is good enough for most of my use case. Download iterm2 and install lovelace. Done!
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).
Uses the GPU for rendering (iirc the basis for alacritty’s performance claims).
Right when this happens:
https://i.redd.it/5buckgok5lx61.png
What am I to do???
https://i.redd.it/5buckgok5lx61.png
What am I to do???
problem at least on OS X is none of these term replacements render fonts as well as the native term.
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 still use xterm with a bitmap font plus tmux. Low on resources, fast and all features I need.
I hope it "obsoletes" kitty as well https://github.com/kovidgoyal/kitty/pull/3544#issuecomment-8...
In what world would corporate, closed-source software engage in this kind of earnest truth-telling without the propellers of mergers, acquisitions, or takeovers?