Chromium now has initial, experimental support for the xdg-session-management #wayland protocol, which will start shipping in canary channel in the coming days. I've implemented and tested it against Mutter 48, the only compositor supporting it atm - also experimentally - since version 47.
Quick demo at https://youtu.be/OG9ZLXzlwkQ
Čas vyzkoušet nové prostředí – #GNOME48 na #ArchLinux
#i3 zůstává mým hlavním prostředím pro každodenní práci, ale musím říct, že GNOME 48 vypadá skvěle.
On @gnome #wayland #zoom do not support the advanced screenshare option "Portion of screen"... Just in case you searched for it... and misconfigured your graphics and display... and reinstall serveral drivers... and everything went green and yellow, but nothing helps, so you switch to arch and have a new hobby...
после обновления почему-то перестал грузиться Element, выдаваяozone_platform_x11.cc(246)] Missing X server or $DISPLAY
. а у меня вообще Wayland. подумала, что дело в том, что оно хочет через иксы запуститься
попробовала element-desktop --ozone-platform=wayland
, оно сработало. хотела дописать в hyprland.conf этот флаг, где у меня биндинг на запуск Элемента, а потом подумала, типа а не лучше ли со всеми электронными приложениями system-wide это решить, и создала файл ~/.config/electron-flags.conf
, где прописала
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
Элемент работает, посмотрим, чо остальные будут
@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....
In a nutshell, a major rework of what the X core protocol supports would be necessary.
But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.
@peppe Well, #dwm is a window manager. Then there's #dwl, which is a #wayland #compositor, trying to do "functionally the same" as dwm. My point is, it has to implement a lot more stuff to do so.
My favorite window manager is #fvwm (or now #fvwm3), and as far as I know, its main developer was looking into wayland and currently doesn't have any concrete plans to work on that ... and I can perfectly understand.
@mp362 Try #voidlinux it's surprisingly stable despite being a rolling release :)
Also if you want to keep xfce but at the same time have some fresh experience one option is to combine it with #labwc and go full #wayland (not for stability ofc :D )
https://wiki.xfce.org/releng/wayland_roadmap#testing
@nebucatnetzer slightly off-topic, but I switched away from #GNOME to KDE #Plasma, since GNOME #Wayland doesn't (?) support server-side decorations. I'd have switched to the GNOME #X11 session, but I'd have lost workspace swiping and smooth scrolling.
After GNOME 48's dynamic double/triple buffering, what I'm really looking forward to see, eventually, is #Mutter being able to recover from GPU state resets: https://gitlab.gnome.org/GNOME/mutter/-/issues/3305
On Linux, the open source AMDGPU graphics drivers in #Mesa are infamous for making everything lock up in your face like that.
I'm just crossing my fingers and hoping this will happen by the time distros collectively ditch X11 in favor of #Wayland.
I've been attempting to rewrite some C code for a Wayland client in Zig using only the client API (via zig-wayland's scanner) and for some reason I can't grab the seat name when I set the listener, very frustrating
It's got to be the way Zig handles struct memory, I just don't know how... I doubt I actually need an extern struct but I bet if I can throw pointers around like it's C I'll figure out the rest later
#C #Zig #Wayland
FLOWBLADE 2.20 released. This powerful video editor now uses SDL2 video playback for Flatpak on all systems with MLT 7.30 or higher. But video playback for native Wayland without XWayland or for GTK4 does not currently seem possible with SDL.
wlrctl
or wob
. I'm still running #RiverWM as my daily though and just testing Labwc to see what's on the otherside but hey. ;)The first time #Ubuntu really rubbed me the wrong way wasn't #snap, but #mir.
Back back in the days, when Jesus rode dinosaurs into Jerusalem, there was still a dispute about which new standard was going to be adopted.
#Wayland was in planning stage then and Canonical was fighting against it for no other reason than "not invented here".
There I was, with an union tired around my belt, seeing that the license was #GPL - with an agreement that #Canonical could "relicense" your code... wat?!