i want to recreate a UI similar to the one below in Gtk4. It’s a list of colors and a ColorChooserWidget to modify the selected color. Making each color a color button would be suboptimal from a usability point of view as we’d get a dialog popping up for modifying each color.
Since GtkColorChooserWidget is deprecated (why?) in Gtk4, what’s the best way forward here? Hope that it’ll stay around for the foreseeable future and that there will eventually be a proper replacement? Or should I roll my own (bad) copy of it?
@carrotIndustries is talking about the widget on the far right (purplish square with a slider to its left and color value on top).
@carrotIndustries, Don’t worry. Deprecation simply just means that the widget/API will be removed in a major version. So, GtkColorChooserWidget is planned to be removed (or rather, privated) in GTK5 and it will keep working in GTK4 for its whole lifetime.
As for why it was deprecated, I don’t know. From the deprecation notice,
Direct use of GtkColorChooserWidget is deprecated.
it seems like GTK4 is still using this widget internally for its GtkColorDialog API.
We deprecated all *Chooser interfaces alongside their corresponding dialogs, as that’s not the kind of API we want to expose going forward. That had the knock-on effect of deprecating most of the involved widgets, so we can move them into the private/internal API with GTK5.
The embedded use case has always been more of an artefact of how the API was implemented for GtkFileChooser in GTK2 that unfortunately became a pattern replicated over the years for other *Chooser implementations; embedding the color plane, scale, and selector into other windows was not really something we encouraged in applications.
It’s a common pattern in drawing applications, though they’re mostly using their own widgets for various reasons.
While the new ColorDialogButton API might be “good enough” for many use cases, it’s not a full-featured replacement for the embedded widget.
Picking a color requires opening another window
There is no signal that gets emitted as the user selects a color in the color chooser, the rgba property only updates after pressing okay
For applications that require interactively tweaking a color until it looks right, users would now have to repeatedly open and close the dialog which is of course super annoying.
Also, as an application developer, seeing useful widgets being deprecated without a feature-equivalent replacement is rather frustrating.
Indeed: GTK is not really a graphics-oriented toolkit, so offering a color selector for drawing applications in the default set of widgets would be either incongruous, or would require an API and feature set covering all possible use cases of drawing apps.
It’s not meant to be a full replacement of the embedded widget.
Color picking goes through the portal API, so it can work on different platforms and desktop environments; this alone requires a certain degree of complexity in the API.
That’s because the API is designed for async behaviour, not as a separate modal dialog: you ask the user for a color, and you get a color at the end. Same thing happens for file selection.
I understand completely, but you have to look at it from the perspective of the toolkit developers. We are, just like you, maintaining a software project—and we have to make do with the resources we have. We have to keep the API in a certain equilibrium with the amount of people actually working on the project.
Having said that, exposing a color selection widget in GTK5 may still be possible. In the meantime, you can still use the existing (deprecated) widget: the API will keep working until GTK4 get EOL’d, which is going to happen when GTK 6 is released.
That widget is not good for drawing applications at all as it does not have precise input for the HSV values. I don’t think it is really good for your use case either, it takes up too much space and leaves a large margin at the bottom. If that window is a modal dialog it seems it would be too large to see the colors changing underneath.
