Georges Stavracas

Vala exists. There are also enough famous GJS memory leak issues in the past. https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

No, but hopefully that issue is resolved soon: https://feaneron.com/2022/10/21/the-death-of-the-meme/

My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation". > https://gitlab.gnome.org/GNOME/gjs/-/issues/361 Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether > https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... This fix is strictly specific to GObjects wrapped by GJS

> however the new public API has an animation, after which a special window opens and requires you to click a "share" button before Flameshot can work with the screenshot. You need to go through that every time you use Flameshot. This is indeed very frustrating. Something related is in the works for screenshares, a "remember this decision" option. https://feaneron.com/2021/11/13/adventures-with-portals/ At some point maybe something similar will come up for screenshots. On a related note, GNOME Shell 42 should have a nice new screenshot integration: https://thisweek.gnome.org/posts/2021/12/twig-24/#gnome-shell

Even stuff such as OBS Studio was significantly slower on Wayland than on X11, at least until the efforts done _last year_ (e.g. https://feaneron.com/2021/03/30/obs-studio-on-wayland/ ) . Single-Window support for screencast API is also only a couple years old! Before that it would just error out, even if the D-Bus interface was there ( https://github.com/flatpak/xdg-desktop-portal-gtk/blob/b2b5ede150e7dd4… ). That's why I say that it just moves way too fast for the glacial speed that commercial houses normally have. For at least 2 years (thinking 2016-2018) some distros were even shipping Wayland _without_ an actual working screen capture API. How do you even support those ?

The only one out of those that's a intentional design is multiple monitors. The other ones are known shortcomings that are just really hard to fix. The memory leak was fixed a few years ago: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

> It doesn't leak memory (https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...), it doesn't crash, it doesn't change (UI/UX is a kind of stable, too), and it can seamlessly restart itself in place without any disruption to the actual user session. None of that was true when I last used i3. YMMV.

"polished" is subjective enough that I won't say you're wrong (although I don't agree), but how can you be more stable than i3, in any sense? It doesn't leak memory (https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/)… it doesn't crash, it doesn't change (UI/UX is a kind of stable, too), and it can seamlessly restart itself in place without any disruption to the actual user session.

There was an update for OBS recently, which sounds like it fixed the Wayland issues. https://feaneron.com/2021/03/30/obs-studio-on-wayland/

I think the original blog post from the developer is a better link: https://feaneron.com/2021/03/30/obs-studio-on-wayland/ Michael added zero extra information on top of that.

Wow. I was suprised to read that OBS doesn't work with Wayland. I found some articles [0] on how it runs well using XWayland [1] - which I guess let's you run X-Clients under Wayland - but it seems that the amount of work to get this to work is not trivial, considering the official PR for the work, is on part 3 and that has been open since March![2]. Oh, how did it get so bad? --------------- [0]:https://feaneron.com/2019/11/21/screencasting-with-obs-studio-on-wayla… [1]:https://wayland.freedesktop.org/xserver.html#heading_toc_j_3 [2]:https://github.com/obsproject/obs-studio/pull/2484#issuecomment-604775…

Did you read the bug report? The entire problem is that GC isn't working right. See https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ for more info.

The news is, that it finally landed! https://feaneron.com/2017/10/03/improved-half-tiling-available-in-mutt…

Some of your comments are valid and I agree with them, but some of them are a lot of nonsense. >This was caused by a weird mismatch between its javascript desktop and its compiled code that was too hard to fix so they decided to just constantly run the garbage collector and marveled at how not horrible this performed in actuality. No, this is not even close to what happened. There was never any weird mismatch, the refcounting is very similar in both of them. The bug was that the garbage collector wasn't running correctly. Please read the (now 4 years old) blog post: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ >Deprecates features that people use without replacement. I would like to know about these desktops that are still under active development and have never removed or deprecated features. I've never seen one. I'm sure if you look hard enough you can find people complaining that Windows 11 doesn't support 8-bit color displays at 640x480. >See tray icons for a literal decade This never happened, there has been several extensions for tray icons for the entire decade. The real problem here is that all the APIs for tray icons are broken and nobody bothered to implement one correctly. >Has no addon API forcing addons to monkey patch the javascript desktop ensuring such efforts can trivially fail on any version update and addons that aren't actively developed will stop working. This has nothing to do with javascript or addons. In general code…