Main index > Usage problems > GTK Bug [SOLVED]

By aaa (User), on Tue Aug 16 16:03:25 2005: GTK Bug [SOLVED].

Whenever changing GTK themes using a utility such as gtk-chtheme or switch, all the open adesklets close, and the ~/.adesklets config file is recreated as the empty default.

By syfou (Core Developer & Desklet Author), on Tue Aug 16 18:37:02 2005.

adesklets is completely orthogonal to GTK (It just do not know anything about it). What you describe is most strange, as I never experienced any loss of data in $HOME/.adesklets (in fact, re-reading my code, I do not even see how it could happen). I am affraid you'll need to go in greater details: I would need at least the state of the configuration file & your process map immediately before and after the theme change.

This said, I suspect that your desklet starting sequence is at stake here: is it possible that you start the desklets in such a place that makes the starting sequence to be re-invoked wrongfully when changing the GTK theme?

By aaa (User), on Tue Aug 16 22:14:17 2005.

The starting sequence is simply executing them in a shell script that handles all startup apps, which is called by .xinitrc. When the app closes, no error messages are shown, neither in the terminal nor in the system log. Immediately when pressing "OK" the window vanishes and the config file resets.

I've tried launching this from the terminal to trap any output, but still, nothing is printed - not even in the TTY that X is launched from. If I kill the process manually, the config file is not rewritten, so it's not like the app is crashing. All the GTK theme programs are doing is sending a signal to all desktop windows that basically says "reload the gtkrc file", so I don't know why adesklets is even bothering with such a message. It should be like all other non-gtk apps and simply ignore it. Given that, there is no reason that adesklets should need to be re-invoked at all. It should simply be unaffected by the event.

The config file simply contains (excluding comments):
[/home/aaa/.desklets/weather/weather.py]
id=0 screen=0 x=0 y=766

Relevant processes before GTK theme change (ps aux output):
aaa 18138 0.5 1.3 7720 5220 ? S 22:02 0:00 python /home/aaa/.desklets/weather/weather.py
aaa 18143 0.7 1.1 7616 4600 ? S 22:02 0:00 adesklets /home/aaa/.desklets/weather/weather.py

After changing theme there simply are no processes related to adesklets.

By syfou (Core Developer & Desklet Author), on Wed Aug 17 02:13:34 2005.

aaa wrote:


All the GTK theme programs are doing is sending a signal to all desktop windows that basically says "reload the gtkrc file"

Now I see the problem; thank you for the precise pointer. Here is a patch against adesklets 0.4.10; I tested it with gtk-chtheme myself, and it works fine on my side.

The complete absence of any output is explained by the fact that adesklets detected the GTK notification as a perfectly normal and well-formed request for exit; this also explains why you were returned an empy $HOME/.adesklets file. When you point out that:

aaa wrote:


I don't know why adesklets is even bothering with such a message. It should be like all other non-gtk apps and simply ignore it. Given that, there is no reason that adesklets should need to be re-invoked at all. It should simply be unaffected by the event.

You are right that adesklets should be shielded against such messages (hence the patch), but the very use of a function such as gdk_event_send_clientmessage_toall() for notifying theme change is wrong. Sending unsollicited messages to all top-level windows is a very questionable practice, especially when simple mechanisms (atom check?) to identify windows that "speak" GTK are that straightforward to implement.

By aaa (User), on Wed Aug 17 12:08:54 2005.

syfou wrote:


Here is a patch against adesklets 0.4.10; I tested it with gtk-chtheme myself, and it works fine on my side.


Patch worked great - thanks!

syfou wrote:


You are right that adesklets should be shielded against such messages (hence the patch), but the very use of a function such as gdk_event_send_clientmessage_toall() for notifying theme change is wrong. Sending unsollicited messages to all top-level windows is a very questionable practice, especially when simple mechanisms (atom check?) to identify windows that "speak" GTK are that straightforward to implement.


I agree with this. Now if we could only get these developers to agree as well. Thanks again!


adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.