Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: So, this still needs more testing and work... Is this a candidate for -5? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl0R3kACgkQpiWmPGlmQSMILwCdGvTsUJO0rB7RZ2hQwLsQwJOJ /1cAn13cFQkJRY2OHgdhW3hNLS+Zr1Bn =SUOL -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
Jon TURNEY wrote:
Jon TURNEY wrote:
Yes, I see the same behaviour. When I looked into this, it seems to
be because the taskbar doesn't re-evaluate if the window should be in
it or not when the style is changed, but only when a ShowWindow() occurs.
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...
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.
(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...)
So, this still needs more testing and work...
Cygwin/X: Process _NET_WM_STATE_SKIP_TASKBAR hint in multiwindow mode.
To ensure that taskbar learns the correct state initially (since it
only updates it's idea of if it should show a button or not on a ShowWindow()),
we must be a bit more careful to do things in the right order and set all
the style flags before we show the window.
This is probably the right thing to do in any case as it means we can avoid
the messy appearance of the window changing style just after it is first shown
In this implementation, this is achieved by having WM_CREATE send a WM_WM_CREATE
message to our window manager thread, which then does all the work of
discovering
the windows style; it's convenient to do that there as accessing X internals is
awkward in the wndproc; possibly it's more than convenient as there might be
some
deadlock issue that thread avoids...
But note that this subtly changes the semantics of winCreateWindowsWindow():
previously the window was visible and drawn before that function returned, now
that happens asychronously; I'm not sure if that could cause problems or not...
Check PropertyChange events for any of the window properties which we consider
to decide on the window style, and update the window style. This allows the
styling of the window to change during it's lifetime.
We have to jump through hoops to ensure that the taskbar notices if the window
has changed it's style in a way which affects if the taskbar shows it or not.
---
xserver/hw/xwin/winmultiwindowwm.c | 43 ++
+++---
xserver/hw/xwin/winmultiwindowwindow.c |6
xserver/hw/xwin/winmultiwindowwm.c | 269
xserver/hw/xwin/winmultiwindowwndproc.c | 48 ++---
xserver/hw/xwin/winwindow.h |1
4 files changed, 199 insertions(+), 125 deletions(-)
Index: xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winmultiwindowwm.c 2009-01-14
00:29:34.456125000 +
+++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c2009-01-14
01:35:19.09375 +
@@ -485,31 +485,24 @@
return XSendEvent (pDisplay, iWin, False, NoEventMask, e);
}
-
/*
- * Updates the name of a HWND according to its X WM_NAME property
+ * See if we can get the stored HWND for this window...
*/
-
-static void
-UpdateName (WMInfoPtr pWMInfo, Window iWindow)
+static HWND
+getHwnd (WMInfoPtr pWMInfo, Window iWindow)
{
- wchar_t
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
Jon TURNEY wrote:
Yaakov (Cygwin/X) wrote:
Yaakov (Cygwin/X) wrote:
I have noticed that normal windows don't appear in the taskbar until
they are refocused upon. Can you confirm?
Ping?
I'm not dead, just sleeping ;-)
Yes, I see the same behaviour. When I looked into this, it seems to be
because the taskbar doesn't re-evaluate if the window should be in it or
not when the style is changed, but only when a ShowWindow() occurs.
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...
Process _NET_WM_STATE_SKIP_TASKBAR hint in multiwindow mode.
To ensure that taskbar learns the correct state initially (since it
only updates it's idea of if it should show a button or not on a ShowWindow()),
we must be a bit more careful to do things in the right order and set all
the style flags before we show the window.
This is probably the right thing to do in any case as it means we can avoid
the messy appearance of the window changing style just after it is first shown
In this implementation, this is achieved by having WM_CREATE send a WM_WM_CREATE
message to our window manager thread, which then does all the work of
discovering
the windows style; it's convenient to do that there as accessing X internals is
awkward in the wndproc; possibly it's more than convenient as there might be
some
deadlock issue that thread avoids...
But note that this subtly changes the semantics of winCreateWindowsWindow():
previously the window was visible and drawn before that function returned, now
that happens asychronously; I'm not sure if that could cause problems or not...
---
xserver/hw/xwin/winmultiwindowwm.c | 43 ++
+++---
xserver/hw/xwin/winmultiwindowwindow.c |6
xserver/hw/xwin/winmultiwindowwm.c | 202 +++-
xserver/hw/xwin/winmultiwindowwndproc.c | 48 +++
xserver/hw/xwin/winwindow.h |1
4 files changed, 149 insertions(+), 108 deletions(-)
Index: xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winmultiwindowwm.c 2009-01-06
02:41:28.90100 +
+++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c2009-01-06
02:42:54.09375 +
@@ -485,31 +485,24 @@
return XSendEvent (pDisplay, iWin, False, NoEventMask, e);
}
-
/*
- * Updates the name of a HWND according to its X WM_NAME property
+ * See if we can get the stored HWND for this window...
*/
-
-static void
-UpdateName (WMInfoPtr pWMInfo, Window iWindow)
+static HWND
+getHwnd (WMInfoPtr pWMInfo, Window iWindow)
{
- wchar_t *pszName;
Atom atmType;
int fmtRet;
unsigned longitems, remain;
- HWND *retHwnd, hWnd;
- XWindowAttributesattr;
+ HWND *retHwnd, hWnd = NULL;
- hWnd = 0;
-
- /* See if we can get the cached HWND for this window... */
if (XGetWindowProperty (pWMInfo-pDisplay,
iWindow,
pWMInfo-atmPrivMap,
0,
1,
False,
- XA_INTEGER,//pWMInfo-atmPrivMap,
+ XA_INTEGER,
atmType,
fmtRet,
items,
@@ -524,8 +517,25 @@
}
/* Some sanity checks */
+ if (!hWnd) return NULL;
+ if (!IsWindow (hWnd)) return NULL;
+
+ return hWnd;
+}
+
+/*
+ * Updates the name of a HWND according to its X WM_NAME property
+ */
+
+static void
+UpdateName (WMInfoPtr pWMInfo, Window iWindow)
+{
+ wchar_t *pszName;
+ HWND hWnd;
+ XWindowAttributesattr;
+
+ hWnd = getHwnd (pWMInfo, iWindow);
if (!hWnd) return;
- if (!IsWindow (hWnd)) return;
/* Set the Windows window name */
GetWindowName (pWMInfo-pDisplay, iWindow, pszName);
@@ -554,36 +564,12 @@
static void
PreserveWin32Stack(WMInfoPtr pWMInfo, Window iWindow, UINT direction)
{
- Atom
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
Jon TURNEY wrote: so needs more work... Just noticed this completely breaks override-redirect windows, so erm.. yes... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
Yaakov (Cygwin/X) wrote: Yaakov (Cygwin/X) wrote: I have noticed that normal windows don't appear in the taskbar until they are refocused upon. Can you confirm? Ping? I'm not dead, just sleeping ;-) Yes, I see the same behaviour. When I looked into this, it seems to be because the taskbar doesn't re-evaluate if the window should be in it or not when the style is changed, but only when a ShowWindow() occurs. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin/X) wrote: I have noticed that normal windows don't appear in the taskbar until they are refocused upon. Can you confirm? Ping? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklcYjEACgkQpiWmPGlmQSPB2wCfYlP/Q5uj4Zc/22YysGuPMdfD 2KMAoPDvRluC4H6VnVkJqbg4LrM7dZ1T =Ru0R -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
Yaakov (Cygwin Ports) wrote:
Jon,
Following up on our discussion about multiwindow not honouring
_NET_WM_STATE_SKIP_TASKBAR. 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
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.
Anyhow, try it out and see what you think.
Process _NET_WM_STATE_SKIP_TASKBAR hint in multiwindow mode.
---
xserver/hw/xwin/winmultiwindowwm.c | 43 ++
+++---
xserver/hw/xwin/winmultiwindowwm.c | 45
xserver/hw/xwin/winmultiwindowwndproc.c | 28 ---
2 files changed, 47 insertions(+), 26 deletions(-)
Index: xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winmultiwindowwm.c
+++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwm.c
@@ -1470,6 +1470,8 @@ winDeinitMultiWindowWM ()
#define HINT_BORDER(1L1)
#define HINT_SIZEBOX (1l2)
#define HINT_CAPTION (1l3)
+/* Windows extended window styles */
+#define HINT_SKIPTASKBAR (1L0)
/* These two are used on their own */
#define HINT_MAX (1L0)
#define HINT_MIN (1L1)
@@ -1480,7 +1482,7 @@ winApplyHints (Display *pDisplay, Window
static Atom windowState, motif_wm_hints, windowType;
Atom type, *pAtom = NULL;
int format;
- unsigned longhint = 0, maxmin = 0, rcStyle, nitems = 0 , left = 0;
+ unsigned longhint = 0, exHint = 0, maxmin = 0, rcStyle, nitems = 0 ,
left = 0;
WindowPtrpWin = GetProp (hWnd, WIN_WINDOW_PROP);
if (!hWnd) return;
@@ -1491,22 +1493,31 @@ winApplyHints (Display *pDisplay, Window
if (windowType == None) windowType = XInternAtom(pDisplay,
_NET_WM_WINDOW_TYPE, False);
if (XGetWindowProperty(pDisplay, iWindow, windowState, 0L,
-1L, False, XA_ATOM, type, format,
+MAXINT, False, XA_ATOM, type, format,
nitems, left, (unsigned char **)pAtom) == Success)
{
-if (pAtom nitems == 1)
+if (pAtom)
{
- static Atom hiddenState, fullscreenState, belowState, aboveState;
+ static Atom skiptaskbarState, hiddenState, fullscreenState, belowState,
aboveState;
+
+ if (skiptaskbarState == None) skiptaskbarState = XInternAtom(pDisplay,
_NET_WM_STATE_SKIP_TASKBAR, False);
if (hiddenState == None) hiddenState = XInternAtom(pDisplay,
_NET_WM_STATE_HIDDEN, False);
if (fullscreenState == None) fullscreenState = XInternAtom(pDisplay,
_NET_WM_STATE_FULLSCREEN, False);
if (belowState == None) belowState = XInternAtom(pDisplay,
_NET_WM_STATE_BELOW, False);
if (aboveState == None) aboveState = XInternAtom(pDisplay,
_NET_WM_STATE_ABOVE, False);
- if (*pAtom == hiddenState) maxmin |= HINT_MIN;
- else if (*pAtom == fullscreenState) maxmin |= HINT_MAX;
- if (*pAtom == belowState) *zstyle = HWND_BOTTOM;
- else if (*pAtom == aboveState) *zstyle = HWND_TOPMOST;
+
+ unsigned long i;
+ for (i = 0; i nitems; i++)
+ {
+ if (*pAtom == skiptaskbarState) exHint |= HINT_SKIPTASKBAR;
+ if (*pAtom == hiddenState) maxmin |= HINT_MIN;
+ else if (*pAtom == fullscreenState) maxmin |= HINT_MAX;
+ if (*pAtom == belowState) *zstyle = HWND_BOTTOM;
+ else if (*pAtom == aboveState) *zstyle = HWND_TOPMOST;
+ }
+
+ XFree(pAtom);
}
-if (pAtom) XFree(pAtom);
}
nitems = left = 0;
@@ -1547,6 +1558,17 @@ winApplyHints (Display *pDisplay, Window
if (pAtom) XFree(pAtom);
}
+ /* Transient windows which are transient for non-root window shouldn't be in
taskbar */
+ /* XXX: perhaps? */
+ {
+WindowPtr pDaddy;
+if (winMultiWindowGetTransientFor(pWin, pDaddy))
+ {
+ if (pDaddy)
+ exHint |= HINT_SKIPTASKBAR;
+ }
+ }
+
/* Apply Styles, overriding hint settings from above */
rcStyle = winOverrideStyle((unsigned long)pWin);
if (rcStyle STYLE_TOPMOST) *zstyle = HWND_TOPMOST;
@@ -1573,7 +1595,10 @@ winApplyHints (Display *pDisplay, Window
((hint HINT_SIZEBOX) ? (GetParent(hWnd) ? 0 :
WS_SIZEBOX) : 0) |
((hint HINT_CAPTION) ? WS_CAPTION : 0));
- return;
+ if (exHint HINT_SKIPTASKBAR)
+SetWindowLongPtr(hWnd, GWL_EXSTYLE, WS_EX_TOOLWINDOW);
+ else
+SetWindowLongPtr(hWnd,
Re: multiwindow support for _NET_WM_STATE_SKIP_TASKBAR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: Here's a slightly improved version of that patch, and working version of the small testcase you pointed out to me. That makes more sense, thanks. 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. I wonder how many apps set _NET_WM_STATE_SKIP_TASKBAR and want a taskbar, but I think this is acceptable. Anyhow, try it out and see what you think. I have noticed that normal windows don't appear in the taskbar until they are refocused upon. Can you confirm? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkku94cACgkQpiWmPGlmQSNaUwCeOYC15UZhM8hJMLPc34rFl89t b70Anjbj1YcJvoxMbABcOQphY9+unACs =mSW2 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
