sillysloft / fluxbox

Fluxbox Window Manager (Mirror)
http://fluxbox.org/news/
Other
0 stars 1 forks source link

Sticky windows cannot be removed from taskbar #963

Open sillysloft opened 14 years ago

sillysloft commented 14 years ago

Fluxbox version: 1.1.1-2 (package from Ubuntu 9.10)

It seems that setting a window sticky will remove its property "skip_taskbar". I identified the problem using the panel Tint2. I thought it was a Tint2-related issue, but a Tint2 developer identified the problem as a Fluxbox bug.

Take for example the application lxterminal. I activate the property skip_taskbar on it: wmctrl -r lxterminal -b toggle,skip_taskbar This hides the entry for lxterminal in the panel (here, Tint2). Fine. Then: wmctrl -r lxterminal -b toggle,skip_taskbar Then lxterminal appears again in the panel. Still fine.

Now, make the window sticky: wmctrl -r lxterminal -b toggle,sticky

Try to remove it from the taskbar: wmctrl -r lxterminal -b toggle,skip_taskbar This fails. The application is still in the panel.

Note that wmctrl had some effect because, if you remove the sticky property: wmctrl -r lxterminal -b toggle,sticky it does remove that property, and the application disappears from the taskbar! It is like the sticky property was cancelling the skip_taskbar property. If you activate again stickiness, the application will re-appear.

Below is the comment from the Tint2 developer, sent after I report the problem to Tint2 team: """ ok, i tried it today myself in fluxbox. I have to say, that it is a bug in fluxbox. After setting the sticky state, _NET_WM_STATE does not contain anymore the SKIP_TASKBAR. Therefore tint2 shows it in the taskbar. On the other hand there is set an unknown atom (probably an atom defined by fluxbox, for correct handling of sticky windows which have skip_taskbar) """

The thread is there: http://code.google.com/p/tint2/issues/detail?id=186

Reported by: vivien_mallet

sillysloft commented 8 years ago

Original comment by: baghira-style

sillysloft commented 8 years ago

This isn't reproducible in 1.3.6, _NET_WM_STATE is correct and reflected correctly, no matter how much I try.

Original comment by: baghira-style