bug#7296: display-pixel-height not enough

[Lennart Borgman <lennart.borgman@gmail.com>]

On Mon, Nov 1, 2010 at 3:46 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Mon, 1 Nov 2010 02:26:44 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:
>
>>> I'd rather suggest implementing "some of window manager emulations"
>>> (i.e., shortening width/height if specified one exceeds available
>>> one, and possibly maximized, fullwidth, and fullheight for the
>>> fullscreen frame parameter) on W32 and seeing if the proposed
>>> function is still necessary, before introducing incompatibility or
>>> new primitives.
>
>> In what way can the working display area size in pixels be
>> incompatible? And why is using the current total display area size
>> better (and more compatible)?
>
> I mean compatibility with previous versions.

But is not the current version of display-pixel-height/width kind of
bogus since it does not give the actual useable working area?

And haven't we made a decision to try to avoid beeing "bug-back-compatible"?


> It looks unnatural that we can't know the offsets of the available
> display area, if we are to have primitives to get its size.

Yes, we can add functions for that too. There is a lot of small
details to consider here actually, but I think doing the change I
suggested (or rather Eli) is the best first step.


> Also we
> need to consider multiple-monitor environment.

Yes. (I told about the function to use for w32 for that.)


> Anyway, no matter how you try to specify position/size in detail at
> the Lisp level, additional constraints are forced by the window
> manager on X11 and the Cocoa framework on Mac OS X.  And such
> additional constraints actually solve the problem in your motivating
> example in the first place.  It looks more natural to implement such
> constraints in the remaining environment, i.e., W32.

I see. Yes, maybe. I will have a look at it. (But I would still
suggest changing display-pixel-height/width.)