I am very happy to announce a new version of Casilda!
A simple Wayland compositor widget for Gtk 4.
This release comes with several new features, bug fixes and extra polish that it is making it start to feel like a proper compositor.
It all started with a quick 1.2 release to port it to wlroots 0.19 because 0.18 was removed from Debian, while doing this on my new laptop I was able to reproduce a texture leak crash which lead to 1.2.1 and a fix in Gtk by Benjamin to support Vulkan drivers that return dmabufs with less fd than planes.
At this point I was invested to I decided to fix the rest of issues in the backlog…
Fractional scaleCasilda only supported integer scales not fractional scale so you could set your display scale to 200% but not 125%.
For reference this is how gtk4-demo looks like at 100% or scale 1 where 1 application/logical pixel corresponds to one device/display pixel.
*** Keep in mind its preferable to see all the following images without fractional scale itself and at full size ***
Clients would render at the next round scale if the application was started with a fractional scale set…
Or the client would render at scale 1 and look blurry if you switched from 1 to a fractional scale.
In both cases the input did not matched with the renderer window making the application really broken.
So if the client application draws a 4 logical pixel border, it will be 5 pixels in the backing texture this means that 1 logical pixel correspond to 1.25 device pixels. So in order for things to look sharp CasildaCompositor needs to make sure the coordinates it uses for position the client window will match to the device pixel grid.
My first attempt was to do
((int)x * scale) / scalebut that still looked blurry, and that is because I assumed window coordinate 0,0 was the same as its backing surface coordinates 0,0 but that is not the case because I forgot about the window shadow. Luckily there is API to get the offset, then all you have to do is add the logical position of the compositor widget and you get the surface origin coordinates
gtk_native_get_surface_transform (GTK_NATIVE (root), &surface_origin_x, &surface_origin_y); /* Add widget offset */ if (gtk_widget_compute_point (self, GTK_WIDGET (root), &GRAPHENE_POINT_INIT (0, 0), &out_point)) { surface_origin_x += out_point.x; surface_origin_y += out_point.y; }Once I had that I could finally calculate the right position
/* Snap logical coordinates to device pixel grid */ if (scale > 1.0) { x = floorf ((x + surface_origin_x) * scale) / scale - surface_origin_x; y = floorf ((y + surface_origin_y) * scale) / scale - surface_origin_y; }And this is how it looks now with 1.25 fractional scale.
Keyboard layoutsAnother missing feature was support for different keyboard layouts so switching layouts would work on clients too. Not really important for Cambalache but definitely necessary for a generic compositor.
Popups positionersCasilda now send clients all the necessary information for positioning popups in a place where they do not get cut out of the display area which is a nice thing to have.
Cursor shape protocolCurrent versions of Gtk 4 requires cursor shape protocol on wayland otherwise it fallback to 32×32 pixel size cursors which might not be the same size of your system cursors and look blurry with fractional scales.
In this case the client send an cursor id instead of a pixel buffer when it wants to change the cursor.
This was really easy to implement as all I had to do is call
gtk_widget_set_cursor_from_name (compositor, wlr_cursor_shape_v1_name (event->shape)); GreetingsAs usual this would not be possible without the help of the community, special thanks to emersion, Matthias and Benjamin for their help and support.
Release NotesSource code lives on GNOME gitlab here
git clone https://gitlab.gnome.org/jpu/casilda.git Matrix channelHave any question? come chat with us at #cambalache:gnome.org
MastodonFollow me in Mastodon @xjuan to get news related to Casilda and Cambalache development.
Happy coding!
If you have recently installed a very up-to-date Linux distribution with a desktop environment, or upgraded your system on a rolling-release distribution, you might have noticed that your home directory has a new folder: “Projects”
Why?With the recent 0.20 release of xdg-user-dirs we enabled the “Projects” directory by default. Support for this has already existed since 2007, but was never formally enabled. This closes a more than 11 year old bug report that asked for this feature.
The purpose of the Projects directory is to give applications a default location to place project files that do not cleanly belong into one of the existing categories (Documents, Music, Pictures, Videos). Examples of this are software engineering projects, scientific projects, 3D printing projects, CAD design or even things like video editing projects, where project files would end up in the “Projects” directory, with output video being more at home in “Videos”.
By enabling this by default, and subsequently in the coming months adding support to GLib, Flatpak, desktops and applications that want to make use of it, we hope to give applications that do operate in a “project-centric” manner with mixed media a better default storage location. As of now, those tools either default to the home directory, or will clutter the “Documents” folder, both of which is not ideal. It also gives users a default organization structure, hopefully leading to less clutter overall and better storage layouts.
This sucks, I don’t like it!As usual, you are in control and can modify your system’s behavior. If you do not like the “Projects” folder, simply delete it! The xdg-user-dirs utility will not try to create it again, and instead adjust the default location for this directory to your home directory. If you want more control, you can influence exactly what goes where by editing your ~/.config/user-dirs.dirs configuration file.
If you are a system administrator or distribution vendor and want to set default locations for the default XDG directories, you can edit the /etc/xdg/user-dirs.defaults file to set global defaults that affect all users on the system (users can still adjust the settings however they like though).
What else is new?Besides this change, the 0.20 release of xdg-user-dirs brings full support for the Meson build system (dropping Automake), translation updates, and some robustness improvements to its code. We also fixed the “arbitrary code execution from unsanitized input” bug that the Arch Linux Wiki mentions here for the xdg-user-dirs utility, by replacing the shell script with a C binary.
Thanks to everyone who contributed to this release!
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.