[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


   > I'm not so sure it's a good idea to remove the obsolete x, y, width, and
   > height slots [of wm-size-hints].  What if there's a window manager out
   > there that uses them?  It's a tradeoff between backwards compatibility and
   > reduction of confusion.  Perhaps having them there but not exporting them
   > would be a good compromise.

You're right.  These slots should be retained and their accessors should be kept
internal.  At first, I thought these fields were being removed from the stored
format of the WM_NORMAL_HINTS property, in which case the incompatibility would
be inevitable.  However, I was wrong.

   > I don't like the idea of changing the defaults for user-specified to nil.
   > Mainly because it's a fairly arbitrary choice -- maybe the user specifically
   > asked for it and maybe he didn't -- there isn't a clearcut way to tell like
   > there is with normal C programs.  Basically I oppose the change because it's
   > a backwards incompatibility.

The rationale for user-specified-position/size defaulting to nil is based on an

	The true arbiter of window geometry is the interactive user.

and two assertions:

	1. The default case is the case involving the least effort by the

	2. A client that acquires initial window geometry from the interactive
	   user is doing more work than one that doesn't.

When user-specified-position/size are true, the window manager is expected to
treat them just as if they had been entered interactively by the user.  This is
a claim that the client has already done the work to acquire initial window
geometry (e.g.  from the command line, from a user interaction, from a resource
file, etc.).  Clients which make this claim but do not actually do the work have
always been in error (see axiom).  I don't understand the statement that "there
isn't a clearcut way to tell like there is with normal C programs".

I suspect that the effect of this "incompatibility" will mainly be to expose
erroneous clients.

   > Are
   > you planning to implement the above changes?  Is LaMott?  

Not immediately.  My current commitments won't permit me to work on the
implementation for some time.  Probably implementation should await ratification
of ICCCM following the current public review.  I'm interested from folks if they
want to help with the implementation and when.