GTK+ scrollbars and themes (bug): please forward

[mawarkus t-online de (Matthias Warkus)]

[I am not subscribed to any GTK+ mailing list, and I don't even know
their addresses. It would be nice if someone forwarded this to the
relevant list(s) for GTK+ issues.]


Changing themes with gnomecc (Xenophilia is really great!) I found
what looks like a bug in GTK+'s theme handling.

Themes like GTKStep or Xenophilia arrange the arrow buttons of a
scrollbar both at one end of the bar, in a NeXTsteppy fashion, which
is cool. Now, if I change to another theme engine that arranges the
buttons where they normally are, they are redrawn with the other
themes' graphics, but the arrow buttons remain where they are. They
don't change their width, either, if the scrollbar width in the new
theme is different.

Whether newly started programs have changed their scrollbar button
alignment and width after a theme engine change or not seems
completely erratic. Actually, those who start with the drive grinding
normally display the new theme correctly; thus I suspect the buggy
behaviour is somehow related to pages of libraries remaining in memory
(dlopened?) when they shouldn't. I suspect, too, that `broadcasting' a
kind of signal to all GTK+ apps to drop their references into the
engine code and reload the new code would be a possible fix. I am a
newbie at GTK+ programming, so I really don't know how to do this
myself.

As a side note, the theme selector capplet's preview frame has stopped
working for me with a recent CVS update. Did anyone else experience
this?

mawa
-- 
Come home at night with a swirling in my head, Reach for the pillow,
miss the whole darn bed
                                -- Joe Riggens, "Drunk", '50 R&B song.