Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Alacritty instead of Termite

github.com

Post reply on HN
Print view View original

151–160 of 331 posts

Re: Use Alacritty instead of Termite

#151

Post by zxzax »

Cloudef wrote: post #143
zxzax wrote: post #139

Earlier quoted context omitted.

>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 o…

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/36…

>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.

Re: Use Alacritty instead of Termite

#152

Post by Cloudef »

zxzax wrote: post #145
Cloudef wrote: post #54

Earlier quoted context omitted.

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 a…

>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 y…

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.

Re: Use Alacritty instead of Termite

#154

Post by zxzax »

jstimpfle wrote: post #146
zxzax wrote: post #112

Earlier quoted context omitted.

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 qu…

>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?

Re: Use Alacritty instead of Termite

#155

Post by Cloudef »

zxzax wrote: post #151
Cloudef wrote: post #143

Earlier quoted context omitted.

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/36…

>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…

>mpv has since implemented client side decorations.

Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186

Needless to say, mpv prefers xdg-decoration if compositor supports it.

>There aren't any zero code solutions

It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_.

>The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries

Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.

Re: Use Alacritty instead of Termite

#156

Post by shi_tty »

jah wrote: post #153

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

Re: Use Alacritty instead of Termite

#157

Post by zxzax »

Cloudef wrote: post #155
zxzax wrote: post #151

Earlier quoted context omitted.

>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…

>mpv has since implemented client side decorations. Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186 Needless to say, mpv prefers xdg-decoration if compositor supports it. >There aren't any zero code solutions It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the found…

I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I actually prefer them to SSD because they take less space, and they are consistent with the way the mpv decorations work in macOS.

>It's zero-code for client if the compositor actually handled the border.

With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.

>Yes and hope those libraries actually implement stable ABI.

Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.

Re: Use Alacritty instead of Termite

#158

Post by marshallward »

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?

Re: Use Alacritty instead of Termite

#159

Post by jorams »

Narishma wrote: post #64
halz wrote: post #34

Earlier quoted context omitted.

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 ]

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.

Re: Use Alacritty instead of Termite

#160

Post by akvadrako »

Cloudef wrote: post #152
zxzax wrote: post #145

Earlier quoted context omitted.

>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 y…

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.

Post reply on HN