Re: questions/suggestions about changes in 1.0pre2

[Julian Adams <julian adams gmx net>]

-----BEGIN PGP SIGNED MESSAGE-----

Firstly I think that a review of the situation like this is the best way to
review this. Thanks for doing one :)

Second I think it's crucial for everyone that implementations of the spec
interoperate (doh!). As such it's vital that v1.0 of the spec gets wrapped up
before KDE 2.0 ships, and that KDE 2.0 conforms to it.
Clearly there is no problems with anyone implementing extra stuff *so long as
it does not clash with the spec, or create potential clashes for the future*

Third the spec is about consensus. Items on which there isn't a consensus will
just have to not be in 1.0. 99.9 % of what's in there now everyone is happy
with. Despite this not being everything it's still going to make life much
better for people who use apps based on different desktop environments on X
(e.g. me !)

Fourth we've banged these ideas about quite a few times - I don't mind doing it
again - but we do need a conclusion. It's important that we pin this down, and
agree to live by it AND extend it cooperatively.

Finally my comments :

On Fri, 22 Sep 2000, Bradley T. Hughes
wrote: >I've been looking over the new "1.0pre2" spec that is on
freedesktop.org, >and I thought I should ask about some of the changes that
have been made >(I didn't see some of them discussed on this list)
>
>_NET_NUMBER_OF_DESKTOPS:  when I implemented the spec, a client could
>change this by sending a client message to the root window with
>message_type = _NET_NUMBER_OF_DESKTOPS, but now the spec says
>_NET_SET_NUMBER_OF_DESKTOPS.  This is the only root window message that
>uses a different message_type from the property itself.  I think this
>should be changed back to the original.

Agreed. Well spotted.
>
>_NET_DESKTOP_GEOMERTY:  <pedantic> The type should probably be
>CARDINAL[][2]/32 (same as _NET_DESKTOP_VIEWPORT) instead of just saying
>CARDINAL[2]/32... extra clarity</pedantic>

Agreed.
>
>_NET_WM_VISIBLE_NAME_STRING:  The _STRING should be dropped off the end,
>to keep consistent naming (WM_NAME, _NET_WM_NAME,
>_NET_WM_VISIBLE_NAME).  My implementation uses _NET_WM_VISIBLE_NAME.
>
I'd have no problem with that.

>_NET_WM_WINDOW_TYPE:  I think the _NET_WM_WINDOW_TYPE_TOOLBAR type should
>be simply _NET_WM_WINDOW_TYPE_TOOL.  Floating toolbars should still use
>this type, but it causes less confusion for windows that aren't toolbars,
>but which should be drawn with less decorations (a small color grid for a
>painting program probably shouldn't have full decorations/menus
>etc... just a small titlebar and a close button probably)
>

You have a point, but in this case  I feel the differences is too small to
bother changing it ! You're Ok with the rest of it ?

 >_NET_WM_STATE: I think this should be a bitfield.  We are
assuming that >all state value are boolean flags (since we have set/unset/toggle
>commands).  As extensions are made and things added, this will become
>quite a large property for storing nothing but boolean flags.  I suggest
>this:
>
>	_NET_WM_STATE, CARDINAL/32
>	Modal        = 1<<0
>	MaxVert      = 1<<1
>	MaxHoriz     = 1<<2
>	Shaded       = 1<<3
>
>Note that the state information has been trimmed down to include only
>useful state information (common UI elements).  These are simply hints

I don't mind whether this is a bitfield or a list (I'm not an implementor). But
if a bitfield is used extensions within that bitfield MUST be excluded the spec
should say:

<suggest>
Project specific extensions MUST NOT use currently unsed bits within bitfields
defined by this document. 2 projects could
use the same bits for differing purposes and future revisions of this
specification reserve otherwise unused bits.
Project specific extensions MUST be made so as not to hinder operation of
unextended implementations.
</suggest>

if a list is used then we could explicitly allow extensions here: (as these can
be detected as unknown by non-conforming implementations)
 <suggest>
project specific extension atoms MAY be added to this list. Such atoms MUST NOT
begin with the _NET prefix. Implementations detecting unknown atoms SHOULD
ignore them
</suggest>


 >
>The argument made against StaysOnTop also holds true for Sticky and
>SkipTaskbar.  These hints/states dictate policy, which should be done
>"through the window manager configuration".  If a particular
>implementation wants to use Sticky, SkipTaskbar or StaysOnTop, it should
>be done outside the _NET namespace (as I have been told *many* times).
>
>This is the part where people get pissed off.  Some feel that Sticky and
>SkipTaskbar are essential hints for working with the desktop.  If enough
>people Sticky and SkipTaskbar, then I feel that StaysOnTop should also be
>included.  Either we include nothing in the spec that describes policy
>(like Sticky, StaysOnTop and SkipTaskbar do) or we include all reasonable
>policy.

  > >Give me one good reason
that Sticky or SkipTaskbar should be included but >StaysOnTop should not.  One
dictates fixed position in the x/y >coordinates, the other fixed position in
the z coordinate. >

Personally I wouldn't mind if this went in the spec, but I do want to comment.

You're right that these 3 are similar, but you also point out the essential
difference - StaysOnTop is the z coordinate. The z coordinate is not currently
handled in the spec. Because it's a surprisingly contentious issue. I look at
ti like you - I wouldn't mind if it made it into the spec, probably because
the mental models we use for the desktop are similar.

Other people (and window managers) have a more complex layer based view of the
world. I've thought about this, but not really been able to figure out whether
there is a truly "right" approach. At the moment i think that it's horses for
courses. Layering has been dropped from this spec (but not excluded by it).

I feel that the right way to go is to leave it out of the spec (and address the
complex laying issus in a future version, and for KDE / Blackbox to cover the
omission *below* the C++ API level, using an approach which cooperates with
either solution above.

I feel it;s more constructive to do it that way at the moment.

Time to go out in the sun !

Julian

> --
>Bradley T. Hughes <bhughes trolltech com>
>Waldemar Thranes gt. 98B N-0175 Oslo, Norway
>Office: +47 21 60 48 92
>Mobile: +47 92 01 97 81
>
>
>_______________________________________________
>wm-spec-list mailing list
>wm-spec-list gnome org
>http://mail.gnome.org/mailman/listinfo/wm-spec-list
--




-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: rq0FRGJ1DjTYEHhAaloNQLnlz3dnlllL

iQA/AwUBOcynepJAqFTwwbGuEQIykwCfRZVoZrfsKxKajFlZhkQaHbSHXLQAoPEL
ClYHozsQbCYRMq7ioGLsv3nF
=sseh
-----END PGP SIGNATURE-----