Bug 9852

Created attachment 3741 [details]
Yaakov's first draft

The attached patch was what I had in mind but it has no effect.  I'm posting
this now to at least start the discussion.

You may wish to refer to the FD.o EWMH specs:

http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html

Created attachment 3742 [details]
Jon's first draft

Yaakov,

Here's a slightly improved version of that patch, and working version of the
small testcase you pointed out to me.

Sadly, doesn't work quite as well as it might: to remove a window from the
taskbar, not only do you have to remove the WS_EX_APPWINDOW style, but also add
the WS_EX_TOOLWINDOW style, which changes the size of the title bar etc.

So this might look ok for some title-bar less dialog-style windows, but looks a
bit odd otherwise.

Created attachment 3743 [details]
Test case

Created attachment 3744 [details]
Jon's second draft

Attached is an updated version of this patch which fixes that problem, but the
changes involved are rather larger than I'm happy with.

This patch re-arranges the sequence of events at window creation so we check
all the styles before we first show the window (which is good)

However, it then exposes another problem: at the moment we only do this window
styling at window creation time, if the hinting properties are updated after
the window is shown, we don't use them.

This is accidentally demonstrated in the small test case posted previously as
XMapWindow() occurs before XChangeProperty(): reverse the order and window is
reliably styled correctly, but as it stands it is timing sensitive as to if the
XChangeProperty() takes effect before or after we show the window...

So, I've added some more code to use the PropertyNotify event to watch for hint
changes, but as written this is very inefficient, so needs more work...

Created attachment 3745 [details]
Jon's third draft

Attached is an updated version of this patch, which does override-redirect
windows more correctly, and is a bit more careful about checking that the
PropertyNotify event is of interest before sending the WM_WM_HINTS_EVENT
message to update the style.

One thing I can't get to work correctly and efficiently is supporting windows
which turn the NET_WM_STATE_SKIP_TASKBAR state on or off after the window is
created.  It seems this needs some code to conditionally hide/show the window
depending on if the corresponding WS_ bits are changing, but the correct
sequence of events to get this to work eludes me at the moment.

Note that for e.g. the gmplayer control panel constantly updates it's
WM_NORMAL_HINTS whilst is being moved around the screen so it's no good to
unconditionally hide and then show the window on every property change, this
leads to a really unpleasant flickering.

So, this still needs more testing and work...

Created attachment 3746 [details]
Test case 2

The attached test program also shows another problem with the
NET_WM_STATE_SKIP_TASKBAR property change: the size of the window isn't
adjusted correctly to keep the client area the same, but I this think may just
be a problem that ValidateSizing() doesn't understand the WS_EX_TOOLWINDOW
style correctly...

(In reply to comment #5)
> Created an attachment (id=3745)
> Jon's third draft
> 
> Attached is an updated version of this patch, which does override-redirect
> windows more correctly, and is a bit more careful about checking that the
> PropertyNotify event is of interest before sending the WM_WM_HINTS_EVENT
> message to update the style.
> 
> One thing I can't get to work correctly and efficiently is supporting windows
> which turn the NET_WM_STATE_SKIP_TASKBAR state on or off after the window is
> created.  It seems this needs some code to conditionally hide/show the window
> depending on if the corresponding WS_ bits are changing, but the correct
> sequence of events to get this to work eludes me at the moment.
> 
> Note that for e.g. the gmplayer control panel constantly updates it's
> WM_NORMAL_HINTS whilst is being moved around the screen so it's no good to
> unconditionally hide and then show the window on every property change, this
> leads to a really unpleasant flickering.
> 
> So, this still needs more testing and work... 

This doesn't appear to be working for me; items still show up on the taskbar. 
Furthermore, the Always On Top option does not appear when this patch is used.

BTW, XMMS is an example of a real app that uses this, for all the additional
windows (playlist, equalizer, etc.).

This may be useful:

http://www.freedesktop.org/wiki/Software/XTesting

Particularly the section entitled "EWMH/ICCCM compliance".

Created attachment 4092 [details]
skip taskbar / unmap minimized windows patch set

Updated patch set.  Fixed the breakage to the system menu for X windows not
getting the X server customizations.  Tested with XMMS, windows seem to be
removed from taskbar correctly.

(In reply to comment #8)
> This may be useful:
> 
> http://www.freedesktop.org/wiki/Software/XTesting
> 
> Particularly the section entitled "EWMH/ICCCM compliance".

Thanks.  metacity-window-demo pointed to by that is very useful for testing
(although we don't support all the styles that uses yet)

Thanks for the patches.  Do these replace any current patches, or are they
additions thereto?

(In reply to comment #11)
> Thanks for the patches.  Do these replace any current patches, or are they
> additions thereto?

This set replaces 1.5-hint-handling-skip-taskbar.patch and
cygwin-unmap-minimized-windows.patch

Trying these patches with 1.6.2 on *Win7 build 7100*:

1) The first test case still shows on the taskbar, but with a utility window
border (IOW top decoration is narrower and has only a small [X]); w/o the
patches it has a normal decoration.

2) Second test case shows on the taskbar no matter what, but the window
decoration does change with the toggle where it did not do so before.  But, the
toggle button and its enclosing window grow vertically with each press, which
does not occur without these patches.

3) In fbpanel, when I open the apps menu, a small black square appears in the
upper left corner of the screen, and goes away when the menu is closed.

4) With the patches, I can no longer replicate the issue with menus staying on
screen after a minimize of the parent window.

5) Utility windows of gmplayer, qmmp, xine, and xmms are all listed on the
taskbar as well.

Again, this is Win7, where the taskbar itself has changed quite a bit since
Vista or XP.  If you're seeing different results on XP, perhaps I should try in
a VM (but not before next week).

Jon, are you able to reproduce (3) in comment 13?

(In reply to comment #14)
> Jon, are you able to reproduce (3) in comment 13?

Yes.  That's very strange.  That's a 10x10 top-level X Window.  It seems to be
owned by fbpanel so I guess it must be invisible when things are working
correctly...

After the SWT/Motif patch in bug 9848:

$ patch -p1 < ../../../cygwin-Re-order-window-creation-process.patch      
patching file hw/xwin/winmultiwindowwindow.c
Hunk #1 succeeded at 710 (offset -13 lines).
patching file hw/xwin/winmultiwindowwm.c
Hunk #7 FAILED at 1054.
Hunk #8 succeeded at 1113 (offset 43 lines).
Hunk #9 succeeded at 1560 (offset 39 lines).
Hunk #10 succeeded at 1639 (offset 39 lines).
1 out of 10 hunks FAILED -- saving rejects to file hw/xwin/winmultiwindowwm.c.rej

The other patches still apply.

Created attachment 4262 [details]
skip taskbar / unmap minimized windows patch set

Thanks for checking this.  Attached a refreshed patch set.  Fixed a rather
obvious bug in PropertyChange handling as well.

(In reply to comment #17)
> Created an attachment (id=4262)
> skip taskbar / unmap minimized windows patch set

Thanks for the refresh.  I'm still seeing issues 2 and 3 from comment 13.

Created attachment 6227 [details]
Improved testcase which allows to set initial taskbar state of window

I've gone over this patch set again, updated it and removed the dangerous stuff related to reworking ordering of things during window creation, and pushed it to the branch skip-taskbar-hint on my fd.o tree.

This now uses the ITaskbarList COM interface, which seems to be the only reliable way of adding/removing the window from the taskbar.

(In reply to comment #18)
> Thanks for the refresh.  I'm still seeing issues 2 and 3 from comment 13.

This should also fixes the window size increase issue (which ws due to winUpdateWindowPosition() assuming the WS_EX_APPWINDOW style when recalculating the window size), and the issue with InputOnly windows being made visible.

Fix shipped in 1.12.0-2