GTK+ – Page 2 – scrambled tofu

and now for something from the school of pure evil (setting a background on a GtkTextView)

This is something that comes up from time to time, someone wants to set some attractive background on a GtkTextView. Well, unfortunately for you, the theme engine isn't able to help you here because GtkTextView never calls gtk_paint_box() or friends. Still, today I stared at the code for a bit and came up with a particularly hacky solution: see for yourself. You have to handle everything yourself, resizing (hook into size-allocate), scaling whatever is needed. You could probably cheat though and call something like gtk_paint_box() and then let the theme engine do that bit of the work for you… I've not tried.

Just to prove it works:

This depends on what is basically an implementation detail of the widget, and I make no promises that it will continue working in the future. With that warning in mind, do what you will with the code.

P.S. the background image is a photo of the art in my hotel room. If I was Google, I'd totally sue.

quick and dirty icon theme viewer

So very often I find myself trying to find the name of an icon in the icon theme, and I end up having to search through my icon theme with a combination of find and eog. Usually I miss the icon on my first pass through.

Today I cracked, and decided to hammer together a quick and dirty viewer and searcher for the icon theme which looks something like this:

It's written in PyGTK and so far only has the single feature of 'Search' (this is my 90% case). It could be a lot more advanced if people wanted to hack on it: it could select themes, show whether an icon is in this theme or a parent theme, what sizes are available, etc. I will certainly accept patches!

Hopefully other people find this useful too. Source code is here.

GTK+ client-side-windows and threading

Some people (including me) had noticed that recent Empathy's video calling was breaking with recent GTK+ builds. Some people (not including me) were smart enough to work out the bug was related to client-side-windows.

In CSW-enabled GTK+, calls to GDK_WINDOW_XID() — the function with returns the XID of a GdkWindow — implicitly makes a call to gdk_window_ensure_native() before retrieving the XID. It does this so that there is a window on the X server to return the XID for, and thus ideally no one's application will break under CSW. The problem in Empathy was that the first call to GDK_WINDOW_XID() happened in a thread, which in the olden days would have been harmless, but now it can magically result in your window being allocated server side.

The fix for Empathy (and maybe your program to) is to call gdk_window_ensure_native() as soon as the widget is realized. In Empathy we're calling GDK_WINDOW_XID(), because we don't want to depend on GTK+ 2.18, which looks a lot like this.