GTK+ Archive

There’s no denying that not everyone is happy with the state of the GTK world, and I, too, have argued that GNOME’s massive presence and seeming unwillingness to cooperate with or even consider the existence of other GTK-based desktop environments is doing real, measurable harm to the likes of Xfce, Cinnamon, and others. A major root cause is a feeling that GTK is nothing but a vessel for GNOME, and that the project doesn’t really seem to care much about anyone else. GNOME Foundation member and all-round very kind person Hari Rana, also known as TheEvilSkeleton, penned a blog post highlighting the other side of the story. In essence, what it comes down to, according to Rana, is that it’s better for everyone if GNOME-specific widgets are moved out of GTK, and into something else – first libhandy, and now its succesor libadwaita, splitting the toolkit (GTK) from the design language (libadwaita). This allows GNOME developers to focus on, well, GNOME, and frees up time for GTK developers to focus on generic widgets that aren’t specific to GNOME. Thanks to the removal of GNOME widgets from GTK 4, GTK developers can continue to work on general-purpose widgets, without being influenced or restricted in any way by the GNOME HIG. Developers of cross-platform GTK 3 apps that rely exclusively on general-purpose widgets can be more confident that GTK 4 won’t remove these widgets, and hopefully enjoy the benefits that GTK 4 offers. Hari Rana From a GNOME standpoint, this makes perfect sense, and I can obviously see the benefits for them. However, what this entire post seems to ignore is that the main effect of the split between GTK 4 and libadwaita is that various GTK applications, now targeting libadwaita because of GNOME’s immense popularity, simply no longer integrate very well with other desktops, like Xfce or Cinnamon. GNOME is, of course, under no obligation to remedy this situation, but at the very least they could acknowledge this is a very real problem that their fellow developers working on Xfce, Cinnamon, MATE, and others, have to deal with. It works the other way around too. Developers targeting the Linux desktop, where GNOME is more or less the default, have to choose between making a GTK application that integrates well with GNOME by opting for libadwaita and leaving non-GNOME users with a crappy experience, or opting for ‘pure’ GTK 4 and leaving GNOME users with a worse experience. Neither option is good for the Linux desktop as a whole. The very real ripple effects of GNOME’s choices regarding GTK and libadwaita are seemingly being stubbornly ignored, neglected, and often not even acknowledged at all, and it’s no surprise this creates an immense amount of friction in the wider desktop Linux community. It just feels smug and careless, and of course that’s going to rub people the wrong way- regardless of the purity of your intentions.

We first introduced support for dmabufs and graphics offload last fall, and it is included in GTK 4.14. Since then, some improvements have happened, so it is time for an update. GTK Development Blog This one’s for the ones smarter than me.

Recently, GTK gained not one, but two new renderers: one for GL and one for Vulkan. Since naming is hard, we reused existing names and called them “ngl” and “vulkan”. They are built from the same sources, therefore we also call them “unified” renderers. As mentioned already, the two renderers are built from the same source. It is modeled to follow Vulkan apis, with some abstractions to cover the differences between Vulkan and GL (more specifically, GL 3.3+ and GLES 3.0+). This lets us share much of the infrastructure for walking the scene graph, maintaining transforms and other state, caching textures and glyphs, and will make it easier to keep both renderers up-to-date and on-par. GTK Development Blog This is well above my paygrade, but I’m sure it’s still of interest to y’all.

In the best case, we may be able to avoid feeding the data through the compositing pipeline of the compositor as well, if the compositor supports direct scanout and the dmabuf is suitable for it. In particular on mobile systems, this may avoid using the GPU altogether, thereby reducing power consumption. I don’t understand what’s happening but it seems like a good idea? Can anyone help?

I'm not even remotely versed enough in the world of GTK+ to say anything meaningful about this, but it does seem like a welcome move for developers and users of GTK+ alike.

The latest version of GTk+, version 3.2, has been released. While this new release contains many smaller, less invasive changes, it also has experimental support for two very important new features. First, the ability to run Gtk+ applications inside a browser using HTML5. Second, initial support for the Wayland display server.

GTK+ 3.0 has been released two days ago. This major release includes a large number of improvements, including a full switch from the old X11 drawing API to cairo for rendering, a switch to XorgInput2 for more flexible input device management, and a new theming API sporting a CSS-like syntax for theme configuration.

The Gtk+ team is working on a roadmap to structure the development process of the Gtk+ 3.0 release and to open up the involved decision making progress. The first draft has been sent to the devel mailing list, and is now open for debate. Coincidentally, the draft roadmap also provides a nice overview of the features and changes planned for Gtk+ 3.0.

"GTK+ may be called many things. I would call it 'simple' and sometimes even 'elegant', refering to its foundation of pure, elegant C. But not everyone is compelled to use those terms, using terms like 'clumsy' and 'unwieldy' instead. Yes, there is a lot disagreement. But there's one thing almost everyone would agree to: that GTK+ isn't pretty." This is about to change.

Imendio has released a binary build for the native Gtk+ Mac OS X port. It can be downloaded at the project's webpage. The installed frameworks can be used directly in the Xcode IDE and come with a project template that sets all the necessary flags and variables to build against them.

At last week's Guadec meeting, Kristian Rietveld delivered the GTK+ "state of the union" report. GTK+ is the multi-platform toolkit behind a number of popular applications and, perhaps most well known, the Gnome Desktop environment for Linux. Read the full report here.

Ars Technica has an article about recent proposals to evolve the GTK+ toolkit: "The developers of GTK are preparing for a major overhaul that aims to resolve many of the framework's most significant deficiencies and add next-generation features that will increase flexibility and simplify development. This effort is still in the earliest planning stage, but several intriguing proposals provide valuable insight into some of the changes envisioned by prominent developers."

"GNOME theme engine designer Andrea Cimitan has implemented support for transparent widgets in the Murrine GTK theme engine, bringing Vista-like translucent glass effects to the GNOME desktop. Cimitan used RGBA colormaps to implement the feature and says that, with only 10 or 20 extra lines of code, translucency can easily be added to other theme engines that support RGBA. Cimitan says that the addition of translucency effects proves that critics of GTK are wrong. "n the last week I've seen a lot of people claiming about 'lacks' of Gtk+ capabilities," wrote Cimitan in a blog entry. "Some of them still think that Gtk+ doesn't have RGBA support... Or it will require nasty hacks. This is absolutely false."

"Ars was at FOSSCamp this weekend. Think of FOSSCamp as an 'un-conference' without a set agenda where the minds behind open source projects get together and plot world domination (and, err, ways to improve their code). One fascinating session (and one that shows how FOSSCamp works and why it's so productive) was given by Mirco Muller, who discussed using OpenGL in GTK applications. Muller - the developer behind Cairo-Clock and the LowFat image viewer - talked about the state of OpenGL support in desktop applications and described various techniques that developers can use to make OpenGL content integrate better with conventional GTK user interfaces."