I upgraded to the new gkrellm-2.1.28-r1 today. This version of does not use the dock / slit of my window manager when started with the option --withdrawn. (I use OpenBox 3.1) gkrellm-2.1.27 works as expected. I'm downgrading for the moment. Reproducible: Always Steps to Reproduce: 1. emerge gkrellm-2.1.28-r1 2. launch it with gkrellm2 --withdrawn Actual Results: Window opens normally, not in slit/dock Expected Results: Window opens in window manager's slit/dock
This is being solved elsewhere AFAIK. I think it was gtk-2.4's problem... :-( Radek
The same problem on Gnome 2.6 and gtk+ 2.4 ;(
Just as a data point, I'm still on gtk+ 2.2 so this issue is not resticted to gtk+ 2.4. It seems that the same issue was already discussed in bug 45335. I'm sorry, but that bug did not turn up when I looked for existing bug reports (because I only looked for open ones). Maybe bug 45335 should be reopened and this bug marked as duplicate?
Could be down to differences between WMs. -r1 made withdrawal work with Fluxbox and GTK+ 2.4. I came up with the workaround which made it into -r1, where window hints are passed to the WM after the window is shown by GTK+. As far as I can tell, this helped because GTK+ 2.4 updates window hints when showing the window. The proper solution would probably be to withdraw the window with the help of GTK+, but I'm no expert on the API and couldn't find out how to implement it.
Markus: any idea ?
This looks like an inherent problem with GTK+ 2.4.0 to me, since it simply overrides WM hints already set. The best thing would probably be if there was a way to set this through the GTK+ API, maybe second best would be to respect an existing state hint (in update_wm_hints).
OK, I just re-emerged 2.1.28-r1 *without* the gtk2.4 patch applied to it and now everything works like a charm. It appears that the patch is a valid work-around but *only* if you are using gtk2.4, on gtk2.2 the patch actually *causes* the misbehaviour. Sigh...
---QUOTE--- It appears that the patch is a valid work-around but *only* if you are using gtk2.4, on gtk2.2 the patch actually *causes* the misbehaviour. ---END-QUOTE--- Actually, the patch doesn't work for all gtk
Sorry about that... to finish my idea... The patch doesn't work for all gtk-2.4.0 users and it also doesn't work for all fluxbox users it seems. At least, it doesn't work for me. I was using fluxbox-0.1.14-r2 and, after reading comment #4, I thought that upgrading fluxbox to 0.9.8-r1 would make things work again, but it doesn't seem to be the case
I spoke too soon ... the name of the executable used to run fluxbox seems to have changed between versions... it is now startfluxbox. After using that gkrellm work like before.
After upgrading to gtk+2.4 because it was marked stable, I was still having problems with gkrellm withdrawing to the slit. My impression (actually sparked by comment #16 in bug 45335) is that the whole problem is a timing issue. So I put a sleep .5s between starting gkrellm and openbox, which fixes the problem for me!
