On 4/17/06, Dan Winship <[EMAIL PROTECTED]> wrote: > > Anyway, you focused on the "making room for the window manager frame" > > part of the text, I would prefer to focus on the "The reference point > > of the window manager frame is placed at the location on the screen > > where the reference point of the client window was when the client > > requested the transition from Withdrawn state." By focusing on that > > part, the EWMH interpretation seems to fit just fine, to me. > > Oh... I get it now. 4.1.5 says: <snip> > And if the ICCCM meant what the EWMH claims, then I don't see where the > EWMH gets "If the Application requests a new position (x, y)..., the > Window Manager calculates a new reference point" from. What in the ICCCM > justifies computing a new reference point when the position changes, but > not when the size changes? (Yes, it would be ridiculous to NOT compute a > new reference point in that case, but IMHO that's just evidence that the > EWMH reading of 4.1.5 is wrong.)
What justifies the totally arbitrary choice of keeping the top-left corner of the client window fixed when getting a configure request that specifies a new size without specifying a new position? You pointed out that the EWMH made an arbitrary choice required to make sense of something not spelled out in the ICCCM, but you had to do the same thing. Stated differently: As pointed out by Joe, section 4.1.5 also says Client configure requests are interpreted by the window manager in the same manner as the initial window geometry mapped from the Withdrawn state, as described in section 4.1.2.3. But it can't be exactly the same, because (a) the application already has a previously known position and size when it sends a configure request, and (b) the configure request does not need to come with all of x, y, width, and height specified -- any combination of the 4 (or even none of the four) is allowed. How to handle the difference is left up to interpretation. The EWMH tries to honor the specified reference point (as a way of making room for the window decorations, if you want to think of it that way), with the obvious interpretation being that a new reference point must be computed when a new x & y are specified. You thought in terms of resizing keeping the top left pixel of the client window fixed and making room for the decorations when necessary. At least, that's the best I can make of it. I may still be missing something, though. Anyway, I'm still not seeing any inherent conflict between the ICCCM and the EWMH interpretation (nor of the ICCCM and what you suggest; it seems the ICCCM is just too vague) > > Given that window managers still don't agree, we do have to pick > > something and stick with it and will have to fix lots of apps & WMs. > > Yes, that's why I suggested the text about "Clients SHOULD always > include x and y in this case", because then it works regardless of how > the WM behaves. IOW, we declare the disputed functionality to be > deprecated and essentially undefined, since as you note, it is unlikely > that we will ever reach a state where all WMs implement it the same. If we can verify that there's a method that does work well with many/most non-EWMH-compliant WMs while still getting correct behavior under EWMH compliant ones, I see no problem with adding an implementational note section for application authors in this area of the spec. Further, declaring the resize-only behavior as deprecated may be fine, but I don't like the idea of declaring the resulting behavior to be undefined. Noting that there are still (possbily widespread) compliance problems is fine, but I think the EWMH definition of correct behavior should stand. > I guess that whether or not to change the recommended behavior is a > separate question from whether or not the recommendation actually > matches what the ICCCM says. But if it doesn't match the ICCCM, we > should at least update the text to not claim it does. :) True. :) But I really don't see where the two conflict; the EWMH just declares what it feels should be the correct interpretation, AFAICT. _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
