proposed addition to EWMH: _NET_WM_NORMAL_GEOMETRY

[Mark Tiefenbruck]

This goes in the list of Application Window Properties. The idea is
that this holds the previous state of a window that has been
temporarily changed by the window manager, e.g. while maximized or
fullscreen. If the user switches or restarts his window manager, this
information is currently lost, giving unexpected results when trying
to restore the state. This property gives the new window manager the
information it needs to restore the window properly.

One issue is that of ordering width and height vs. x and y. The
--geometry argument typically uses width, height, x, y, whereas
_NET_WORKAREA uses x, y, width, height. I've chosen width, height, x,
y for now. Another question is whether or not the client should be
allowed to change these values. I've decided for now that it may alter
them only from withdrawn state.

_NET_WM_NORMAL_GEOMETRY width, height, x, y, CARDINAL[4]/32

Array of four cardinals that defines the size and position to which
the window should be restored when changing window state. The values
should be set according to the same rules as WM_NORMAL_HINTS given in
ICCCM Section 4.1.2.3. This property SHOULD be updated by the window
manager whenever a change in _NET_WM_STATE corresponds to a change in
window geometry. A client MAY change this property from the Withdrawn
state but MUST NOT change it while the window is being managed.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Fri, 27 Jul 2007 19:42:25 -0700 "Mark Tiefenbruck" <mark@...>
babbled:

> This goes in the list of Application Window Properties. The idea is
> that this holds the previous state of a window that has been
> temporarily changed by the window manager, e.g. while maximized or
> fullscreen. If the user switches or restarts his window manager, this
> information is currently lost, giving unexpected results when trying
> to restore the state. This property gives the new window manager the
> information it needs to restore the window properly.
>
> One issue is that of ordering width and height vs. x and y. The
> --geometry argument typically uses width, height, x, y, whereas
> _NET_WORKAREA uses x, y, width, height. I've chosen width, height, x,
> y for now. Another question is whether or not the client should be
> allowed to change these values. I've decided for now that it may alter
> them only from withdrawn state.

i disagree with the ordering - -geometry is the way it is because of parsing
ans spacing - this is a command-lin e argument. different from PROPERITES. all
other netwm PROPERTIES are X,Y,WIDTH,HEIGHT - which is actually the most common
order you see such geometry in API calls for creating and moving/resizing
windows, drawing boxes etc. etc. i see no good reason to re-order the arguments
in a property based on the ordering in just 1 command-line argument.

> _NET_WM_NORMAL_GEOMETRY width, height, x, y, CARDINAL[4]/32
>
> Array of four cardinals that defines the size and position to which
> the window should be restored when changing window state. The values
> should be set according to the same rules as WM_NORMAL_HINTS given in
> ICCCM Section 4.1.2.3. This property SHOULD be updated by the window
> manager whenever a change in _NET_WM_STATE corresponds to a change in
> window geometry. A client MAY change this property from the Withdrawn
> state but MUST NOT change it while the window is being managed.
>
>   Mark
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> i disagree with the ordering - -geometry is the way it is because of parsing
> ans spacing - this is a command-lin e argument. different from PROPERITES. all
> other netwm PROPERTIES are X,Y,WIDTH,HEIGHT - which is actually the most common
> order you see such geometry in API calls for creating and moving/resizing
> windows, drawing boxes etc. etc. i see no good reason to re-order the arguments
> in a property based on the ordering in just 1 command-line argument.

Fair enough. It was a rather arbitrary decision, anyway. I figured
there might be circumstances where size would be provided but not
coordinates. On the other hand, maybe just the opposite will occur
with future _NET_WM_STATE properties. I don't think there's a natural
way to allow for these with just one window property, anyway.

Any other problems?

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Fri, 27 Jul 2007 20:05:19 -0700 "Mark Tiefenbruck" <mark@...>
babbled:

> > i disagree with the ordering - -geometry is the way it is because of parsing
> > ans spacing - this is a command-lin e argument. different from PROPERITES.
> > all other netwm PROPERTIES are X,Y,WIDTH,HEIGHT - which is actually the
> > most common order you see such geometry in API calls for creating and
> > moving/resizing windows, drawing boxes etc. etc. i see no good reason to
> > re-order the arguments in a property based on the ordering in just 1
> > command-line argument.
>
> Fair enough. It was a rather arbitrary decision, anyway. I figured
> there might be circumstances where size would be provided but not
> coordinates. On the other hand, maybe just the opposite will occur
> with future _NET_WM_STATE properties. I don't think there's a natural
> way to allow for these with just one window property, anyway.
>
> Any other problems?

not really - we already do this for e17 - but we have our own specific
properties we use to allow the wm to pass on state between restarts - haven't
made any attempt to pass it onto other wm's or make it stable/well defined
though.


--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

On 7/27/07, Mark Tiefenbruck <mark@...> wrote:

> This goes in the list of Application Window Properties. The idea is
> that this holds the previous state of a window that has been
> temporarily changed by the window manager, e.g. while maximized or
> fullscreen. If the user switches or restarts his window manager, this
> information is currently lost, giving unexpected results when trying
> to restore the state. This property gives the new window manager the
> information it needs to restore the window properly.
>
> One issue is that of ordering width and height vs. x and y. The
> --geometry argument typically uses width, height, x, y, whereas
> _NET_WORKAREA uses x, y, width, height. I've chosen width, height, x,
> y for now. Another question is whether or not the client should be
> allowed to change these values. I've decided for now that it may alter
> them only from withdrawn state.
>
> _NET_WM_NORMAL_GEOMETRY width, height, x, y, CARDINAL[4]/32
>
> Array of four cardinals that defines the size and position to which
> the window should be restored when changing window state. The values
> should be set according to the same rules as WM_NORMAL_HINTS given in
> ICCCM Section 4.1.2.3. This property SHOULD be updated by the window
> manager whenever a change in _NET_WM_STATE corresponds to a change in
> window geometry. A client MAY change this property from the Withdrawn
> state but MUST NOT change it while the window is being managed.

You could just have the WM restore its original geometry when shutting
down, but leave the state hints (max vert, etc) in tact for the new
window manager.  Then you can do exactly what you want without any new
hints.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> You could just have the WM restore its original geometry when shutting
> down, but leave the state hints (max vert, etc) in tact for the new
> window manager.  Then you can do exactly what you want without any new
> hints.

Yes, that's another possibility I considered. First of all, it's just
an ugly way to transfer information -- setting a window property is
less work and less disruptive than two XMoveResizes. Second, all of
that resizing may affect the application in not-so-nice ways; for
instance, I think video players would fall into this category. Third,
there may be other uses of the property than just restoring state. As
an example, a pager might use the information, rather than displaying
the actual geometry. Or, you might have a program similar to 3ddesk
that animates the changing of state and wants to do some rendering in
advance.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

On 7/27/07, Mark Tiefenbruck <mark@...> wrote:

> > You could just have the WM restore its original geometry when shutting
> > down, but leave the state hints (max vert, etc) in tact for the new
> > window manager.  Then you can do exactly what you want without any new
> > hints.
>
> Yes, that's another possibility I considered. First of all, it's just
> an ugly way to transfer information -- setting a window property is
> less work and less disruptive than two XMoveResizes. Second, all of
> that resizing may affect the application in not-so-nice ways; for
> instance, I think video players would fall into this category.

I don't really see how setting a window property and keeping it up to
date constantly is less work than an XMoveResize one time when you are
shutting down.

Nor do I see how adding a property that all WMs need to code around is
less disruptive than an XMoveResize that lets them know the correct
geometry without having to change anything at all.

And if a window can't handle being resized.. that's kind of funny. Are
your users switching/restarting their WM multiple times a second?
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> Nor do I see how adding a property that all WMs need to code around is
> less disruptive than an XMoveResize that lets them know the correct
> geometry without having to change anything at all.

I'm talking about disruptive for the user, not disruptive for the
programmer. The users are my priority here.

> And if a window can't handle being resized.. that's kind of funny. Are
> your users switching/restarting their WM multiple times a second?

Consider this example. You're watching a movie with a fullscreen
MPlayer. Your system receives a critical update to your window
manager, and it needs to restart. Which should happen: a) MPlayer
stays fullscreen and your window manager generally lets you focus on
the movie, or b) MPlayer resizes, you see a bunch of windows getting
reparented, and then MPlayer returns to fullscreen?

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Jim Gettys-3]

On Fri, 2007-07-27 at 21:28 -0700, Mark Tiefenbruck wrote:

> > And if a window can't handle being resized.. that's kind of funny. Are
> > your users switching/restarting their WM multiple times a second?
>
> Consider this example. You're watching a movie with a fullscreen
> MPlayer. Your system receives a critical update to your window
> manager, and it needs to restart. Which should happen: a) MPlayer
> stays fullscreen and your window manager generally lets you focus on
> the movie, or b) MPlayer resizes, you see a bunch of windows getting
> reparented, and then MPlayer returns to fullscreen?
>

This is a poor example.  Surely you can do better than this....  Window
managers should be able to run indefinitely, just as the X server.
                             - Jim

--
Jim Gettys
One Laptop Per Child


_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> This is a poor example.  Surely you can do better than this....  Window
> managers should be able to run indefinitely, just as the X server.

Seriously? Do you maintain a window manager? I guess we might as well
remove SIGSEGV from the kernel. It's a paragon of uselessness.

Whether or not a window manager SHOULD be able to run indefinitely is
irrelevant. Sometimes crashes do happen. Sometimes security issues
arise due to software that wasn't even written when you wrote your
window manager (e.g. a font or image library changing its code). These
problems aren't going away any time soon.

That brings up another example. Suppose the window manager crashes,
or, if you prefer, the user kills the window manager. You can't
restore the windows in this situation because you don't know your
internal state is reliable, among other reasons. If you haven't been
keeping the _NET_WM_NORMAL_GEOMETRY hint up to date, that information
is lost.

Even if I grant that it never happens to users, it does happen to
developers and testers. We have maximized windows, too.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

On 7/28/07, Mark Tiefenbruck <mark@...> wrote:

> > This is a poor example.  Surely you can do better than this....  Window
> > managers should be able to run indefinitely, just as the X server.
>
> Seriously? Do you maintain a window manager? I guess we might as well
> remove SIGSEGV from the kernel. It's a paragon of uselessness.
>
> Whether or not a window manager SHOULD be able to run indefinitely is
> irrelevant. Sometimes crashes do happen. Sometimes security issues
> arise due to software that wasn't even written when you wrote your
> window manager (e.g. a font or image library changing its code). These
> problems aren't going away any time soon.
>
> That brings up another example. Suppose the window manager crashes,
> or, if you prefer, the user kills the window manager. You can't
> restore the windows in this situation because you don't know your
> internal state is reliable, among other reasons. If you haven't been
> keeping the _NET_WM_NORMAL_GEOMETRY hint up to date, that information
> is lost.
>
> Even if I grant that it never happens to users, it does happen to
> developers and testers. We have maximized windows, too.

If crashing is a big concern for you, you could use a private window
property to save that state and restore it after the crash.  That
doesn't need any standard defined.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> If crashing is a big concern for you, you could use a private window
> property to save that state and restore it after the crash.  That
> doesn't need any standard defined.

That's not the point. The point is that window managers do need to be
updated now and then. Do you dispute that?

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Sat, 28 Jul 2007 14:24:24 -0700 "Mark Tiefenbruck" <mark@...>
babbled:

> > If crashing is a big concern for you, you could use a private window
> > property to save that state and restore it after the crash.  That
> > doesn't need any standard defined.
>
> That's not the point. The point is that window managers do need to be
> updated now and then. Do you dispute that?

you still can use a private property entirely defined by your wm :) that is
what we do.

BUT - changing wm's mid-stream means you need to standardise such info, and it
means that a wm doesn't have to undergo a clean shutdown for a new one to kick
in properly.

then again - one would argue... how often do users change wm's? really? is this
worth standardising? i know that it is possible for me to support this - but
its usefulness is dubious as i have other things i also need to store between
restarts too and will still need private properties for this.

>   Mark
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>


--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> then again - one would argue... how often do users change wm's? really? is this
> worth standardising? i know that it is possible for me to support this - but

Well, I'm guessing that just about every single one of our users
(yours and mine and Dana's too) switched his WM at some point. It's in
the best interests of progress for users to be able to try out new WMs
seamlessly. Who knows what will be blamed on you?

> its usefulness is dubious as i have other things i also need to store between
> restarts too and will still need private properties for this.

I agree with this. We still need our own layer and window decoration
properties, but these haven't been standardized very well (and
probably can't be). If we're all going to be storing this info anyway,
I think we should be making a point to interoperate.

My situation is that I'm going to have to implement this as a new
property either way. I would prefer that it be a standard one so that
I don't have to change it later and so that it's compatible with other
window managers.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Sat, 28 Jul 2007 18:00:14 -0700 "Mark Tiefenbruck" <mark@...>
babbled:

> > then again - one would argue... how often do users change wm's? really? is
> > this worth standardising? i know that it is possible for me to support this
> > - but
>
> Well, I'm guessing that just about every single one of our users
> (yours and mine and Dana's too) switched his WM at some point. It's in
> the best interests of progress for users to be able to try out new WMs
> seamlessly. Who knows what will be blamed on you?

switched at some POINT. my point is - how many times do they switch - runtime -
and expect everything to "just come up as before". personally i'm willing to
accept a user even has to shut down all apps and their login session to change
wm's - even though they don't have to, i believe people switching wm's on the
fly is a RARE occurrence. most users try a wm for a bit - then stick to switch
a few weeks or months or years later. some of them go through a "try every wm
around for a few hours" phases - but these are rare and generally will live
with the "iffiness" of all their apps not quite being in the right state after
a switch.

so the point is - how many times a DAY or HOUR do you expect the typical user
to switch WM's? (not restart)? not even typical - the vast majority of users?

i'd put it at maybe 1 WM change per year. as an average. possibly less.

> > its usefulness is dubious as i have other things i also need to store
> > between restarts too and will still need private properties for this.
>
> I agree with this. We still need our own layer and window decoration
> properties, but these haven't been standardized very well (and
> probably can't be). If we're all going to be storing this info anyway,
> I think we should be making a point to interoperate.

sure - as i said  i don't see a problem with this - but the arguments for it
are not very strong.

> My situation is that I'm going to have to implement this as a new
> property either way. I would prefer that it be a standard one so that
> I don't have to change it later and so that it's compatible with other
> window managers.

you will need buy-in from a reasonable number of other wm authors to bother
making it a standard. my suggestion - make it a private property (just rename
it) and otherwise implement as you would - when you have done that - debugged
it, added the other 5 or 2 properties you really need for a restart / wm change
to work THEN propose that - what you have, as a standard just with a rename to
NETWM properties. this lets you refine your stuff without having to do "design
by committee/mediocrity" :) a lot faster and more convenient - especially as in
this case i don't think we see users needing to clamouring for such
interoperability :)

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list