tag:old.nabble.com,2006:forum-1405Nabble - Gnome - Window Manager Spec2009-12-02T08:14:42ZDiscuss the creation of a new specification for Window Manager hints to augment those found in the ICCCM.tag:old.nabble.com,2006:post-26611577Re: Client-side decorations, RGBA opaque regions2009-12-02T08:14:42Z2009-12-02T08:14:42ZCody Russell-2On Wed, 2009-11-25 at 07:21 +0100, Fredrik Höglund wrote:
<div class='shrinkable-quote'><br>> > The other hint that would be useful is a hint similar to
<br>> > _NET_FRAME_EXTENTS that specifies client-side drop shadow extents.
<br>> The
<br>> > main idea here being that the WM could take advantage of this to
<br>> know
<br>> > where to perform window snapping for windows whose decorations and
<br>> > drop-shadows are drawn client-side. This might be called
<br>> > _NET_SHADOW_EXTENTS.
<br>>
<br>> I think this is a good idea, but maybe it should have a more generic
<br>> name, since the client may draw something other than a shadow
<br>> around the window.
<br>>
<br>> Also, while the spec doesn't say, I think the convention is that
<br>> properties
<br>> set by the client start with _NET_WM, while properties set by the
<br>> window
<br>> manager start with _NET.
</div><br>Perhaps instead of using a shadow/whatever extents region, we mark the
<br>'content' region instead. So, _NET_WM_CONTENT_AREA would describe
<br>everything inside the drop-shadow/glow/padding and would be used by the
<br>WM to determine window snapping regions and such.
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26611577&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26522573Re: struts, workareas and xinerama2009-11-25T16:11:18Z2009-11-25T16:11:18ZTomáš JanoušekHello,
<br><br>On Wed, Nov 25, 2009 at 06:39:57PM -0500, Dana Jansens wrote:
<div class='shrinkable-quote'><br>> 2009/11/25 Tomáš Janoušek <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26522573&i=0" target="_top" rel="nofollow">tomi@...</a>>:
<br>> > This looks reasonable, the only problem I can think of is this setup:
<br>> >
<br>> > 11112222
<br>> > 11112222
<br>> > 11112222 <-- taskbar spanning screens 1 and 2
<br>> > 33334444
<br>> > 33334444
<br>> > 33334444
<br>> >
<br>> > It's something that can be done for struts at the top and bottom of the root
<br>> > window using monitor = 0xFFFFFFFF, so we might want to support it for inner
<br>> > edges as well. I'm not sure if anyone actually wants to use something like
<br>> > that. I'm fine with that not being addressed, personally.
<br>>
<br>> It could be done by using two windows, one appearing (and setting a
<br>> strut) on each monitor. I'm not sure that is a reasonable thing to
<br>> expect though.
</div><br>I didn't realize that, now it makes sense :-). I have no further comments and
<br>will be happy to implement that into xmonad and xmobar, as soon as it's
<br>accepted in wm-spec.
<br><br>Thanks,
<br>--
<br>Tomáš Janoušek, a.k.a. Liskni_si, <a href="http://work.lisk.in/" target="_top" rel="nofollow">http://work.lisk.in/</a><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26522573&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26522276Re: struts, workareas and xinerama2009-11-25T15:39:57Z2009-11-25T15:39:57ZDana Jansens-22009/11/25 Tomáš Janoušek <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26522276&i=0" target="_top" rel="nofollow">tomi@...</a>>:
<div class='shrinkable-quote'><br>> Hello,
<br>>
<br>> thanks for your quick reply.
<br>>
<br>> On Sat, Nov 21, 2009 at 12:45:13PM -0500, Dana Jansens wrote:
<br>>> Secondly, as Lubus suggested, I have extended the STRUT property to
<br>>> allow for placing struts on boundaries between monitors. This
<br>>> addresses the use case presented by Tomáš. To keep the property
<br>>> similar to what has been done in the past, my proposed property looks
<br>>> like this:
<br>>>
<br>>> _NET_WM_STRUT_AREAS, monitor, left, right, top, bottom, left_start_y,
<br>>> left_end_y,
<br>>> right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>>> bottom_end_x, CARDINAL[13]/32
<br>>>
<br>>> As you can see it is exactly the _NET_WM_STRUT_PARTIAL hint, with a
<br>>> monitor field added, so that the window can request the monitor on
<br>>> which the strut should be reserved.
<br>>>
<br>>> In both cases of these hints, monitor may be set to 0xFFFFFFFF, in
<br>>> which case the geometry is relative to the root window and ignores
<br>>> everything about multiple monitors, essentially using the same
<br>>> behavior as the old hints.
<br>>
<br>> This looks reasonable, the only problem I can think of is this setup:
<br>>
<br>> 11112222
<br>> 11112222
<br>> 11112222 <-- taskbar spanning screens 1 and 2
<br>> 33334444
<br>> 33334444
<br>> 33334444
<br>>
<br>> It's something that can be done for struts at the top and bottom of the root
<br>> window using monitor = 0xFFFFFFFF, so we might want to support it for inner
<br>> edges as well. I'm not sure if anyone actually wants to use something like
<br>> that. I'm fine with that not being addressed, personally.
</div><br>It could be done by using two windows, one appearing (and setting a
<br>strut) on each monitor. I'm not sure that is a reasonable thing to
<br>expect though.
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26522276&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26521488Re: struts, workareas and xinerama2009-11-25T14:35:43Z2009-11-25T14:35:43ZTomáš JanoušekHello,
<br><br>thanks for your quick reply.
<br><br>On Sat, Nov 21, 2009 at 12:45:13PM -0500, Dana Jansens wrote:
<div class='shrinkable-quote'><br>> Secondly, as Lubus suggested, I have extended the STRUT property to
<br>> allow for placing struts on boundaries between monitors. This
<br>> addresses the use case presented by Tomáš. To keep the property
<br>> similar to what has been done in the past, my proposed property looks
<br>> like this:
<br>>
<br>> _NET_WM_STRUT_AREAS, monitor, left, right, top, bottom, left_start_y,
<br>> left_end_y,
<br>> right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>> bottom_end_x, CARDINAL[13]/32
<br>>
<br>> As you can see it is exactly the _NET_WM_STRUT_PARTIAL hint, with a
<br>> monitor field added, so that the window can request the monitor on
<br>> which the strut should be reserved.
<br>>
<br>> In both cases of these hints, monitor may be set to 0xFFFFFFFF, in
<br>> which case the geometry is relative to the root window and ignores
<br>> everything about multiple monitors, essentially using the same
<br>> behavior as the old hints.
</div><br>This looks reasonable, the only problem I can think of is this setup:
<br><br> 11112222
<br> 11112222
<br> 11112222 <-- taskbar spanning screens 1 and 2
<br> 33334444
<br> 33334444
<br> 33334444
<br><br>It's something that can be done for struts at the top and bottom of the root
<br>window using monitor = 0xFFFFFFFF, so we might want to support it for inner
<br>edges as well. I'm not sure if anyone actually wants to use something like
<br>that. I'm fine with that not being addressed, personally.
<br><br>Regards,
<br>--
<br>Tomáš Janoušek, a.k.a. Liskni_si, <a href="http://work.lisk.in/" target="_top" rel="nofollow">http://work.lisk.in/</a><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521488&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26521243Re: New hints for compositing window managers2009-11-25T14:16:40Z2009-11-25T14:16:40ZBugzilla from fredrik@kde.orgOn Wednesday 25 November 2009, Denis Dzyubenko wrote:
<div class='shrinkable-quote'><br>> Hi Fredrik,
<br>>
<br>> 2009/11/25 Fredrik Höglund <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521243&i=0" target="_top" rel="nofollow">fredrik@...</a>>:
<br>> > I want to propose a new set of window manager hints that lets a client
<br>> > specify that a compositing window manager should extend the window frame
<br>> > behind the client window.
<br>> >
<br>> > The _NET_WM_FRAME_OVERLAP hint is intentionally designed to be compatible
<br>> > with the DwmExtendFrameIntoClientArea API on Windows, to make life easier
<br>> > for cross platform toolkits and applications.
<br>> >
<br>> > When I discussed this idea with Carsten Haitzler on IRC a while back,
<br>> > he convinced me that a single rectangle might not be sufficient for all use
<br>> > cases.
<br>>
<br>> That sounds like an excellent idea, I really look forward to having
<br>> more control over window decorations. I know that Qt already uses
<br>> DwmExtendFrameIntoClientArea for QWizard dialogs on Windows and it
<br>> would be really nice to be able to implement it for X11 as well.
<br>>
<br>> Is there anyone from a compositing manager camp interested in this?
<br>> Will enlightenment or kde support this addition? (I can imagine that
<br>> it might require a bit of effort to support this feature in a themable
<br>> window manager).
</div><br>The themes would have to be designed for it, but implementing it is
<br>actually pretty easy. The window manager just draws the decoration
<br>on the backbuffer, and then composites the client window over the
<br>decoration.
<br><br>I can't speak for others, but KDE will support this hint.
<br><br>> Also it should be necessary to be able to figure out if the window
<br>> manager supports this feature - probably we can add a new hint for
<br>> _NET_SUPPORTED property.
<br><br>The window manager would just add _NET_WM_FRAME_OVERLAP
<br>to the list of properties in _NET_SUPPORTED. Applications that want
<br>to use this feature will of course have to provide a fallback path in
<br>case the window manager doesn't support it.
<br><br>> Also, your suggestion doesn't say anything about the content of the
<br>> window that is supposed to be transparent - should clients fill it
<br>> with some value of just leave it uninitialized and the compositor will
<br>> (somehow) take care of it?
<br><br>The client just leaves the parts of the window where it wants the
<br>decoration to "shine through" transparent.
<br><div class='shrinkable-quote'><br>> I also fail to see what will the compositor do with
<br>> _NET_WM_FRAME_OVERLAP hint - lets say the client sets it to be
<br>> -1,-1,-1,-1 - what does it mean? Will the window be opaque,
<br>> transparent or semi-transparent with a blur like on Windows when using
<br>> DwmExtendFrameIntoClientArea? I would expect the behavior whatever it
<br>> is to be fixed so that clients can rely on it. Also, if it's the
<br>> latter and the window will be "blurry" I actually fail to see how the
<br>> compositor can implement this partual blur without knowing which areas
<br>> inside the client window should be blurred (if I remember correctly,
<br>> on Windows when using the DwmExtendFrameIntoClientArea function the
<br>> client has to fill the transparent area with a specific color to tell
<br>> the compositor where the blur should go).
</div><br>The text in the patch attached to my original email explains in detail
<br>how the values should be interpreted by the window manager. If all
<br>values are set to -1, the window manager must extend the decoration
<br>behind the whole window.
<br><br>I agree that applications need more control over where the blur effect
<br>is applied, but I think this is needed regardless of whether the window
<br>frame is extended behind the client window or not. This is why I didn't
<br>include a hint for it in my patch.
<br><br>On Windows, applications can toggle the blur effect on and off for specific
<br>windows, and define the region where the blur should be applied.
<br>The region is defined in the struct passed to DwmEnableBlurBehindWindow.
<br><br>Adding a _NET_WM_BLUR_REGION would give us the same functionality.
<br><br>Regards,
<br>Fredrik
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521243&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26518001Re: New hints for compositing window managers2009-11-25T10:33:08Z2009-11-25T10:33:08ZBugzilla from shadone@gmail.comHi Fredrik,
<br><br>2009/11/25 Fredrik Höglund <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26518001&i=0" target="_top" rel="nofollow">fredrik@...</a>>:
<div class='shrinkable-quote'><br>> I want to propose a new set of window manager hints that lets a client
<br>> specify that a compositing window manager should extend the window frame
<br>> behind the client window.
<br>>
<br>> The _NET_WM_FRAME_OVERLAP hint is intentionally designed to be compatible
<br>> with the DwmExtendFrameIntoClientArea API on Windows, to make life easier
<br>> for cross platform toolkits and applications.
<br>>
<br>> When I discussed this idea with Carsten Haitzler on IRC a while back,
<br>> he convinced me that a single rectangle might not be sufficient for all use
<br>> cases.
</div><br>That sounds like an excellent idea, I really look forward to having
<br>more control over window decorations. I know that Qt already uses
<br>DwmExtendFrameIntoClientArea for QWizard dialogs on Windows and it
<br>would be really nice to be able to implement it for X11 as well.
<br><br>Is there anyone from a compositing manager camp interested in this?
<br>Will enlightenment or kde support this addition? (I can imagine that
<br>it might require a bit of effort to support this feature in a themable
<br>window manager).
<br><br>Also it should be necessary to be able to figure out if the window
<br>manager supports this feature - probably we can add a new hint for
<br>_NET_SUPPORTED property.
<br><br>Also, your suggestion doesn't say anything about the content of the
<br>window that is supposed to be transparent - should clients fill it
<br>with some value of just leave it uninitialized and the compositor will
<br>(somehow) take care of it?
<br><br>I also fail to see what will the compositor do with
<br>_NET_WM_FRAME_OVERLAP hint - lets say the client sets it to be
<br>-1,-1,-1,-1 - what does it mean? Will the window be opaque,
<br>transparent or semi-transparent with a blur like on Windows when using
<br>DwmExtendFrameIntoClientArea? I would expect the behavior whatever it
<br>is to be fixed so that clients can rely on it. Also, if it's the
<br>latter and the window will be "blurry" I actually fail to see how the
<br>compositor can implement this partual blur without knowing which areas
<br>inside the client window should be blurred (if I remember correctly,
<br>on Windows when using the DwmExtendFrameIntoClientArea function the
<br>client has to fill the transparent area with a specific color to tell
<br>the compositor where the blur should go).
<br><div class='shrinkable-quote'><br>> I've therefore included a _NET_WM_FRAME_CLIP hint for specifying multiple
<br>> rectangles. These two hints could be merged, but I think that the
<br>> expectations are slightly different. It's less reasonable for the window
<br>> manager to draw an inner frame around the rectangles specified in the
<br>> property, since they they may form a complex region. Even when they don't,
<br>> the client won't know how much space is needed between the rectangles in
<br>> order for the window manager to be able to draw the frame.
<br>>
<br>> It's also unlikely that the client wouldn't need to update this property
<br>> each time the window is resized. So for these reasons I prefer keeping these
<br>> properties separate.
<br>>
<br>> There's also a _NET_FRAME_TEXT_COLOR hint set on the window by the
<br>> window manager for use by the client.
<br>>
<br>> These hints provide an interesting contrast to the hints just proposed by
<br>> Cody Russell, but they don't conflict or overlap.
</div><br><br>--
<br>Best regards,
<br>Denis.
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26518001&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26516292Re: Client-side decorations, RGBA opaque regions2009-11-25T08:55:38Z2009-11-25T08:55:38ZYann DroneaudLe mercredi 25 novembre 2009 à 10:46 -0600, Cody Russell a écrit :
<div class='shrinkable-quote'><br>> On Wed, 2009-11-25 at 17:30 +0100, Yann Droneaud wrote:
<br>> > > They don't draw shadows on RGBA windows currently do they?
<br>> > Otherwise it
<br>> > > would be making some pretty big assumptions wouldn't it?
<br>> > >
<br>> >
<br>> > Some do.
<br>>
<br>> Sorry, I forgot to be more specific.. but on *undecorated* RGBA windows?
<br>>
</div><br>Did you mean on unredirected (override_redirect = True) RGBA window ?
<br><br>Examples of undecorated window showed in the thread uses an
<br>override_redirect window.
<br><br>Regards.
<br><br>--
<br>Yann Droneaud
<br><br><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516292&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26516247Re: Client-side decorations, RGBA opaque regions2009-11-25T08:52:14Z2009-11-25T08:52:14ZCody Russell-2On Wed, 2009-11-25 at 11:03 -0500, Dana Jansens wrote:
<br>> How would a compositing manager which decorates windows with, for
<br>> example, shadows, know not to draw shadows around/over/under the
<br>> client's shadows? I believe that window frames and other decorations
<br>> should each be done by a single client or there will be innumerable
<br>> conflicts involved.
<br><br>Sorry, I'm getting off topic a bit. To answer your question, the hint
<br>I'm proposing that I called _NET_SHADOW_EXTENTS could solve this. If
<br>those extents are set by the application, then the CM might know from
<br>this that the application intends to draw its own shadow (or glow, or
<br>whatever).
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516247&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26516155Re: Client-side decorations, RGBA opaque regions2009-11-25T08:46:21Z2009-11-25T08:46:21ZCody Russell-2On Wed, 2009-11-25 at 17:30 +0100, Yann Droneaud wrote:
<br>> > They don't draw shadows on RGBA windows currently do they?
<br>> Otherwise it
<br>> > would be making some pretty big assumptions wouldn't it?
<br>> >
<br>>
<br>> Some do.
<br><br>Sorry, I forgot to be more specific.. but on *undecorated* RGBA windows?
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516155&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26515870Re: Client-side decorations, RGBA opaque regions2009-11-25T08:30:15Z2009-11-25T08:30:15ZYann DroneaudLe mercredi 25 novembre 2009 à 10:12 -0600, Cody Russell a écrit :
<div class='shrinkable-quote'><br>> On Wed, 2009-11-25 at 11:03 -0500, Dana Jansens wrote:
<br>> >
<br>> > How would a compositing manager which decorates windows with, for
<br>> > example, shadows, know not to draw shadows around/over/under the
<br>> > client's shadows? I believe that window frames and other decorations
<br>> > should each be done by a single client or there will be innumerable
<br>> > conflicts involved.
<br>>
<br>> They don't draw shadows on RGBA windows currently do they? Otherwise it
<br>> would be making some pretty big assumptions wouldn't it?
<br>>
</div><br>Some do.
<br><br>> Perhaps the spec should specifically say that this applies to RGBA
<br>> windows only. What about shaped windows? Do compositors generally draw
<br>> shadows for these?
<br>>
<br><br>Some do it too.
<br><br><br>See thread
<br><a href="http://lists.freedesktop.org/archives/xorg/2009-September/047361.html" target="_top" rel="nofollow">http://lists.freedesktop.org/archives/xorg/2009-September/047361.html</a><br>Especially my post
<br><a href="http://lists.freedesktop.org/archives/xorg/2009-September/047415.html" target="_top" rel="nofollow">http://lists.freedesktop.org/archives/xorg/2009-September/047415.html</a><br><br><br>Regards.
<br><br>--
<br>Yann Droneaud
<br><br><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26515870&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26515523Re: Client-side decorations, RGBA opaque regions2009-11-25T08:12:44Z2009-11-25T08:12:44ZCody Russell-2On Wed, 2009-11-25 at 11:03 -0500, Dana Jansens wrote:
<br>>
<br>> How would a compositing manager which decorates windows with, for
<br>> example, shadows, know not to draw shadows around/over/under the
<br>> client's shadows? I believe that window frames and other decorations
<br>> should each be done by a single client or there will be innumerable
<br>> conflicts involved.
<br><br>They don't draw shadows on RGBA windows currently do they? Otherwise it
<br>would be making some pretty big assumptions wouldn't it?
<br><br>Perhaps the spec should specifically say that this applies to RGBA
<br>windows only. What about shaped windows? Do compositors generally draw
<br>shadows for these?
<br><br>Thanks,
<br> Cody
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26515523&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26515370Re: Client-side decorations, RGBA opaque regions2009-11-25T08:03:28Z2009-11-25T08:03:28ZDana Jansens-22009/11/25 Fredrik Höglund <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26515370&i=0" target="_top" rel="nofollow">fredrik@...</a>>:
<div class='shrinkable-quote'><br>> On Wednesday 25 November 2009, Cody Russell wrote:
<br>>> Hi,
<br>>>
<br>>> I'm working on adding support to GTK+ for doing client-side window
<br>>> decorations, and there are a couple additional hints that seem like they
<br>>> would be useful to propose.
<br>>>
<br>>> Part of this work is involving changing GTK+ to use RGBA windows by
<br>>> default. For this, I'd like to propose an XserverRegion hint that
<br>>> contains a region marking what parts of the window are known to be
<br>>> opaque. The idea being that this could be used by a WM/compositor to
<br>>> optimize which parts of the window it needs to composite, if it's useful
<br>>> to the WM/compositor (or it could be ignored; a GL compositor may not
<br>>> find this kind of information very useful, for example). This might be
<br>>> called _NET_OPAQUE_REGION.
<br>>
<br>> I think it would be preferable to store the rectangles directly in the
<br>> property.
<br>>
<br>> The reason is that if the window manager wants to fetch the rectangles,
<br>> it first has to make a synchronous call to fetch the ID, followed by another
<br>> synchronous call to fetch the rectangles, while it only has to make
<br>> one such call if the rectangles are stored directly in the property.
<br>>
<br>> If the window manager needs an XserverRegion it would have to create
<br>> it, but this is an asynchronous call.
<br>>
<br>>> The other hint that would be useful is a hint similar to
<br>>> _NET_FRAME_EXTENTS that specifies client-side drop shadow extents. The
<br>>> main idea here being that the WM could take advantage of this to know
<br>>> where to perform window snapping for windows whose decorations and
<br>>> drop-shadows are drawn client-side. This might be called
<br>>> _NET_SHADOW_EXTENTS.
<br>>
<br>> I think this is a good idea, but maybe it should have a more generic
<br>> name, since the client may draw something other than a shadow
<br>> around the window.
</div><br>How would a compositing manager which decorates windows with, for
<br>example, shadows, know not to draw shadows around/over/under the
<br>client's shadows? I believe that window frames and other decorations
<br>should each be done by a single client or there will be innumerable
<br>conflicts involved.
<br><br>Cheers,
<br>Dana
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26515370&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26508195New hints for compositing window managers2009-11-24T22:40:37Z2009-11-24T22:40:37ZBugzilla from fredrik@kde.orgHi,
<br><br>I want to propose a new set of window manager hints that lets a client
<br>specify that a compositing window manager should extend the window frame
<br>behind the client window.
<br><br>The _NET_WM_FRAME_OVERLAP hint is intentionally designed to be compatible
<br>with the DwmExtendFrameIntoClientArea API on Windows, to make life easier
<br>for cross platform toolkits and applications.
<br><br>When I discussed this idea with Carsten Haitzler on IRC a while back,
<br>he convinced me that a single rectangle might not be sufficient for all use
<br>cases.
<br><br>I've therefore included a _NET_WM_FRAME_CLIP hint for specifying multiple
<br>rectangles. These two hints could be merged, but I think that the
<br>expectations are slightly different. It's less reasonable for the window
<br>manager to draw an inner frame around the rectangles specified in the
<br>property, since they they may form a complex region. Even when they don't,
<br>the client won't know how much space is needed between the rectangles in
<br>order for the window manager to be able to draw the frame.
<br><br>It's also unlikely that the client wouldn't need to update this property
<br>each time the window is resized. So for these reasons I prefer keeping these
<br>properties separate.
<br><br>There's also a _NET_FRAME_TEXT_COLOR hint set on the window by the
<br>window manager for use by the client.
<br><br>These hints provide an interesting contrast to the hints just proposed by
<br>Cody Russell, but they don't conflict or overlap.
<br><br>Regards,
<br>Fredrik
<br><br><br /><tt>[wm-spec.diff]</tt><br /><hr align="left" width="300" /><tt>Index: wm-spec.xml
<br>===================================================================
<br>RCS file: /cvs/icccm-extensions/wm-spec/wm-spec.xml,v
<br>retrieving revision 1.30
<br>diff -u -3 -p -r1.30 wm-spec.xml
<br>--- wm-spec.xml 17 Mar 2008 14:48:05 -0000 1.30
<br>+++ wm-spec.xml 25 Nov 2009 06:25:13 -0000
<br>@@ -1538,6 +1538,58 @@ window's frame. left, right, top and bo
<br> respective borders added by the Window Manager.
<br> </para>
<br> </sect2>
<br>+
<br>+ <sect2><title>_NET_WM_FRAME_OVERLAP</title>
<br>+ <programlisting><![CDATA[
<br>+_NET_WM_FRAME_OVERLAP, left, right, top, bottom, CARDINAL[4]/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This optional property MAY be set by the client to indicate that the Window
<br>+Manager should extend the frame behind the client window, so that the frame
<br>+can serve as the backdrop for the window contents.
<br>+ </para>
<br>+ <para>
<br>+The four values indicate how far the frame should extend behind the window on
<br>+each side. If all four values are set to -1, the Window Manager MUST extend
<br>+the window frame behind the whole client window. Negative values MUST
<br>+otherwise be interpreted by the Window Manager as if they were zero.
<br>+ </para>
<br>+ <para>
<br>+The Window Manager MAY draw an inner frame around the inner rectangle.
<br>+ </para>
<br>+ </sect2>
<br>+
<br>+ <sect2><title>_NET_WM_FRAME_CLIP</title>
<br>+ <programlisting><![CDATA[
<br>+_NET_WM_FRAME_CLIP, x, y, width, height, CARDINAL[][4]/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This optional property MAY be set by the client to indicate that the Window
<br>+Manager should extend the window frame behind the whole client window,
<br>+while leaving the rectangles specified in this property transparent.
<br>+ </para>
<br>+ <para>
<br>+If both this property and the _NET_WM_FRAME_OVERLAP property are set,
<br>+the Window Manager MUST ignore the _NET_WM_FRAME_OVERLAP property, and
<br>+use the values in this property instead.
<br>+ </para>
<br>+ </sect2>
<br>+
<br>+ <sect2><title>_NET_FRAME_TEXT_COLOR</title>
<br>+ <programlisting><![CDATA[
<br>+_NET_FRAME_TEXT_COLOR, CARDINAL/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This property MUST be set by the Window Manager if it supports the
<br>+_NET_WM_FRAME_OVERLAP or _NET_WM_FRAME_CLIP properties.
<br>+ </para>
<br>+ <para>
<br>+This property should be interpreted as an ARGB32 pixel value, and
<br>+is intended to be used by the client as the text color in areas of
<br>+the window where the window frame is used as the background.
<br>+ </para>
<br>+ </sect2>
<br>+
<br> </sect1>
<br> <sect1>
<br> <title>Window Manager Protocols</title>
<br></tt><hr align="left" width="300" /><br />_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508195&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26508081Re: Client-side decorations, RGBA opaque regions2009-11-24T22:21:11Z2009-11-24T22:21:11ZBugzilla from fredrik@kde.orgOn Wednesday 25 November 2009, Cody Russell wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I'm working on adding support to GTK+ for doing client-side window
<br>> decorations, and there are a couple additional hints that seem like they
<br>> would be useful to propose.
<br>>
<br>> Part of this work is involving changing GTK+ to use RGBA windows by
<br>> default. For this, I'd like to propose an XserverRegion hint that
<br>> contains a region marking what parts of the window are known to be
<br>> opaque. The idea being that this could be used by a WM/compositor to
<br>> optimize which parts of the window it needs to composite, if it's useful
<br>> to the WM/compositor (or it could be ignored; a GL compositor may not
<br>> find this kind of information very useful, for example). This might be
<br>> called _NET_OPAQUE_REGION.
</div><br>I think it would be preferable to store the rectangles directly in the
<br>property.
<br><br>The reason is that if the window manager wants to fetch the rectangles,
<br>it first has to make a synchronous call to fetch the ID, followed by another
<br>synchronous call to fetch the rectangles, while it only has to make
<br>one such call if the rectangles are stored directly in the property.
<br><br>If the window manager needs an XserverRegion it would have to create
<br>it, but this is an asynchronous call.
<br><br>> The other hint that would be useful is a hint similar to
<br>> _NET_FRAME_EXTENTS that specifies client-side drop shadow extents. The
<br>> main idea here being that the WM could take advantage of this to know
<br>> where to perform window snapping for windows whose decorations and
<br>> drop-shadows are drawn client-side. This might be called
<br>> _NET_SHADOW_EXTENTS.
<br><br>I think this is a good idea, but maybe it should have a more generic
<br>name, since the client may draw something other than a shadow
<br>around the window.
<br><br>Also, while the spec doesn't say, I think the convention is that properties
<br>set by the client start with _NET_WM, while properties set by the window
<br>manager start with _NET.
<br><br>> Lastly, after reading the documentation about _NET_FRAME_EXTENTS [1] it
<br>> says that "the window manager MUST set _NET_FRAME_EXTENTS to the extents
<br>> of the window's frame." If an application is drawing the decorations,
<br>> should it set this property?
<br><br>I imagine that the window manager would set all values to 0 if it doesn't
<br>draw the decoration itself.
<br><br>Regards,
<br>Fredrik
<br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508081&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26507374Client-side decorations, RGBA opaque regions2009-11-24T20:22:13Z2009-11-24T20:22:13ZCody Russell-2Hi,
<br><br>I'm working on adding support to GTK+ for doing client-side window
<br>decorations, and there are a couple additional hints that seem like they
<br>would be useful to propose.
<br><br>Part of this work is involving changing GTK+ to use RGBA windows by
<br>default. For this, I'd like to propose an XserverRegion hint that
<br>contains a region marking what parts of the window are known to be
<br>opaque. The idea being that this could be used by a WM/compositor to
<br>optimize which parts of the window it needs to composite, if it's useful
<br>to the WM/compositor (or it could be ignored; a GL compositor may not
<br>find this kind of information very useful, for example). This might be
<br>called _NET_OPAQUE_REGION.
<br><br>The other hint that would be useful is a hint similar to
<br>_NET_FRAME_EXTENTS that specifies client-side drop shadow extents. The
<br>main idea here being that the WM could take advantage of this to know
<br>where to perform window snapping for windows whose decorations and
<br>drop-shadows are drawn client-side. This might be called
<br>_NET_SHADOW_EXTENTS.
<br><br>Lastly, after reading the documentation about _NET_FRAME_EXTENTS [1] it
<br>says that "the window manager MUST set _NET_FRAME_EXTENTS to the extents
<br>of the window's frame." If an application is drawing the decorations,
<br>should it set this property?
<br><br>Thanks,
<br> Cody
<br><br>[1]. <a href="http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html" target="_top" rel="nofollow">http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html</a><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26507374&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26458798Re: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint2009-11-21T09:59:10Z2009-11-21T09:59:10ZDana Jansens-22009/11/6 Giles Atkinson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458798&i=0" target="_top" rel="nofollow">Giles.Atkinson@...</a>>:
<br>> That makes sense to me, but also prompts me to make an additional point about this property: why is not specified as a conventional window hint, as well a client message to request a change?
<br>>
<br>> The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message. That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved. Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.
<br><br>I agree, the functionality as only a message completely misses windows
<br>that want to map in fullscreen mode. I would support this change.
<br><div class='shrinkable-quote'><br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458798&i=1" target="_top" rel="nofollow">wm-spec-list-bounces@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458798&i=2" target="_top" rel="nofollow">wm-spec-list-bounces@...</a>] On Behalf Of Jason 'vanRijn' Kasper
<br>> Sent: 05 November 2009 22:32
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458798&i=3" target="_top" rel="nofollow">wm-spec-list@...</a>
<br>> Subject: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint
<br>>
<br>> re, all.
<br>>
<br>> The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.
<br>>
<br>> I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.
<br>>
<br>> I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).
<br>>
<br>> I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?
</div><br>I believe that it's the same but technically the file you'd want to
<br>edit is here: <a href="http://webcvs.freedesktop.org/icccm-extensions/wm-spec/" target="_top" rel="nofollow">http://webcvs.freedesktop.org/icccm-extensions/wm-spec/</a><br><br>> The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.
<br>>
<br>> Thanks in advance, all! =:)
<br><br>This also sounds reasonable to me, as there is no "add/remove/toggle"
<br>state indicator or anything of the type in the message now, and "all
<br>monitors" (the usual use for 0xFFFFFFFF) can already be achieved
<br>through using indices.
<br><br><br>Cheers,
<br>Dana
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458798&i=4" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26458677Re: struts, workareas and xinerama2009-11-21T09:45:13Z2009-11-21T09:45:13ZDana Jansens-22009/11/20 Tomáš Janoušek <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458677&i=0" target="_top" rel="nofollow">tomi@...</a>>:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hello,
<br>>
<br>> On Thu, Jan 24, 2008 at 07:19:10PM +0100, Lubos Lunak wrote:
<br>>> On Wednesday 13 of June 2007, Dana Jansens wrote:
<br>>> > Secondly, I am in need of some clarification in terms of struts with
<br>>> > Xinerama. In the above example, say an application set a strut on the
<br>>> > "right side" with a length of the 1st monitor. Where exactly does
<br>>> > this strut reside? It could reside entirely on the first monitor, it
<br>>> > could reside on the second monitor (and the nowhereland above it) or
<br>>> > it could be split between the two monitors.
<br>>> >
<br>>> > I expect there is no answer to this question, which is frustrating
<br>>> > because this is a real-life setup that one of my users has talked
<br>>> > about recently. Perhaps _NET_WM_STRUT_PARTIAL is just not enough, and
<br>>> > needs to be able to specify the monitor as well as start/length.
<br>>>
<br>>> Correct. The strut hints talk about desktop (root window) edges, so they
<br>>> don't support reserved areas "inside". That basically matches _NET_WORKAREA,
<br>>> so if you want to extend one, you probably want to do the same with the other
<br>>> one.
<br>>
<br>> I encountered this issue as well and I got an idea for a simple workaround.
<br>> Imagine a screen layout like this:
<br>>
<br>> 11111111
<br>> 11111111
<br>> 11111111
<br>> 222222 <--- strut here
<br>> 222222
<br>> 222222
<br>>
<br>> We want to place a panel at the top of screen 2. A naive panel application may
<br>> set a partial strut where top = top coordinate of screen 2 + height of panel.
<br>> This is wrong, as it indicates that the entire screen 1* is covered, *but* the
<br>> interpretation may as well be different. If we agree that struts covering an
<br>> entire xinerama screen are nonsense, we may interpret such struts as not
<br>> covering those screens at all, just those that they don't cover entirely. This
<br>> way _NET_WM_STRUT_PARTIAL can be used for struts covering any edge of any
<br>> Xinerama screen.
<br>>
<br>> * I know, not really entire screen. Just a horizontal strut whose height is
<br>> greater than the height of screen 1. Please read "entire" as "entire in
<br>> their primary dimension".
<br>>
<br>> This naive way of setting _NET_WM_STRUT_PARTIAL is used in xmobar and I have
<br>> implemented this semantics for xmonad:
<br>> <a href="http://www.haskell.org/pipermail/xmonad/2009-November/009148.html" target="_top" rel="nofollow">http://www.haskell.org/pipermail/xmonad/2009-November/009148.html</a><br>>
<br>> I can't think of any use for struts that span multiple screens in their primary
<br>> dimension (height for horiz. struts, width for vert. struts), personally.
<br>> If wm-spec is extended in the way Dana and Lubos said (which didn't happen yet
<br>> even though it's been almost 2 years already), I'll be happy to implement it,
<br>> but this "hack" seemed easier and compatible with what was in the wild.
<br>>
<br>> What's your opinion?
</div></div>I apologize I dropped the ball on this one and forgot about it until
<br>quite recently when another issue came up.
<br><br>I have attached a suggested patch to the wm-spec to improve its
<br>relation to multi-monitor environments.
<br><br>First, it adds a multi-monitor-friendly _NET_WORKAREAS hint, replacing
<br>the _NET_WORKAREA hint. I thought that _NET_WORKAREAS sounded a bit
<br>better than _NET_WORKAREA_AREAS, though it may be too close to the
<br>original hint. The hint is slightly different from the one I
<br>suggested previously. It looks like this:
<br><br>_NET_WORKAREAS, monitor, x, y, width, height, CARDINAL[][5]/32
<br><br>I included a monitor index to each geometry so that a client can tell
<br>how many monitors and desktops are being represented in this hint
<br>independent of the value in _NET_NUM_DESKTOPS. If decoding the values
<br>in this required knowing the value of _NET_NUM_DESKTOPS, it would lead
<br>to some ugly race conditions.
<br><br>The proposed property lists the geometry of work areas on each monitor
<br>for the first desktop, followed by the work areas on each monitor for
<br>the second desktop, and so on. The geometries are given for monitors
<br>in the same order as the monitors appear in the list returned by the
<br>Xinerama extension, and the "monitor" field is an index into this
<br>list.
<br><br>Secondly, as Lubus suggested, I have extended the STRUT property to
<br>allow for placing struts on boundaries between monitors. This
<br>addresses the use case presented by Tomáš. To keep the property
<br>similar to what has been done in the past, my proposed property looks
<br>like this:
<br><br>_NET_WM_STRUT_AREAS, monitor, left, right, top, bottom, left_start_y,
<br>left_end_y,
<br>right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>bottom_end_x, CARDINAL[13]/32
<br><br>As you can see it is exactly the _NET_WM_STRUT_PARTIAL hint, with a
<br>monitor field added, so that the window can request the monitor on
<br>which the strut should be reserved.
<br><br>In both cases of these hints, monitor may be set to 0xFFFFFFFF, in
<br>which case the geometry is relative to the root window and ignores
<br>everything about multiple monitors, essentially using the same
<br>behavior as the old hints.
<br><br><br>I would however like to understand why the _NET_WM_STRUT (and then
<br>_NET_WM_STRUT_PARTIAL) hint allows a window to reserve space along
<br>more than one edge of the screen. This makes it very difficult for a
<br>window manager to do anything intelligent with strut windows, as it
<br>can not always tell what edge they are on if they request space on
<br>multiple edges. What use case was considered when allowing this
<br>behaviour? It is included in the notes that "A corner panel that does
<br>not extend for the full length of a screen border SHOULD only set one
<br>strut." I would perfer to make the _NET_WM_STRUT_AREAS hint only
<br>allow an application to reserve one rectangular area along one edge of
<br>one monitor. Applications which wanted to use multiple edges could
<br>still do so through multiple windows.
<br><br>Restricting a window to reserving a strut along only one edge would
<br>not affect most (any?) uses of the STRUT property for applications,
<br>but would allow a Window Manager to treat strut windows more
<br>intelligently. The use case I am considering this for is when more
<br>than one window reserve the same edge of a screen [1]. Currently
<br>applications are trying to place themselves relative to the WORKAREA,
<br>which causes race conditions between clients and does not allow them
<br>to properly move dynamically as strut windows are added/removed along
<br>the edge. The window manager should be able to place windows along a
<br>strut edge when there are more than one so that they do not overlap.
<br>This would be much simpler and more predictable if a window is only
<br>attached to a single edge (has a single reserved edge reserved in its
<br>strut).
<br><br>I have added a comments in the diff that reflect the problems
<br>introduced in this scenario. First that the STRUT should be relative
<br>to the screen edge, not to the WORKAREA, and second that the window
<br>manager may place windows with struts away from the edge of the
<br>monitor. However, implementations will be somewhat limited by the
<br>STRUT hint in its current form. These are important things that will
<br>affect how well applications will be able to make use of struts, and
<br>cooperate with each other, so I hope that these issues will be looked
<br>at seriously.
<br><br>Cheers,
<br>Dana
<br><br><br>[1] <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551807" target="_top" rel="nofollow">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551807</a><br><br /><tt>[multi-monitor-workarea-and-strut.diff]</tt><br /><hr align="left" width="300" /><tt>commit 39d82f6ff7ed2a552fbecd8c032e0190f918135f
<br>Author: Dana Jansens <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458677&i=1" target="_top" rel="nofollow">danakj@...</a>>
<br>Date: Fri Nov 20 23:25:20 2009 -0500
<br><br> Add _NET_WORKAREAS and _NET_WM_STRUT_AREAS.
<br><br>diff --git a/wm-spec.xml b/wm-spec.xml
<br>index f45e284..f3ed0fc 100644
<br>--- a/wm-spec.xml
<br>+++ b/wm-spec.xml
<br>@@ -340,7 +340,7 @@ _NET_NUMBER_OF_DESKTOPS
<br> other data.l[] elements = 0
<br> ]]></programlisting>
<br> <para>
<br>-The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
<br>+The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREAS must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
<br> </para>
<br> <para>
<br> If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. Clients that are still present on desktops that are out of the new range MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated.
<br>@@ -479,24 +479,71 @@ Depending on the information provided with the message, the Window Manager may
<br> decide to refuse the request (either completely ignore it, or e.g. use
<br> _NET_WM_STATE_DEMANDS_ATTENTION).
<br> </para>
<br>+ </sect2><sect2><title>_NET_WORKAREAS</title>
<br>+ <programlisting><![CDATA[
<br>+_NET_WORKAREAS, monitor, x, y, width, height, CARDINAL[][5]/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This property MUST be set by the Window Manager upon calculating the work area
<br>+for each desktop. Contains a geometry of the working area on each physical
<br>+monitor (provided by the Xinerama extension), for each virtual desktop.
<br>+All connected monitors SHOULD have a geometry included,
<br>+and the same monitors MUST be represented for all desktops.
<br>+The monitor is an index into the list of monitors returned by the Xinerama
<br>+extension, starting from 0, or can be a value of 0xFFFFFFFF to indicate the
<br>+Window Manager does not support multiple monitors, and the work area is
<br>+spread across the entire root window. The geometry for each monitor MUST
<br>+appear in this property, for each desktop, in the same order reported by the
<br>+Xinerama extension.
<br>+These geometries are specified relative to the viewport on each
<br>+desktop, not relative to the monitor, and specify an area that is completely
<br>+contained within the viewport.
<br>+Work areas SHOULD be used by desktop applications to place desktop icons
<br>+appropriately.
<br>+ </para>
<br>+ <para>
<br>+This property holds a list of work areas for the first desktop, across all
<br>+monitors, followed by a list of work areas for the second desktop, and so on.
<br>+For example, consider the scenario where there is one monitor of size
<br>+1280x1024 and a second monitor of size 1024x768. The Window Manager has
<br>+2 desktops, and there are is a reserved area of 20 pixels at the top of the
<br>+second monitor on only the second desktop. Then this property would look like:
<br>+"0, 0, 0, 1280, 1024, 1, 0, 0, 1024, 768,
<br>+ 0, 0, 0, 1280, 1024, 1, 0, 20, 1024, 748".
<br>+Alternatively, consider if a Window Manager does not support multiple monitors
<br>+through Xinerama, but sees a root window of size 2304x1024 with 2 desktops
<br>+and 20 pixels reserved at the top of the screen on the second desktop.
<br>+Then this property would look like:
<br>+"0xFFFFFFFF, 0, 0, 2304, 1024, 0xFFFFFFFF, 0, 20, 2304, 1004".
<br>+ </para>
<br>+ <para>
<br>+The Window Manager SHOULD calculate this space by taking the current
<br>+page minus space occupied by dock and panel windows, as indicated by
<br>+the <link linkend="NETWMSTRUTAREAS">_NET_WM_STRUT_AREAS</link>
<br>+property set on client windows (or
<br>+<link linkend="NETWMSTRUT">_NET_WM_STRUT</link> and
<br>+<link linkend="NETWMSTRUTPARTIAL">_NET_WM_STRUT_PARTIAL</link> properties
<br>+for legacy clients).
<br>+ </para>
<br> </sect2><sect2><title>_NET_WORKAREA</title>
<br> <programlisting><![CDATA[
<br> _NET_WORKAREA, x, y, width, height CARDINAL[][4]/32
<br>-]]>
<br>- </programlisting>
<br>+]]></programlisting>
<br> <para>
<br>-This property MUST be set by the Window Manager upon calculating the work area for
<br>+This property has been DEPRECATED in favor of _NET_WORKAREAS. When
<br>+_NET_WORKAREAS has been set, clients MUST ignore the value of this
<br>+property, and use _NET_WORKAREAS instead. Window Managers MAY
<br>+continue to update this property for legacy applications.
<br>+ </para>
<br>+ <para>
<br>+This property MAY be set by the Window Manager upon calculating the work area for
<br> each desktop. Contains a geometry for each desktop. These geometries are
<br> specified relative to the viewport on each desktop and specify an area that is
<br> completely contained within the viewport.
<br>- Work area SHOULD be used by desktop applications to place desktop icons appropriately.
<br> </para>
<br> <para>
<br>-The Window Manager SHOULD calculate this space by taking the current
<br>-page minus space occupied by dock and panel windows, as indicated by
<br>-the <link linkend="NETWMSTRUT">_NET_WM_STRUT</link> or <link
<br>-linkend="NETWMSTRUTPARTIAL">_NET_WM_STRUT_PARTIAL</link> properties set on
<br>-client windows.
<br>+The Window Manager SHOULD calculate this space as a subset of the areas
<br>+described in _NET_WORKAREAS.
<br> </para>
<br> </sect2>
<br> <sect2>
<br>@@ -1332,48 +1379,59 @@ _NET_WM_ACTION_BELOW indicates that the window may placed in the "below" layer o
<br> </para>
<br> </sect2>
<br>
<br>-<sect2><title>_NET_WM_STRUT</title>
<br>- <programlisting id="NETWMSTRUT"><![CDATA[
<br>-_NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32
<br>-]]></programlisting>
<br>- <para>
<br>-This property is equivalent to a _NET_WM_STRUT_PARTIAL property where all start
<br>-values are 0 and all end values are the height or width of the logical screen.
<br>-_NET_WM_STRUT_PARTIAL was introduced later than _NET_WM_STRUT, however, so
<br>-clients MAY set this property in addition to _NET_WM_STRUT_PARTIAL to ensure
<br>-backward compatibility with Window Managers supporting older versions of the
<br>-Specification.
<br>- </para>
<br>-</sect2>
<br>-<sect2><title>_NET_WM_STRUT_PARTIAL</title>
<br>- <programlisting id="NETWMSTRUTPARTIAL"><![CDATA[
<br>-_NET_WM_STRUT_PARTIAL, left, right, top, bottom, left_start_y, left_end_y,
<br>+<sect2><title>_NET_WM_STRUT_AREAS</title>
<br>+ <programlisting id="NETWMSTRUTAREAS"><![CDATA[
<br>+_NET_WM_STRUT_AREAS, monitor, left, right, top, bottom, left_start_y, left_end_y,
<br> right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>-bottom_end_x,CARDINAL[12]/32
<br>+bottom_end_x, CARDINAL[13]/32
<br> ]]></programlisting>
<br> <para>
<br>-This property MUST be set by the Client if the window is to reserve space at the
<br>-edge of the screen. The property contains 4 cardinals specifying the width of
<br>+This property MUST be set by the Client if the window is to reserve space
<br>+at the edge of a screen. The property contains 1 cardinal specifying the
<br>+monitor on which to reserve space, with 4 cardinals specifying the width of
<br> the reserved area at each border of the screen, and an additional 8 cardinals
<br>-specifying the beginning and end corresponding to each of the four struts. The
<br>-order of the values is left, right, top, bottom, left_start_y, left_end_y,
<br>+specifying the beginning and end corresponding to each of the four struts.
<br>+The order of the values is left, right, top, bottom, left_start_y, left_end_y,
<br> right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>-bottom_end_x. All coordinates are root window coordinates. The client MAY change
<br>+bottom_end_x. The monitor is specified as an index from 0 into the list
<br>+of monitors given by the Xinerama extension, or may be 0xFFFFFFFF to
<br>+specify that the strut is to be placed along the edge of the root window
<br>+(the combination of all monitors).
<br>+All coordinates are relative to edge of the physical monitor on which space
<br>+is being requested (not relative to the values in _NET_WORKAREAS).
<br>+The client MAY change
<br> this property at any time, therefore the Window Manager MUST watch for
<br> property notify events if the Window Manager uses this property to assign
<br> special semantics to the window.
<br> </para>
<br> <para>
<br>-If both this property and the _NET_WM_STRUT property are set, the Window Manager
<br>-MUST ignore the _NET_WM_STRUT property values and use instead the values for
<br>-_NET_WM_STRUT_PARTIAL. This will ensure that Clients can safely set both
<br>+A client MUST NOT attempt to set its strut according to other windows
<br>+with struts on the monitor, or according to the _NET_WORKAREAS property,
<br>+as these create race conditions between clients. Instead the size of the
<br>+reserved area MUST always be relative to the screen edge, as if the
<br>+client is the only window with a strut along that edge. If multiple
<br>+windows have overlapping struts along a screen edge, the Window Manager
<br>+MAY adjust the positions of the windows on screen to prevent the
<br>+windows from visibly overlapping by moving the windows away from the
<br>+reserved edge of the screen. Thus a client with a strut window MUST allow
<br>+for the Window Manager to place the window in a different position than
<br>+requested, though it can expect to be placed logically along the edge
<br>+requested.
<br>+ </para>
<br>+ <para>
<br>+If both this property and the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL property
<br>+are set, the Window Manager
<br>+MUST ignore the _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL property values and use
<br>+instead the values for
<br>+_NET_WM_STRUT_AREAS. This will ensure that Clients can safely set both
<br> properties without giving up the improved semantics of the new property.
<br> </para>
<br> <para>
<br> The purpose of struts is to reserve space at the borders of the
<br> desktop. This is very useful for a docking area, a taskbar or a panel,
<br>-for instance. The Window Manager should take this reserved area into
<br>-account when constraining window positions - maximized windows, for
<br>+for instance. The Window Manager SHOULD take this reserved area into
<br>+account when determining the desktop geometry in _NET_WORKAREAS,
<br>+and when constraining window positions - maximized windows, for
<br> example, should not cover that area.
<br> </para>
<br> <para>
<br>@@ -1389,13 +1447,13 @@ screen, 50 pixels tall, and occupying the space from 200-600 pixels
<br> from the left of the screen edge would set a bottom strut of 50, and
<br> set bottom_start_x to 200 and bottom_end_x to 600. Another example is
<br> a panel on a screen using the Xinerama extension. Assume that the set
<br>-up uses two monitors, one running at 1280x1024 and the other to the
<br>-right running at 1024x768, with the top edge of the two physical
<br>-displays aligned. If the panel wants to fill the entire bottom edge
<br>+up uses two monitors, the first one running at 1280x1024 and a second
<br>+one to the right running at 1024x768.
<br>+If the panel wants to fill the entire bottom edge
<br> of the smaller display with a panel 50 pixels tall, it should set a
<br>-bottom strut of 306, with bottom_start_x of 1280, and bottom_end_x of
<br>-2303. Note that the strut is relative to the screen edge, and not the
<br>-edge of the xinerama monitor.
<br>+bottom strut of 50 on monitor 1, with bottom_start_x of 0, and bottom_end_x of
<br>+768. Note that the strut is relative to the edge of the xinerama monitor on
<br>+which it is being placed.
<br> </para>
<br> <para>
<br> Rationale: A simple "do not cover" hint is not enough for dealing with e.g.
<br>@@ -1407,6 +1465,38 @@ A "corner" panel that does not extend for the full length of a screen border
<br> SHOULD only set one strut.
<br> </para>
<br> </sect2>
<br>+<sect2><title>_NET_WM_STRUT</title>
<br>+ <programlisting id="NETWMSTRUT"><![CDATA[
<br>+_NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This property is equivalent to a _NET_WM_STRUT_AREAS property where all start
<br>+values are 0, all end values are the height or width of the logical screen,
<br>+and the monitor is the first monitor.
<br>+_NET_WM_STRUT_AREAS was introduced later than _NET_WM_STRUT, however, so
<br>+clients MAY set this property in addition to _NET_WM_STRUT_AREAS when a Window
<br>+Manager advertises support for it, but not for _NET_WM_STRUT_AREAS, to ensure
<br>+backward compatibility with Window Managers supporting older versions of the
<br>+Specification.
<br>+ </para>
<br>+</sect2>
<br>+<sect2><title>_NET_WM_STRUT_PARTIAL</title>
<br>+ <programlisting id="NETWMSTRUTPARTIAL"><![CDATA[
<br>+_NET_WM_STRUT_PARTIAL, left, right, top, bottom, left_start_y, left_end_y,
<br>+right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
<br>+bottom_end_x,CARDINAL[12]/32
<br>+]]></programlisting>
<br>+ <para>
<br>+This property is equivalent to a _NET_WM_STRUT_AREAS property with the same
<br>+start and end values, for the first monitor reported by the Xinerama
<br>+extension.
<br>+_NET_WM_STRUT_AREAS was introduced later than _NET_WM_STRUT_PARTIAL, however, so
<br>+clients MAY set this property in addition to _NET_WM_STRUT_AREAS when a Window
<br>+Manager advertises support for it, but not for _NET_WM_STRUT_AREAS, to ensure
<br>+backward compatibility with Window Managers supporting older versions of the
<br>+Specification.
<br>+ </para>
<br>+</sect2>
<br> <sect2><title>_NET_WM_ICON_GEOMETRY</title>
<br> <programlisting><![CDATA[
<br> _NET_WM_ICON_GEOMETRY, x, y, width, height, CARDINAL[4]/32
<br>@@ -2245,6 +2335,14 @@ OR OTHER DEALINGS IN THE SOFTWARE.
<br> <title>Changes since 1.3</title>
<br> <itemizedlist>
<br> <listitem><para>
<br>+Added _NET_WM_STRUT_AREAS, deprecating _NET_WM_STRUT_PARTIAL and _NET_WM_STRUT,
<br>+to improve support for applications in multi-monitor environments.
<br>+ </para></listitem>
<br>+ <listitem><para>
<br>+Added _NET_WM_WORKAREAS, deprecating _NET_WM_WORKAREA, to improve support for
<br>+applications in multi-monitor environments.
<br>+ </para></listitem>
<br>+ <listitem><para>
<br> Added _NET_WM_MOVERESIZE_CANCEL.
<br> </para></listitem>
<br> <listitem><para>
<br></tt><hr align="left" width="300" /><br />_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458677&i=2" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26449487Re: struts, workareas and xinerama2009-11-20T12:02:11Z2009-11-20T12:02:11ZTomáš JanoušekHello,
<br><br>On Thu, Jan 24, 2008 at 07:19:10PM +0100, Lubos Lunak wrote:
<div class='shrinkable-quote'><br>> On Wednesday 13 of June 2007, Dana Jansens wrote:
<br>> > Secondly, I am in need of some clarification in terms of struts with
<br>> > Xinerama. In the above example, say an application set a strut on the
<br>> > "right side" with a length of the 1st monitor. Where exactly does
<br>> > this strut reside? It could reside entirely on the first monitor, it
<br>> > could reside on the second monitor (and the nowhereland above it) or
<br>> > it could be split between the two monitors.
<br>> >
<br>> > I expect there is no answer to this question, which is frustrating
<br>> > because this is a real-life setup that one of my users has talked
<br>> > about recently. Perhaps _NET_WM_STRUT_PARTIAL is just not enough, and
<br>> > needs to be able to specify the monitor as well as start/length.
<br>>
<br>> Correct. The strut hints talk about desktop (root window) edges, so they
<br>> don't support reserved areas "inside". That basically matches _NET_WORKAREA,
<br>> so if you want to extend one, you probably want to do the same with the other
<br>> one.
</div><br>I encountered this issue as well and I got an idea for a simple workaround.
<br>Imagine a screen layout like this:
<br><br> 11111111
<br> 11111111
<br> 11111111
<br> 222222 <--- strut here
<br> 222222
<br> 222222
<br><br>We want to place a panel at the top of screen 2. A naive panel application may
<br>set a partial strut where top = top coordinate of screen 2 + height of panel.
<br>This is wrong, as it indicates that the entire screen 1* is covered, *but* the
<br>interpretation may as well be different. If we agree that struts covering an
<br>entire xinerama screen are nonsense, we may interpret such struts as not
<br>covering those screens at all, just those that they don't cover entirely. This
<br>way _NET_WM_STRUT_PARTIAL can be used for struts covering any edge of any
<br>Xinerama screen.
<br><br>* I know, not really entire screen. Just a horizontal strut whose height is
<br> greater than the height of screen 1. Please read "entire" as "entire in
<br> their primary dimension".
<br><br>This naive way of setting _NET_WM_STRUT_PARTIAL is used in xmobar and I have
<br>implemented this semantics for xmonad:
<br><a href="http://www.haskell.org/pipermail/xmonad/2009-November/009148.html" target="_top" rel="nofollow">http://www.haskell.org/pipermail/xmonad/2009-November/009148.html</a><br><br>I can't think of any use for struts that span multiple screens in their primary
<br>dimension (height for horiz. struts, width for vert. struts), personally.
<br>If wm-spec is extended in the way Dana and Lubos said (which didn't happen yet
<br>even though it's been almost 2 years already), I'll be happy to implement it,
<br>but this "hack" seemed easier and compatible with what was in the wild.
<br><br>What's your opinion?
<br><br>Regards,
<br>--
<br>Tomáš Janoušek, a.k.a. Liskni_si, <a href="http://work.lisk.in/" target="_top" rel="nofollow">http://work.lisk.in/</a><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449487&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26424685session management and save_type in save yourself message2009-11-19T03:31:57Z2009-11-19T03:31:57ZIban HATCHONDOHi,
<br><br>I've been reading some old threads such as <a href="https://listman.redhat.com/pipermail/xdg-list/2002-July/000615.html" target="_top" rel="nofollow">https://listman.redhat.com/pipermail/xdg-list/2002-July/000615.html</a> but I still don't understand why I receive some save yourself message with a save_style being 0xFF.
<br>When I connect to the session manager using the SESSION_MANAGER env variable, I got a first save yourself message, to which I answer with a save yourself done, to which the SM answers with a save complete. message followed by a new save yourself message, but with 0xFF as save type.
<br>Does anyone know what that save_type is supposed to mean ? And what is expected as an answer ?
<br><br>Note that all those extra messages disappear when I use the value of DESKTOP_AUTOSTART_ID env variable during my connection.
<br><br>I have the feeling this is not the proper mailing list, so do not hesitate to re-route me to a more appropriated list.
<br><br>Regards,
<br>Iban.
<br><br><br><br>
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26424685&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26240646Re: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint2009-11-06T16:12:18Z2009-11-06T16:12:18ZBugzilla from vR@movingparts.netHey Giles,<br><br><div class="gmail_quote">On Fri, Nov 6, 2009 at 1:49 AM, Giles Atkinson <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26240646&i=0" target="_top" rel="nofollow">Giles.Atkinson@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That makes sense to me, but also prompts me to make an additional point about this property: why is not specified as a conventional window hint, as well a client message to request a change?<br>
<br>
The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message. That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved. Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.<br>
</blockquote><div><br></div><div>I don't think I can answer your question. I'm guessing the design discussion that took place 2 years ago on this list (<a href="http://www.mail-archive.com/wm-spec-list@gnome.org/msg00594.html" target="_top" rel="nofollow">http://www.mail-archive.com/wm-spec-list@.../msg00594.html</a> and friends) hashed this out. I know it went through a couple of revisions before this hint arrived in its current form, and I wasn't part of those initial discussions.</div>
<div><br></div><div>Hm... but as to your situation... it sounds like you're trying to create a window that initially spans multiple monitors? Did you try setting _NET_WM_FULLSCREEN_MONITORS, then _NET_WM_STATE_FULLSCREEN before showing the X window?</div>
</div><br>-- <br> -[ Jason 'vanRijn' Kasper // <a href="http://movingparts.net" target="_top" rel="nofollow">http://movingparts.net</a> ]-<br> -[ KDE PIM Developer // <a href="http://www.kde.org" target="_top" rel="nofollow">http://www.kde.org</a> ]-<br> -[ bash fun -> :(){ :|:&};: // Numbers 6:22-26 ]-<br>
<br />_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26240646&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26227644RE: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint2009-11-05T22:49:20Z2009-11-05T22:49:20ZGiles AtkinsonThat makes sense to me, but also prompts me to make an additional point about this property: why is not specified as a conventional window hint, as well a client message to request a change?
<br><br>The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message. That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved. Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.
<br><br>Giles
<br><br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26227644&i=0" target="_top" rel="nofollow">wm-spec-list-bounces@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26227644&i=1" target="_top" rel="nofollow">wm-spec-list-bounces@...</a>] On Behalf Of Jason 'vanRijn' Kasper
<br>Sent: 05 November 2009 22:32
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26227644&i=2" target="_top" rel="nofollow">wm-spec-list@...</a>
<br>Subject: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint
<br><br>re, all.
<br><br>The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.
<br><br>I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.
<br><br>I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).
<br><br>I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?
<br><br>The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.
<br><br>Thanks in advance, all! =:)
<br><br>--
<br>-[ Jason 'vanRijn' Kasper // <a href="http://movingparts.net" target="_top" rel="nofollow">http://movingparts.net</a> ]-
<br>-[ KDE PIM Developer // <a href="http://www.kde.org" target="_top" rel="nofollow">http://www.kde.org</a> ]-
<br>-[ bash fun -> :(){ :|:&};: // Numbers 6:22-26 ]-
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26227644&i=3" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-26223486Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint2009-11-05T14:31:49Z2009-11-05T14:31:49ZBugzilla from vR@movingparts.netre, all.<div><br></div><div>The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.</div>
<div><br></div><div>I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.</div>
<div><br></div><div>I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).</div>
<div><br></div><div>I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?</div>
<div><br></div><div>The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.</div>
<div><br></div><div>Thanks in advance, all! =:)<br clear="all"><br>-- <br> -[ Jason 'vanRijn' Kasper // <a href="http://movingparts.net" target="_top" rel="nofollow">http://movingparts.net</a> ]-<br> -[ KDE PIM Developer // <a href="http://www.kde.org" target="_top" rel="nofollow">http://www.kde.org</a> ]-<br>
-[ bash fun -> :(){ :|:&};: // Numbers 6:22-26 ]-<br>
</div>
<br />_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26223486&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24972209Re: Freezing updates for compositing managers2009-08-14T07:00:36Z2009-08-14T07:00:36ZGordon Williams-4Hi Owen + Denis,
<br> Me and some of the people at Collabora have been looking at the
<br>feasibility of implementing some kind of freeze of updates with Gtk too,
<br>in order to try and reduce tearing artefacts that we are getting in
<br>the compositor.
<br> I guess in order to eradicate artefacts, you really need two-way
<br>communication between Gtk and the window manager as you say - as even if
<br>the compositor draws after a complete frame, there is no guarantee that
<br>the window hasn't started rendering the next frame and damaged the contents
<br>of the window.
<br> Even if there is a 'WAIT_FOR_COMPOSITOR' signalling mechanism,
<br>it could prove problematic to implement in Gtk when functions like
<br>gdk_window_scroll are expected not to block and yet to scroll the window
<br>contents immediately (however perhaps this could be postponed?).
<br> If we don't wait in Gtk, most likely drawing operations on the
<br>window will be locked while the window is composited (and the compositor
<br>will have to wait for the current drawing operation on the window to
<br>finish). At least this seems to be the case for us. With multiple
<br>windows this can end up stalling the window manager quite seriously,
<br>as it waits for each window in turn.
<br> One possible solution which would allow good performance
<br>without blocking would be to create extra pixmaps to perform triple
<br>buffering using the windowless Gtk branch.
<br><br>It is probably too much work, but it might be worth considering, given
<br>the advantages?
<br><br>It could work something like this:
<br><br>* The window manager adds two window properties, PIXMAP_A and PIXMAP_B,
<br> containing the IDs of two pixmaps.
<br>* Gtk detects this and writes a property, PIXMAP_WRITING (which is either
<br> A,B or W(for the window). This tells the window manager where the window
<br> is currently writing to.
<br>* After it has finished a frame, the window sets PIXMAP_READY to
<br> whatever PIXMAP_WRITING was (to signal a frame is drawn to the compositor)
<br> and then chooses a new destination for PIXMAP_WRITING.
<br>* The window manager detects the change of PIXMAP_READY, then sets
<br> PIXMAP_READING=PIXMAP_READY and composits using this pixmap. Damage
<br> events would need to be created specially when rendering to one
<br> of the two pixmaps.
<br>* In the mean time, the next time the window finishes rendering a frame,
<br> it sets PIXMAP_READY=PIXMAP_WRITING, and then chooses whichever of A,B
<br> or W is not specified in PIXMAP_READY or PIXMAP_READING.
<br><br> I believe this would work without any race conditions, however
<br>there are definitely quite a few issues here.
<br><br>Bad:
<br>* Memory usage - however there would be no need for the current double
<br> buffering in Gtk, so I suppose at least only one extra buffer is used,
<br> and we do save the overhead of allocating new pixmaps each frame.
<br>* Because there are 3 windows to render to, Gtk's exposed area would have to
<br> be the sum of the previous 2 exposed areas (or the previous two exposed
<br> areas would have to be copied from PIXMAP_READY). In a lot of cases
<br> (scrolling) this would not be any worse than doing the panning operation
<br> I guess, but lots of small updates in different areas could be slower.
<br>* Overly ambitious? I have no idea of the internals of the windowless
<br> branch. It could be relatively easy, or it could be extremely painful.
<br><br>Good:
<br>* Performance would be a lot better due to the non-blocking I imagine.
<br>* There would be no need for double buffering in Gtk and hence no blitting of
<br> the final image, and no allocation of damage-sized pixmaps for every frame
<br> - which would be a decent performance boost.
<br>* Hopefully no flicker whatsoever
<br><br>Any thoughts? This is probably a fair chunk of work, but I don't see many
<br>other ways of getting rid of tearing completely. Proper double buffering
<br>(flipping buffers, not Gtk's blitting) could be possible if memory usage
<br>were a problem, but that might cause more problems with synchronisation?
<br><br>- Gordon
<br>
<br><br>-----------------------------
<br><br>On Mon, 2009-06-29 at 10:10 +0200, Denis Dzyubenko wrote:
<div class='shrinkable-quote'><br>> Hi Owen,
<br>>
<br>> Owen Taylor wrote:
<br>> > Fixing this really requires application intervention - when the
<br>> > compositor receives the MapNotify for the window the window might
<br>> > have drawn yet, or might not, and there's no way that the
<br>> > compositor can know.
<br>> >
<br>> > This is actually a symptom of a more general situation - an
<br>> > application wants to make multiple X requests (here a map and
<br>> > then the redraw) and not have the compositor draw until it is done.
<br>> >
<br>> > Thinking of it that way - that gives a pretty straightforward
<br>> > solution - the app can set a property that says "don't update me" -
<br>> > say _NET_WM_FREEZE_UPDATES - and then remove it when it is ready
<br>> > to be painted again.
<br>>
<br>> Sounds like an excellent idea, however it also sounds similar to
<br>> something that the wm-spec already have - can we use the existing
<br>> _NET_WM_SYNC_REQUEST protocol for that? Since compositing manager might
<br>> already support it, it could be pretty straightforward to implement the
<br>> same protocol for the case when a client window is initially mapped. For
<br>> example, when the compositor receives the MapNotify, it might send the
<br>> _NET_WM_SYNC_REQUEST client message and delay showing the window until
<br>> the client responds by setting a _NET_WM_SYNC_REQUEST_COUNTER.
</div><br>I was originally going to respond and say "it sounds related, but it
<br>isn't related."
<br><br>But then I had an idea. You can't really use _NET_WM_SYNC_REQUEST
<br>unmodified - it's inherently initiated from the window manager and not
<br>from the client. And this needs to be initiated from the client. (*)
<br><br>But what if we turned _NET_WM_SYNC_REQUEST_COUNTER into a more
<br>general frame counter. With the following handling:
<br><br> - When the client starts drawing a frame, it increments the counter to
<br> an odd value to freeze updates.
<br> - When the client finishes drawing, it increments the counter to an
<br> even value to thaw updates.
<br> - When the window manager wants to do a sync, it picks an even value
<br> at least a 100 [arbitrary] values ahead of the last value it
<br> received from the client and sends _NET_WM_SYNC_REQUEST to the
<br> client with that value. The client then uses that value on the
<br> frame completion after processing the resize.
<br><br>Advantages of this:
<br><br> - It has the same race-condition-free-startup and no-round-trip on
<br> updates as my proposal.
<br><br> - It integrates with the sync request system in an aesthetically
<br> pleasing fashion.
<br><br> - It has a very useful extension:
<br><br> After redrawing a frame, the window manager sends a
<br> _NET_WM_FRAME_REDRAWN client message to all clients updating
<br> the frame counter since the last redraw. The message contains
<br> the frame value (and maybe some timing information.)
<br><br> Voila: properly throttled application updates in a composited
<br> environment.
<br><br>Disadvantages of this:
<br><br> - Compatibility is tricky; if the window manager is expecting the
<br> old _NET_WM_SYNC_REQUEST_COUNTER behavior, spontaneous client
<br> updates will break the WM's use of _NET_WM_SYNC_REQUEST as far
<br> as I can tell.
<br><br> Having the client adapt its behavior is tricky because:
<br><br> - Switching between compositing managers and window managers
<br> in the fly.
<br> - The possibility of a standalone compositor that wants the
<br> frame counter with an old window manager that expects the
<br> old sync counter behavior.
<br><br> So, I don't really see how to avoid having the application expose
<br> two separate counters. [ Applications could, of course, choose to
<br> only support the new method ... we could deprecate the old way]
<br><br> - The Sync extension is not fun to understand and use; it's much
<br> harder to implement the above as compared to my
<br> _NET_WM_FREEZE_UPDATES. Toolkits and window managers have however,
<br> already figured out much of this to handle _NET_WM_SYNC_REQUEST.
<br><br>- Owen
<br><br>(*) Even if you accept the extra WM <=> client round trip, I don't
<br>think it works out without toolkit modifications to have the window
<br>manager to spontaneously ask for a sync - it's specified currently
<br>to be tied to a ConfigureNotify. Plus, it doesn't extend to the
<br>other uses cases like atomic frame updates.
<br><br><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24972209&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24911563Two window managers2009-08-10T21:35:38Z2009-08-10T21:35:38ZPradeep Reddy-4Hi,<br><br>I have a set up with dual monitors running with separate X-Screen option in Nvidia server settings. I dont really bother whether it is twinview or seperate X-Screen.<br>I would like to run two different window mangers or two separate instances of window managers on each. I am using Ubuntu Jaunty and gdm to login (load X).<br>
<br>kindly give me some hacks or key ideas how do i procedd with. I have googled and got no fruitful information in it.<br><br>Any help will be highly appriciated,<br><br>Thanks in advance,<br>Pradeep<br>
<br />_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24911563&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24537021Re: Freezing updates for compositing managers2009-07-17T08:47:27Z2009-07-17T08:47:27ZDenis Dzyubenko-2Hi Owen,
<br><br>Sorry for the late reply. Now when things settled up and I thought a bit
<br>about it your last solution sounds almost perfect.
<br><br>Owen Taylor wrote:
<br><div class='shrinkable-quote'><br>> But what if we turned _NET_WM_SYNC_REQUEST_COUNTER into a more
<br>> general frame counter. With the following handling:
<br>>
<br>> - When the client starts drawing a frame, it increments the counter to
<br>> an odd value to freeze updates.
<br>> - When the client finishes drawing, it increments the counter to an
<br>> even value to thaw updates.
<br>> - When the window manager wants to do a sync, it picks an even value
<br>> at least a 100 [arbitrary] values ahead of the last value it
<br>> received from the client and sends _NET_WM_SYNC_REQUEST to the
<br>> client with that value. The client then uses that value on the
<br>> frame completion after processing the resize.
</div><br>In your email you mentioned a possible need for the second counter - so
<br>what if we extend the NET_WM_SYNC_REQUEST specification to include a
<br>second counter, so that the NET_WM_SYNC_REQUEST_COUNTER property will
<br>contain two counters.
<br><br>* The first counter should be set by the client as a response to the
<br>_NET_WM_SYNC_REQUEST client message (all according to the current
<br>specification).
<br>* The second counter is set by the client when it wants to freeze
<br>updates and its value can be arbitrary (i.e. doesn't depend on the
<br>ConfigureNotify/ClientMessage pair).
<br><br>This way we maintain backward compatibility - if the
<br>windowmanager/compositor doesn't know about the second counter, they'll
<br>just ignore it and get only the first counter with a
<br>XGetWindowProperty() call.
<br><br>It should also be completely safe if the client doesn't support having
<br>two counters, but the window manager does - the GetWindowProperty() will
<br>just return the first item and the window manager can easily check how
<br>many counter are actually there.
<br><br>> Advantages of this:
<br>>
<br>> - It has the same race-condition-free-startup and no-round-trip on
<br>> updates as my proposal.
<br>>
<br>> - It integrates with the sync request system in an aesthetically
<br>> pleasing fashion.
<br><br>The same advantages apply and I can only see one possible disadvantage -
<br>if the wm/compositor doesn't handle counter updates that are done not in
<br>the response to the ConfigureNotify, but I'd expect window managers to
<br>handle this case pretty well since there is always a possibility of
<br>broken client that doesn't use the NET_WM_SYNC_REQUEST protocol properly.
<br><br><br>I've made a test implementation of this for Qt:
<br><a href="http://pastebin.ca/1498362?nomobile=1" target="_top" rel="nofollow">http://pastebin.ca/1498362?nomobile=1</a><br>(the patch is against Qt master (trunk) which has already introduced
<br>support for the original _NET_WM_SYNC_REQUEST protocol).
<br><br>--
<br>Denis Dzyubenko
<br>Software Engineer
<br>Nokia, Qt Software
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24537021&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24314534Re: multiple strut at same edge?2009-07-02T14:50:03Z2009-07-02T14:50:03ZJohn S. Yates, Jr.On Wed, Jul 1, 2009 at 6:22 PM, John Yates<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24314534&i=0" target="_top" rel="nofollow">john@...</a>> wrote:
<br><br>>> Are you saying that the KDE3 panel was/is capable of positioning
<br>>> itself immediately adjacent to an earlier strut that had already taken
<br>>> up a position at the actual screen edge? That is the only case of
<br>>> interest. Otherwise I do no understand what you believe would be
<br>>> broken.
<br><br>My bad. After posting I realized I should have specified that the
<br>earlier struct come from a distinct application.
<br><br>On Thu, Jul 2, 2009 at 2:09 AM, Nathaniel Smith<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24314534&i=1" target="_top" rel="nofollow">njs@...</a>> wrote:
<br><br>> A quick check confirms that with the current Gnome panel (2.26.1) you
<br>> can happily place two panels on the same edge of the screen, and they
<br>> will arrange themselves next to each other without overlapping. They
<br>> set their strut property in absolute terms (as per the current spec),
<br>> i.e. for me the first one reserves 25 pixels and then the second one
<br>> reserves 50.
<br><br>Sure. Once a panel implementation allows multiple struts along
<br>orthogonal edges it most likely already has logic to avoid corner
<br>overlap. Generalizing to parallel struts is probably very little
<br>additional logic. This is easy to do because it is all handled with a
<br>single application. That is _radically_ less work than figuring out
<br>how to deal with struts from other application whose existence and
<br>properties are communicated only via window messaging.
<br><br>I confirmed and extended the Gnome panels experiment. The behavior is
<br>clearly that which I suggested in my earlier posting:
<br>- panels never overlap, whether they are parallel or orthogonal
<br>- panels always migrate as close to their configured edge as possible
<br>- when a panel closer to the edge disappears all remaining panels
<br>along that edge move outwards
<br><br>There is a clear intended behavior here. Yet it break immediately when
<br>one introduces panels supplied by a distinct application.
<br><br>I installed LXPanel from LXDE. LXPanel is equally scrupulous above
<br>not overlapping other instances of LXPanel. In fact once it has a
<br>panel at a given edge the choice of that edge becomes greyed out when
<br>positioning additional LXPanels.
<br><br>Existence of a Gnome panel on the screen does not cause a similar
<br>reduction in choices. When I configure LXPanel to the same edge as a
<br>Gnome panel they overlap entirely. When I configure the panels to be
<br>orthogonal corners overlap.
<br><br>The breakage runs in both directions. It makes no difference whether
<br>I am reconfiguring a LXPanel or Gnome panel, neither is capable of
<br>presenting the same behavior as when it is dealing with an homogeneous
<br>population of struts of its own creation.
<br><br>>> It sounds like you are suggesting simply codifying the currently
<br>>> observed behavior. If you do go that route then I would request that
<br>>> you also provide description of an approved algorithm by which a
<br>>> window can reliably set and maintain its partial strut property so as
<br>>> to avoid overlapping struts while always maximizing the central
<br>>> workspace in the face of arbitrary other struts coming and going.
<br>>
<br>> I don't see any simple algorithm for this, but you are welcome to
<br>> invent one.
<br><br>Sure... the WM is only entity with access to the global picture so let
<br>it take responsibility :-)
<br><br>> (Or, since at least the Gnome panel is able to do
<br>> something kind of like what you want, it might contain such an
<br>> algorithm.)
<br><br>The experiments described above prove that when it comes to
<br>interacting gracefully with other applications no such algorithm
<br>exists within Gnome panel.
<br><br>> Note that overlapping struts per se are not a problem; the
<br>> strut property just tells the WM to avoid using a bit of the screen,
<br>> and if there are two windows telling the WM to avoid the same part of
<br>> the screen then the WM doesn't really care.
<br><br>Yes, the current strut definition is problematic. It is an
<br>essentially visual description of the screen. There is a complete
<br>absence of any expression of intent. In this sense the design recalls
<br>the critique of MOTIF hints that motivated the introduction of
<br>_NET_WM_WINDOW_TYPE:
<br><br>Rationale: This hint is intended to replace the MOTIF hints. One of
<br>the objections to the MOTIF hints is that they are a purely visual
<br>description of the window decoration. By describing the function of
<br>the window, the Window Manager can apply consistent decoration and
<br>behavior to windows of the same type. Possible examples of behavior
<br>include keeping dock/panels on top or allowing pinnable menus /
<br>toolbars to only be hidden when another window has focus (NextStep
<br>style).
<br><br>I think that what applications really want is to be able to decrease
<br>the remaining workspace in the vicinity of a screen edge and to be
<br>able to position a window relative to that carved out, protected
<br>space. In the most common case, namely no more than a single strut
<br>window at each edge such a changed definition would be
<br>indistinguishable from today's strut handling.
<br><br>> It sounds like what you really want is for the window manager to take
<br>> over the positioning of panels. The problem is that struts and panel
<br>> window position are logically independent -- consider auto-hide
<br>> panels, that may take up more or less space on the screen without
<br>> changing the logical "workspace". (Also there's obviously a major
<br>> backwards compatibility issue with totally redoing how panels and wm's
<br>> interact, but you would need to at least solve the technical issues
<br>> before even trying to argue that breaking compatibility was worth it.)
<br><br>This is my very first foray into the world of windowing and its
<br>standards. For now I am simply striving for an acknowledgment of
<br>existence of problematic scenario and perhaps some consensus on what
<br>applications expect in the presence of heterogeneous struts.
<br><br>My driving use case is that I want to have a single, sticky,
<br>strut-like emacs minibuffer adjacent to a Gnome panel, a KDE kicker or
<br>something similar. You will notice that I am not dealing with a
<br>Desktop Environment's thinking that it can justify the simplifying
<br>assumption that it is the only source of struts. My minibuffer fully
<br>expects other struts to exist. It just does not have a convenient,
<br>reliable way of cohabitting correctly with them. I really believe
<br>that to solve this problem of heterogeneous struts and to compute the
<br>size of my minibuffer strut I should not have to query the window
<br>system to identify and analyze all existing struts. I just want to
<br>say here is a window, please make it this high, as wide as you can,
<br>position as close to the top (or bottom) as possible and do not allow
<br>other windows to overlap it.
<br><br>I believe further that that description of my own intent more or less
<br>parallels that of nearly any application creating a strut. Can anyone
<br>suggest a counter example?
<br><br>/john
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24314534&i=2" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24301714Re: multiple strut at same edge?2009-07-01T23:09:07Z2009-07-01T23:09:07ZNathaniel SmithOn Wed, Jul 1, 2009 at 6:22 PM, John Yates<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24301714&i=0" target="_top" rel="nofollow">john@...</a>> wrote:
<br>> Are you saying that the KDE3 panel was/is capable of positioning
<br>> itself immediately adjacent to an earlier strut that had already taken
<br>> up a position at the actual screen edge? That is the only case of
<br>> interest. Otherwise I do no understand what you believe would be
<br>> broken.
<br><br>A quick check confirms that with the current Gnome panel (2.26.1) you
<br>can happily place two panels on the same edge of the screen, and they
<br>will arrange themselves next to each other without overlapping. They
<br>set their strut property in absolute terms (as per the current spec),
<br>i.e. for me the first one reserves 25 pixels and then the second one
<br>reserves 50.
<br><br>>> On the other hand I agree that this case isn't covered very well in the spec
<br>>> and perhaps could use at least a clarification.
<br>>
<br>> It sounds like you are suggesting simply codifying the currently
<br>> observed behavior. If you do go that route then I would request that
<br>> you also provide description of an approved algorithm by which a
<br>> window can reliably set and maintain its partial strut property so as
<br>> to avoid overlapping struts while always maximizing the central
<br>> workspace in the face of arbitrary other struts coming and going.
<br><br>I don't see any simple algorithm for this, but you are welcome to
<br>invent one. (Or, since at least the Gnome panel is able to do
<br>something kind of like what you want, it might contain such an
<br>algorithm.) Note that overlapping struts per se are not a problem; the
<br>strut property just tells the WM to avoid using a bit of the screen,
<br>and if there are two windows telling the WM to avoid the same part of
<br>the screen then the WM doesn't really care.
<br><br>It sounds like what you really want is for the window manager to take
<br>over the positioning of panels. The problem is that struts and panel
<br>window position are logically independent -- consider auto-hide
<br>panels, that may take up more or less space on the screen without
<br>changing the logical "workspace". (Also there's obviously a major
<br>backwards compatibility issue with totally redoing how panels and wm's
<br>interact, but you would need to at least solve the technical issues
<br>before even trying to argue that breaking compatibility was worth it.)
<br><br>-- Nathaniel
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24301714&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24299603Re: multiple strut at same edge?2009-07-01T18:22:47Z2009-07-01T18:22:47ZJohn S. Yates, Jr.On Wed, Jul 1, 2009 at 9:56 AM, Lubos Lunak<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24299603&i=0" target="_top" rel="nofollow">l.lunak@...</a>> wrote:
<br>>
<br>> The spec says "The property contains 4 cardinals specifying the width of the
<br>> reserved area at each border of the screen". This does not explicitly say it,
<br>> but I read "reserved area at border" as meaning the struct needs to be
<br>> absolute. And that is also how the KDE3 panel used it and it worked. So
<br>> changing this could mean breaking backwards compatibility.
<br><br>Are you saying that the KDE3 panel was/is capable of positioning
<br>itself immediately adjacent to an earlier strut that had already taken
<br>up a position at the actual screen edge? That is the only case of
<br>interest. Otherwise I do no understand what you believe would be
<br>broken.
<br><br>> On the other hand I agree that this case isn't covered very well in the spec
<br>> and perhaps could use at least a clarification.
<br><br>It sounds like you are suggesting simply codifying the currently
<br>observed behavior. If you do go that route then I would request that
<br>you also provide description of an approved algorithm by which a
<br>window can reliably set and maintain its partial strut property so as
<br>to avoid overlapping struts while always maximizing the central
<br>workspace in the face of arbitrary other struts coming and going.
<br><br>/john
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24299603&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24290334Re: Freezing updates for compositing managers2009-07-01T07:01:49Z2009-07-01T07:01:49ZLubos LunakOn Monday 29 of June 2009, Soeren Sandmann wrote:
<div class='shrinkable-quote'><br>> Owen Taylor <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290334&i=0" target="_top" rel="nofollow">otaylor@...</a>> writes:
<br>> > Main question for me is whether this belongs in the wm-spec and
<br>> > should be called _NET_WM_* ... it's clearly compositing-manager
<br>> > specific not window manager-specific, but there's not really
<br>> > (as far as know) a good alternate location.
<br>>
<br>> There is already some compositing manager specific text in the draft
<br>> spec:
<br>>
<br>> <a href="http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552725" target="_top" rel="nofollow">http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552725</a><br>>
<br>> That is still a draft though, so maybe it's time for someone to look
<br>> at making a new release.
</div><br> I think the prevailing opinion last time this was discussed [*] was that
<br>compositing stuff should be in a separate spec. No actual action has taken
<br>place though.
<br><br>[*] <a href="http://mail.gnome.org/archives/wm-spec-list/2008-January/msg00014.html" target="_top" rel="nofollow">http://mail.gnome.org/archives/wm-spec-list/2008-January/msg00014.html</a><br><br>--
<br>Lubos Lunak
<br>KDE developer
<br>--------------------------------------------------------------
<br>SUSE LINUX, s.r.o. e-mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290334&i=1" target="_top" rel="nofollow">l.lunak@...</a> , <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290334&i=2" target="_top" rel="nofollow">l.lunak@...</a>
<br>Lihovarska 1060/12 tel: +420 284 084 672
<br>190 00 Prague 9 fax: +420 284 028 951
<br>Czech Republic <a href="http://www.suse.cz" target="_top" rel="nofollow">http://www.suse.cz</a><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290334&i=3" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24290239Re: multiple strut at same edge?2009-07-01T06:56:27Z2009-07-01T06:56:27ZLubos LunakOn Monday 29 of June 2009, John Yates wrote:
<div class='shrinkable-quote'><br>> I am attempting to create a permanent Emacs minibuffer near the top of
<br>> my screen. In many distributions this is also the location of a top
<br>> Gnome panel with a strut property. My understanding is that for my
<br>> minibuffer never to be obscured it too needs to be a strut.
<br>> Unfortunately I have not found any specification of how a window
<br>> manager should behave when multiple struts are specified requesting
<br>> the same edge.
<br>>
<br>> Empirically I have found that Metacity interprets all struts relative
<br>> to the actual screen edge (so effectively overlapping) but then lays
<br>> out the strut windows without overlap.
</div><br> Are you sure it is Metacity who places the windows? I think it's usually the
<br>panel apps themselves who do the placement.
<br><div class='shrinkable-quote'><br>> Without care the net effect is
<br>> a window in the desire position but without proper strut protection.
<br>> Is this intended behavior or has my use case simply never been
<br>> considered?
<br>>
<br>> This behavior requires an application to enumerate all struts along
<br>> the desired edge and to sum their window geometries. Unless all strut
<br>> lifetimes are properly nested an application must also reevaluate this
<br>> computation every time a potential strut window disappears or empty
<br>> strut space may be left on screen. This seems complex, fragile and
<br>> more properly to be the responsibility of the window manager.
<br>>
<br>> Thus it seems to me that struts should be specified to be additive.
<br>> Any comments?
</div><br> The spec says "The property contains 4 cardinals specifying the width of the
<br>reserved area at each border of the screen". This does not explicitly say it,
<br>but I read "reserved area at border" as meaning the struct needs to be
<br>absolute. And that is also how the KDE3 panel used it and it worked. So
<br>changing this could mean breaking backwards compatibility.
<br><br> On the other hand I agree that this case isn't covered very well in the spec
<br>and perhaps could use at least a clarification.
<br><br>--
<br>Lubos Lunak
<br>KDE developer
<br>--------------------------------------------------------------
<br>SUSE LINUX, s.r.o. e-mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290239&i=0" target="_top" rel="nofollow">l.lunak@...</a> , <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290239&i=1" target="_top" rel="nofollow">l.lunak@...</a>
<br>Lihovarska 1060/12 tel: +420 284 084 672
<br>190 00 Prague 9 fax: +420 284 028 951
<br>Czech Republic <a href="http://www.suse.cz" target="_top" rel="nofollow">http://www.suse.cz</a><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24290239&i=2" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24265002Re: multiple strut at same edge?2009-06-29T19:20:48Z2009-06-29T19:20:48ZJohn S. Yates, Jr.Following up on my earlier posting on
<br><a href="http://fvwm-ewmh.sourceforge.net/man.html" target="_top" rel="nofollow">http://fvwm-ewmh.sourceforge.net/man.html</a> I have found the following
<br>suggestion that fvwm believes that by default struts are additive:
<br><br>====
<br><br>*FvwmNetHints: MyStrut left right top bottom
<br> Where left, right, top and bottom are positive or null integer
<br>which represent an area in pixels from the left of the screen to left,
<br>from the right of the screen to right, from the top of the screen to
<br>top and from the bottom of the screen to bottom. This area is added to
<br>the strut area which is computed from the compilant application
<br>WM_STRUT hint. The strut area is the area from which the working area
<br>is defined: the working area is the complement of the strut area vs
<br>the screen. This option is totally dynamic.
<br><br>*FvwmNetHints: StrutOverride
<br> Where bool is either True of False. If bool is True, then
<br>FvwmNetHints take in account only the MyStrut FvwmNetHints
<br>configuration option to compute the working area. Default is False.
<br>This option is totally dynamic.
<br><br>====
<br><br>/john
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24265002&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24257731Re: Freezing updates for compositing managers2009-06-29T09:47:31Z2009-06-29T09:47:31ZOwen TaylorOn Mon, 2009-06-29 at 10:10 +0200, Denis Dzyubenko wrote:
<div class='shrinkable-quote'><br>> Hi Owen,
<br>>
<br>> Owen Taylor wrote:
<br>> > Fixing this really requires application intervention - when the
<br>> > compositor receives the MapNotify for the window the window might
<br>> > have drawn yet, or might not, and there's no way that the
<br>> > compositor can know.
<br>> >
<br>> > This is actually a symptom of a more general situation - an
<br>> > application wants to make multiple X requests (here a map and
<br>> > then the redraw) and not have the compositor draw until it is done.
<br>> >
<br>> > Thinking of it that way - that gives a pretty straightforward
<br>> > solution - the app can set a property that says "don't update me" -
<br>> > say _NET_WM_FREEZE_UPDATES - and then remove it when it is ready
<br>> > to be painted again.
<br>>
<br>> Sounds like an excellent idea, however it also sounds similar to
<br>> something that the wm-spec already have - can we use the existing
<br>> _NET_WM_SYNC_REQUEST protocol for that? Since compositing manager might
<br>> already support it, it could be pretty straightforward to implement the
<br>> same protocol for the case when a client window is initially mapped. For
<br>> example, when the compositor receives the MapNotify, it might send the
<br>> _NET_WM_SYNC_REQUEST client message and delay showing the window until
<br>> the client responds by setting a _NET_WM_SYNC_REQUEST_COUNTER.
</div><br>I was originally going to respond and say "it sounds related, but it
<br>isn't related."
<br><br>But then I had an idea. You can't really use _NET_WM_SYNC_REQUEST
<br>unmodified - it's inherently initiated from the window manager and not
<br>from the client. And this needs to be initiated from the client. (*)
<br><br>But what if we turned _NET_WM_SYNC_REQUEST_COUNTER into a more
<br>general frame counter. With the following handling:
<br><br> - When the client starts drawing a frame, it increments the counter to
<br> an odd value to freeze updates.
<br> - When the client finishes drawing, it increments the counter to an
<br> even value to thaw updates.
<br> - When the window manager wants to do a sync, it picks an even value
<br> at least a 100 [arbitrary] values ahead of the last value it
<br> received from the client and sends _NET_WM_SYNC_REQUEST to the
<br> client with that value. The client then uses that value on the
<br> frame completion after processing the resize.
<br><br>Advantages of this:
<br><br> - It has the same race-condition-free-startup and no-round-trip on
<br> updates as my proposal.
<br><br> - It integrates with the sync request system in an aesthetically
<br> pleasing fashion.
<br><br> - It has a very useful extension:
<br><br> After redrawing a frame, the window manager sends a
<br> _NET_WM_FRAME_REDRAWN client message to all clients updating
<br> the frame counter since the last redraw. The message contains
<br> the frame value (and maybe some timing information.)
<br><br> Voila: properly throttled application updates in a composited
<br> environment.
<br><br>Disadvantages of this:
<br><br> - Compatibility is tricky; if the window manager is expecting the
<br> old _NET_WM_SYNC_REQUEST_COUNTER behavior, spontaneous client
<br> updates will break the WM's use of _NET_WM_SYNC_REQUEST as far
<br> as I can tell.
<br><br> Having the client adapt its behavior is tricky because:
<br><br> - Switching between compositing managers and window managers
<br> in the fly.
<br> - The possibility of a standalone compositor that wants the
<br> frame counter with an old window manager that expects the
<br> old sync counter behavior.
<br><br> So, I don't really see how to avoid having the application expose
<br> two separate counters. [ Applications could, of course, choose to
<br> only support the new method ... we could deprecate the old way]
<br><br> - The Sync extension is not fun to understand and use; it's much
<br> harder to implement the above as compared to my
<br> _NET_WM_FREEZE_UPDATES. Toolkits and window managers have however,
<br> already figured out much of this to handle _NET_WM_SYNC_REQUEST.
<br><br>- Owen
<br><br>(*) Even if you accept the extra WM <=> client round trip, I don't
<br>think it works out without toolkit modifications to have the window
<br>manager to spontaneously ask for a sync - it's specified currently
<br>to be tied to a ConfigureNotify. Plus, it doesn't extend to the
<br>other uses cases like atomic frame updates.
<br><br><br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24257731&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24252513multiple strut at same edge?2009-06-29T04:32:51Z2009-06-29T04:32:51ZJohn S. Yates, Jr.I am attempting to create a permanent Emacs minibuffer near the top of
<br>my screen. In many distributions this is also the location of a top
<br>Gnome panel with a strut property. My understanding is that for my
<br>minibuffer never to be obscured it too needs to be a strut.
<br>Unfortunately I have not found any specification of how a window
<br>manager should behave when multiple struts are specified requesting
<br>the same edge.
<br><br>Empirically I have found that Metacity interprets all struts relative
<br>to the actual screen edge (so effectively overlapping) but then lays
<br>out the strut windows without overlap. Without care the net effect is
<br>a window in the desire position but without proper strut protection.
<br>Is this intended behavior or has my use case simply never been
<br>considered?
<br><br>This behavior requires an application to enumerate all struts along
<br>the desired edge and to sum their window geometries. Unless all strut
<br>lifetimes are properly nested an application must also reevaluate this
<br>computation every time a potential strut window disappears or empty
<br>strut space may be left on screen. This seems complex, fragile and
<br>more properly to be the responsibility of the window manager.
<br><br>Thus it seems to me that struts should be specified to be additive.
<br>Any comments?
<br><br>/john
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24252513&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24252369Re: Freezing updates for compositing managers2009-06-29T04:21:30Z2009-06-29T04:21:30ZSoeren Sandmann-2Owen Taylor <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24252369&i=0" target="_top" rel="nofollow">otaylor@...</a>> writes:
<br><br>> Main question for me is whether this belongs in the wm-spec and
<br>> should be called _NET_WM_* ... it's clearly compositing-manager
<br>> specific not window manager-specific, but there's not really
<br>> (as far as know) a good alternate location.
<br><br>There is already some compositing manager specific text in the draft
<br>spec:
<br><br> <a href="http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552725" target="_top" rel="nofollow">http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552725</a><br><br>That is still a draft though, so maybe it's time for someone to look
<br>at making a new release.
<br><br><br><br>Soren
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24252369&i=1" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>tag:old.nabble.com,2006:post-24250034Re: Freezing updates for compositing managers2009-06-29T01:10:43Z2009-06-29T01:10:43ZDenis Dzyubenko-2Hi Owen,
<br><br>Owen Taylor wrote:
<div class='shrinkable-quote'><br>> Fixing this really requires application intervention - when the
<br>> compositor receives the MapNotify for the window the window might
<br>> have drawn yet, or might not, and there's no way that the
<br>> compositor can know.
<br>>
<br>> This is actually a symptom of a more general situation - an
<br>> application wants to make multiple X requests (here a map and
<br>> then the redraw) and not have the compositor draw until it is done.
<br>>
<br>> Thinking of it that way - that gives a pretty straightforward
<br>> solution - the app can set a property that says "don't update me" -
<br>> say _NET_WM_FREEZE_UPDATES - and then remove it when it is ready
<br>> to be painted again.
</div><br>Sounds like an excellent idea, however it also sounds similar to
<br>something that the wm-spec already have - can we use the existing
<br>_NET_WM_SYNC_REQUEST protocol for that? Since compositing manager might
<br>already support it, it could be pretty straightforward to implement the
<br>same protocol for the case when a client window is initially mapped. For
<br>example, when the compositor receives the MapNotify, it might send the
<br>_NET_WM_SYNC_REQUEST client message and delay showing the window until
<br>the client responds by setting a _NET_WM_SYNC_REQUEST_COUNTER.
<br><br>--
<br>Denis Dzyubenko
<br>Software Engineer
<br>Nokia, Qt Software
<br>_______________________________________________
<br>wm-spec-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24250034&i=0" target="_top" rel="nofollow">wm-spec-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/wm-spec-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br>