I am very happy to announce a new version of Casilda!
A simple Wayland compositor widget for Gtk 4 originally created for Cambalache
This new version brings Drag&Drop and clipboard support / integration with the host compositor which means you can drag something from a host application and drop it on an application window embedded in a Casilda compositor widget and vice versa!
After a very rugged GUADEC presentation where I tried to show how to create simple Gtk application from slides made with Cambalache using a Casilda compositor to embed GNOME Builder and Cambalache itself I decided to fix all the issues I found so I could redo the presentation and upload it as a video.
This is a screenshot of the slider window, inside it there is a Casilda compositor (green line) used to embed a Cambalache instance which uses another CasildaCompositor (red line) to preview the UI.
Things that possi-bly could go wrong and did:
After fixing all the bugs and keyboard support I started working on adding Clipboard integration with the host.
Clipboard supportIntegrating the clipboard between Casilda and Gtk was fairly easy since all I needs to be done is copy all the clipboard data provided by wlroots wlr_seat::request_set_selection event to GdkClipboard and call wlr_seat_set_selection() on GdkClipboard changed signal.
Wlroots client to GtkIn other to do this I created a new GdkContentProvider that uses a wlr_data_source as the source of the data and set the provider as the content of the clipboard with gdk_clipboard_set_content().
Internally when a clients wants to get data from the clipboard the new provider creates a unix pipe to read data from wlroots by writing to the pipe with wlr_data_source_send() and reading form the other end using g_output_stream_splice_async().
Gtk to wlroots to clientTo go in the other direction I created a new wlr_data_source that uses a GdkClipboard as source and set selection with wlr_seat_set_selection()
Internally gdk_clipboard_read_async() is called to initiate the data read when wlr_data_source send() method is invoked to send the data to the client.
Drag & Drop supportIntegrating D&D was not as easy as the clipboard. Setting it up to work within Casilda is easy enough other than wiring up some events all I had to do was draw the drag icon surface.
The first thing I did after getting the drag surface was draw it at the pointer coordinates which produced blurry results since pointer coordinates are fractional which means they do not always align with the pixel grid.
That was all nice and good but now I needed to start integrating the drag with Gtk (host compositor) so right after calling wlr_seat_start_pointer_drag() I created a GdkDrag with gdk_drag_begin() and used gtk_drag_icon_set_from_paintable() to set the drag icon and I noticed it was still blurry!!!
After a minute of confusion I realized that Gnome Shell (mutter) must be making the same mistake I did before so I decided to see if I could fix it!
Thanks to Michel Dänzer for guiding me and reviewing my MR, Gnome Shell 51 should have sharp drag icons!
Now back to integrating DnD with the host compositor.
These are all the different use cases that are needed to make D&D work transparently across host and guest compositors:
Of course wlroots only contemplates the first use case, the other two cases are specific to Casilda.
Casilda to HostSo far we can detect when a client start a drag, let wlroot handle it and create a GdkDrag to let Gtk initiate another drag at the host level.
This means that when a client embedded in a CasildaCompositor initiates a drag there are two simultaneous drags at the same time, in the guest and host compositors. Keep in mind Casilda always delegates drag icon rendering to the host compositor.
During normal operation Casilda gets events from an event controller, but while on a drag operation events are not sent to the client at least not in the normal way, for that you can use a GtkDropTargetAsync and connect to the various signals for example I use drag-motion to forward events to the client.
Host to CasildaWhen a Drag is initiated in the host compositor Casilda reuses the GtkDropTargetAsync created to track motion events and connects to drag-enter signal to create a proxy drag source in wlroots and synthesize a button release event on GtkDropTargetAsync::drop to trigger the drop on the guest side.
Here is a screencast off all the different use cases in action.
As you can imagine getting all this to work together correctly is not trivial and I expect to be subtle bugs in different corner cases so please if you find one of those file a bug and include a screencast if possible.
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!
Read more of this story at Slashdot.
KDE is on the news because of a controversial proposal to define an official “AI” (LLM) policy. Other projects have tried their hand at similar policies and stances but, in my opinion, they miss the mark about the goal of such initiatives. I think that the point of these statements is shaping social norms and not micro-managing developer workflows. They should be about signalling what kind of behavior we want, and what kind we reject.
This proposal does not go into detail about the many problems that LLM have caused to society, workers, the environment. It goes without saying that all these ills are fundamentally opposed to the humanist spirit of GNOME.
With all that in mind, here is what I personally think a GNOME LLM policy could be:
A GNOME Project LLM Policy The GNOME Project prioritizes the social and human aspects of collective software creation. Therefore: 1. LLMs ("AI") can not be used to create or modify code submitted to GNOME, or hosted on GNOME infrastructure. You might be asked to prove your code meets this requirement. You might be banned for trying to circumvent this policy. Example Guidelines for ContributorsThese are just a draft of the kind of criteria one could use to evaluate if a submission fits the policy.
GNOME is not just software that happens to ship every six months. That is just a delusion we have been holding up for the last 30 years to keep our loose group of colleagues, friends, and acquaintances, together.
GNOME exists as a collective that find joy in reaching beyond our individual limitations to achieve something bigger. These people, this joy, are the whole point of the project. Contributors are not payroll, a liability, that we hope to downsize next quarter.
“Come do free labor for a handful of corporations by reviewing chatbot output in your free time” is not an attractive proposition to young talented people in 2026. If we want GNOME to continue we need to create an attractive and inviting social space where people are valued as people.
Just like the Foundation is moving to individual donations to stop depending on just a handful of companies, we need to look for the next 100 people that will donate a tiny bit of their time, instead of hoping that corporations will keep 10 overworked engineers on staff. We already have seen how companies will happily abandon a whole chunk of GNOME on a whim.
GNOME is not just software, and it should protect the social and human aspects that make it special. Our success metric is the community and social bonds we create. In the most literal sense GNOME is about the journey and the friends we make along the way.
Free Palestine.
FAQ How do you enforce this?You can not. People will still send LLM generated code. This policy makes it explicit that we do not welcome these careless submissions. We have a Code of Conduct that is 80% about telling other people what our values are, and 20% about handling unwanted behavior (“enforcing”). This is similar.
What if people simply lie about not using LLMs?This is the same problem as authorship, in the copyright sense. Whenever we receive new code we have to assume that “beyond a reasonable doubt” said code has been authored by the person contributing it. We make our best guess. The attached guidelines are a suggestion to make these new guesses.
Ok. But what if people are really good at lying?This policy is about the majority that will not even try to lie. See previous questions.
Read more of this story at Slashdot.
With the imminent release of GNOME 51, I realised I hadn’t released an update to Bobby in a few months.
The long tail of crash reports after a release just doesn’t seem to happen anymore when working with Rust. It’s just done and I moved on to other things.
Bobby follows the GNOME version number scheme for convenience, but I did not want to let a major version bump go by without at least one new useful feature. So I’ve added search.
It uses case-insensitive fuzzy matching to filter out rows and highlight cells using the system accent colour as you type.
Simple yet effective!
FutureThere are now two big features left that I want to implement:
I’m not sure which one to work on in the next cycle, so let me know in this poll on the Fediverse which is most useful to you.
Happy equinox and don’t forget to sanitise your database inputs!
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.