Here's a tiny questionnaire for those of you that use non-Latin scripts:
What script do you use (besides Latin)?
How do you use this script on a keyboard? (Do all the glyphs fit on a single keyboard, or does it require a special software input method? Is it handled by your apps or by your operating system?)
By answering this, you'll help me consider some things for a hobby project of mine (which I probably will ramble more than enough about here in the future). Thanks a lot 🥰
@bragefuglseth Russian. Glyphs are printed on the keyboard together with the standard QWERTY layout, and you switch between English and Russian layouts with xkb (Super+Space in GNOME). All glyphs fit, but some are located on the qwerty symbol buttons since there are a few more than latin.
Russians are used to switching back and forth to US/English, and the US layout is always present alongside. Keyboard shortcuts are traditionally written and resolved with English keys (e.g. it's still Ctrl+V).
I swear, every single time I'm preparing release notes for one of my projects I randomly stumble upon a completely unrelated bug that's been sitting there unnoticed for months. It just happened again with niri 0.1.4, I hit a timing based crash in the screencast code that must've been there from the beginning. I'm actually glad because it means I can fix it right away, but how does this keep happening lol
Firefox with its stock look, proper rounded window corners and actual Wayland support feels like jumping 5 years ahead of how it's shipped by default currently.
Another issue discovered/diagnosed with Tracy: screencasting while a game is directly scanned out could lead to dropped frames1. Turns out that when doing implicit synchronization, AMDGPU doesn't distinguish between writes and reads, and thinks that the read of the game's buffer to draw a screencast frame is conflicting with DRM's read to put it on screen. DRM then skips the frame.
Fix by Michel Dänzer passes an explicit sync file2.
Decided to try writing a Wayland compositor for fun. Took me a few days to get things going to a video-able state.
This is scrollable tiling, heavily inspired by PaperWM (which I'm still using and very much enjoying). You've got an infinite strip of windows that you can scroll through.
It's also got dynamic workspaces which work like in GNOME Shell (the Correct™ way to do workspaces), but all monitors have workspaces.
Highlights include relative-pointer and pointer-constraints which let Xwayland masterfully handle 3D games mouse look, and popup unconstraining which prevents popups from opening off-screen. I actually made popups place within their window with some padding, which looks quite nice.
Aaahhhhhh another difficult refactor down and niri now does multi-GPU! By which I mean that monitors plugged into secondary GPUs will now light up and work. All the screenshot UI and screencast portal stuff also works just fine. Wouldn't be able to do this as quickly without Smithay's MultiRenderer support and lots of help from @drakulix 😄
I went for the easier strat of always rendering on the primary GPU, but you can also pick render GPU dynamically, which apparently cosmic-comp does, cool!
Tagged niri v0.1.0-alpha.3 with multi-GPU support, borders and other improvements! Multi-GPU was one of the bigger things I wanted to get done before going out of alpha so I guess I'm slowly getting there.
Turns out that if you implement xdg-decoration in your compositor but tell clients that you want CSD, then SDL2 + libdecor clients will break due to a bug. The bug is already fixed, but the fix hasn't made it to any SDL2 release yet, let alone all the runtimes and vendored copies.
I added text rendering to niri using pangocairo, which turned out to be surprisingly simple. It basically "just worked". This unlocks a lot of features, beginning with a hotkey overlay, which should help people get started (suggested by @ju).
I'm pretty excited to finally be able to "release" niri soon but god I'm glad I set aside a beta week for bugfixes. We already stumbled upon and fixed several issues
A few latency tests before release confirm that niri's still doing good (at least on idle; I don't have any repaint scheduling yet but on idle it doesn't matter). The compositors are pretty much within the noise threshold from each other. Except some sway fullscreen bug and Shell losing one frame somewhere.
Very satisfied with the current state, even though there's plenty left to do. Took a lot of time and work but I've certainly learned a lot, and I'm glad to have contributed a bit to Smithay too!
Before adding more animations into niri, I'm making a "visual tests" application. It shows a set of hardcoded scenarios which I can quickly go through and visually check that everything looks right.
It uses solid color rectangles as "windows", but otherwise this is the real niri layout code and real niri + Smithay rendering code, drawing to a GTK GL area.
For example, on the last test you can see that my offscreen code currently clips CSD shadows (during the open animation).
For anyone following along, this is also finally the blog post where I explain in some detail how the latency tester works and what is shown on the plots.
@matt Hey! I did not determine that. It is a possibility that a11y is what makes GNOME Terminal worse than the GTK 4 terms (which currently have it disabled), but I haven't tested it.
The reason to write this is that a11y, at least in the GTK 4 VTE, is known to be slow, so much so that Ptyxis has an off-by-default setting for it. There are plans upstream to try to speed it up though.
You can toggle the enable-a11y property on the terminal widget to test it.