bug#7296: display-pixel-height not enough

bug#7296: display-pixel-height not enough

[Lennart Borgman]

If you want to know how much height there is available to display a
frame then display-pixel-height does not give you the information you
need. The taskbar (w32 name, I have no idea what it is called on other
platform) and other "bars" may have reserved some of the vertical
space.

I suggest adding something like display-available-pixel-height that
gives the actual height available for a frame that can be totally
visible.

(There is a similar problem for the width.)

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 28 Oct 2010 12:11:07 +0200
> Cc: 
> 
> I suggest adding something like display-available-pixel-height that
> gives the actual height available for a frame that can be totally
> visible.

Wouldn't it make more sense for display-pixel-height/width to return
the height available for display?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Thu, Oct 28, 2010 at 8:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Thu, 28 Oct 2010 12:11:07 +0200
>> Cc:
>>
>> I suggest adding something like display-available-pixel-height that
>> gives the actual height available for a frame that can be totally
>> visible.
>
> Wouldn't it make more sense for display-pixel-height/width to return
> the height available for display?

Probably. But there are perhaps also situation when you actually want
to get the dimension of the whole display. Perhaps not at the moment,
but with enhanced frame handling there could be.

For the moment I think you suggestion is best. It will be more
backward compatible than my initial suggestion.

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 28 Oct 2010 22:39:35 +0200
> Cc: 7296@debbugs.gnu.org
> 
> > Wouldn't it make more sense for display-pixel-height/width to return
> > the height available for display?
> 
> Probably. But there are perhaps also situation when you actually want
> to get the dimension of the whole display. Perhaps not at the moment,
> but with enhanced frame handling there could be.

What use-case could possibly want to know the dimensions that include
unusable portion?

> For the moment I think you suggestion is best. It will be more
> backward compatible than my initial suggestion.

Patches are welcome to implement that.  Or at least if someone could
explain how to find the dimensions of the unusable part, then someone
else could write the code with minimal effort.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 9:59 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Thu, 28 Oct 2010 22:39:35 +0200
>> Cc: 7296@debbugs.gnu.org
>>
>> > Wouldn't it make more sense for display-pixel-height/width to return
>> > the height available for display?
>>
>> Probably. But there are perhaps also situation when you actually want
>> to get the dimension of the whole display. Perhaps not at the moment,
>> but with enhanced frame handling there could be.
>
> What use-case could possibly want to know the dimensions that include
> unusable portion?

What do you mean? When someone wants to use the available height or
width. Is not that enough?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 9:59 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Thu, 28 Oct 2010 22:39:35 +0200
>> Cc: 7296@debbugs.gnu.org
>>
>> > Wouldn't it make more sense for display-pixel-height/width to return
>> > the height available for display?
>>
>> Probably. But there are perhaps also situation when you actually want
>> to get the dimension of the whole display. Perhaps not at the moment,
>> but with enhanced frame handling there could be.
>
> Patches are welcome to implement that.  Or at least if someone could
> explain how to find the dimensions of the unusable part, then someone
> else could write the code with minimal effort.

You can get the working area of the display by either calling
SystemParametersInfo with SPI_GETWORKAREA (for default monitor) or
GetMonitorInfo. See

http://msdn.microsoft.com/en-us/library/ms724947(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/dd144901(v=VS.85).aspx

The functions to change are x_display_pixel_height (and dito width) in w32term.c

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 29 Oct 2010 10:03:34 +0200
> Cc: 7296@debbugs.gnu.org
> 
> > What use-case could possibly want to know the dimensions that include
> > unusable portion?
> 
> What do you mean? When someone wants to use the available height or
> width. Is not that enough?

"Available" means it does not include portions that are not usable by
any window.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Eli Zaretskii skrev 2010-10-29 09.59:
>> From: Lennart Borgman<lennart.borgman@gmail.com>
>> Date: Thu, 28 Oct 2010 22:39:35 +0200
>> Cc: 7296@debbugs.gnu.org
>>
>>> Wouldn't it make more sense for display-pixel-height/width to return
>>> the height available for display?
>>
>> Probably. But there are perhaps also situation when you actually want
>> to get the dimension of the whole display. Perhaps not at the moment,
>> but with enhanced frame handling there could be.
>
> What use-case could possibly want to know the dimensions that include
> unusable portion?
>

They are not unusable.  One can create a frame that covers the 
taskbar/panel/whatever.

	Jan D.

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> Date: Fri, 29 Oct 2010 12:13:49 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Lennart Borgman <lennart.borgman@gmail.com>, 7296@debbugs.gnu.org
> 
> > What use-case could possibly want to know the dimensions that include
> > unusable portion?
> >
> 
> They are not unusable.  One can create a frame that covers the 
> taskbar/panel/whatever.

On MS-Windows?  If so, what is this bug report about?  It says:

  If you want to know how much height there is available to display a
  frame then display-pixel-height does not give you the information you
  need. The taskbar (w32 name, I have no idea what it is called on other
  platform) and other "bars" may have reserved some of the vertical
  space.

"Reserved" means, to me, that those parts cannot be used.  What am I
missing?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 12:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 29 Oct 2010 12:13:49 +0200
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> CC: Lennart Borgman <lennart.borgman@gmail.com>, 7296@debbugs.gnu.org
>>
>> > What use-case could possibly want to know the dimensions that include
>> > unusable portion?
>> >
>>
>> They are not unusable.  One can create a frame that covers the
>> taskbar/panel/whatever.
>
> On MS-Windows?  If so, what is this bug report about?  It says:
>
>  If you want to know how much height there is available to display a
>  frame then display-pixel-height does not give you the information you
>  need. The taskbar (w32 name, I have no idea what it is called on other
>  platform) and other "bars" may have reserved some of the vertical
>  space.
>
> "Reserved" means, to me, that those parts cannot be used.  What am I
> missing?

Perhaps nothing. On w32 maximized windows covers the area that are not
reserved by the taskbar (or other bars). I think this is the area that
we should return (as I have said before).

Maybe a bit of confusion comes in because the taskbar only reserves
this area on w32 if it is not automatically hidden.

bug#7296: display-pixel-height not enough

[Jan D.]

Lennart Borgman skrev 2010-10-29 14:28:
> On Fri, Oct 29, 2010 at 12:57 PM, Eli Zaretskii<eliz@gnu.org>  wrote:
>>> Date: Fri, 29 Oct 2010 12:13:49 +0200
>>> From: Jan Djärv<jan.h.d@swipnet.se>
>>> CC: Lennart Borgman<lennart.borgman@gmail.com>, 7296@debbugs.gnu.org
>>>
>>>> What use-case could possibly want to know the dimensions that include
>>>> unusable portion?
>>>>
>>> They are not unusable.  One can create a frame that covers the
>>> taskbar/panel/whatever.
>> On MS-Windows?  If so, what is this bug report about?  It says:
>>
>>   If you want to know how much height there is available to display a
>>   frame then display-pixel-height does not give you the information you
>>   need. The taskbar (w32 name, I have no idea what it is called on other
>>   platform) and other "bars" may have reserved some of the vertical
>>   space.
>>
>> "Reserved" means, to me, that those parts cannot be used.  What am I
>> missing?
> Perhaps nothing. On w32 maximized windows covers the area that are not
> reserved by the taskbar (or other bars). I think this is the area that
> we should return (as I have said before).
>
> Maybe a bit of confusion comes in because the taskbar only reserves
> this area on w32 if it is not automatically hidden.

I tried on W32 (Windows 7).  Maximizing a window does not use the space 
occupied by the taskbar, but there is no problem in creating a frame 
that does.  So an unmximized window can be taller than a maximized one.
On Gnome, the window manager won't let you do this, so when you set 
frame height/geometry to anything that might cover a panel, it adjusts 
the X window so it doesn't cover any panels.

     Jan D.


     Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 3:15 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> Lennart Borgman skrev 2010-10-29 14:28:
>>
>> On Fri, Oct 29, 2010 at 12:57 PM, Eli Zaretskii<eliz@gnu.org>  wrote:
>>>>
>>>> Date: Fri, 29 Oct 2010 12:13:49 +0200
>>>> From: Jan Djärv<jan.h.d@swipnet.se>
>>>> CC: Lennart Borgman<lennart.borgman@gmail.com>, 7296@debbugs.gnu.org
>>>>
>>>>> What use-case could possibly want to know the dimensions that include
>>>>> unusable portion?
>>>>>
>>>> They are not unusable.  One can create a frame that covers the
>>>> taskbar/panel/whatever.
>>>
>>> On MS-Windows?  If so, what is this bug report about?  It says:
>>>
>>>  If you want to know how much height there is available to display a
>>>  frame then display-pixel-height does not give you the information you
>>>  need. The taskbar (w32 name, I have no idea what it is called on other
>>>  platform) and other "bars" may have reserved some of the vertical
>>>  space.
>>>
>>> "Reserved" means, to me, that those parts cannot be used.  What am I
>>> missing?
>>
>> Perhaps nothing. On w32 maximized windows covers the area that are not
>> reserved by the taskbar (or other bars). I think this is the area that
>> we should return (as I have said before).
>>
>> Maybe a bit of confusion comes in because the taskbar only reserves
>> this area on w32 if it is not automatically hidden.
>
> I tried on W32 (Windows 7).  Maximizing a window does not use the space
> occupied by the taskbar, but there is no problem in creating a frame that
> does.  So an unmximized window can be taller than a maximized one.

Yes, but a w32 frame can be taller than a maximized window, but if the
taskbar is always on top, then part of it will be hidden behind the
taskbar. That is why I sent this bug report.

bug#7296: display-pixel-height not enough

[Drew Adams]

I have not been following this thread.  I'll just offer this, in case it helps.

In my library fit-frame.el, I take into account the value returned by function
`winmgr-display-available-pixel-bounds', which is apparently available on
MacIntosh (but maybe it's only available for Aquamacs - dunno). I believe that
that function takes into account various areas of the Mac screen that are
unavailable for Emacs display.  On that platform, my code uses the sizes
returned by that function instead of using `x-display-pixel-(height|width)',
when calculating the frame size.

David Reitter (Aquamacs) can tell you more about that function, if you're
interested.  If you're thinking of doing something similar for Windows, you
might want to contact him about it.

bug#7296: display-pixel-height not enough

[Stefan Monnier]

> On Gnome, the window manager won't let you do this, so when you set frame

You mean: Gnome's default window-manager doesn't let you do it.
Many other window-managers that you can use with Gnome let you do it.


        Stefan

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-10-29 15.38:

>
> Yes, but a w32 frame can be taller than a maximized window, but if the
> taskbar is always on top, then part of it will be hidden behind the
> taskbar. That is why I sent this bug report.

So Emacs must know if the taskbar is configured to always be on top also?
Or does the API functions take that into account.  How about taskbars that 
autohide?

	Jan D.

bug#7296: display-pixel-height not enough

[Stefan Monnier]

>> Yes, but a w32 frame can be taller than a maximized window, but if the
>> taskbar is always on top, then part of it will be hidden behind the
>> taskbar. That is why I sent this bug report.
> So Emacs must know if the taskbar is configured to always be on top also?
> Or does the API functions take that into account.  How about taskbars
> that autohide?

I suspect that once we find the way to get the relevant data (probably
it's somewhere in an X display property or something), we'll see that
this question is irrelevant (i.e. already solved by the window-manager).


        Stefan

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 7:37 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> Yes, but a w32 frame can be taller than a maximized window, but if the
>>> taskbar is always on top, then part of it will be hidden behind the
>>> taskbar. That is why I sent this bug report.
>> So Emacs must know if the taskbar is configured to always be on top also?
>> Or does the API functions take that into account.  How about taskbars
>> that autohide?
>
> I suspect that once we find the way to get the relevant data (probably
> it's somewhere in an X display property or something), we'll see that
> this question is irrelevant (i.e. already solved by the window-manager).

I provided the recipe for w32 in this thread, but I do not know
anything about X.

bug#7296: display-pixel-height not enough

[Jan D.]

Stefan Monnier skrev 2010-10-29 18:24:
>> On Gnome, the window manager won't let you do this, so when you set frame
> You mean: Gnome's default window-manager doesn't let you do it.
> Many other window-managers that you can use with Gnome let you do it.

Right, I only tested with Compiz and metacity.  Then again, it shows 
that the issue is more complicated than just replacing 
display-width/height with "available" width/height.

     Jan D.

bug#7296: display-pixel-height not enough

[Jan D.]

Stefan Monnier skrev 2010-10-29 19:37:
>>> Yes, but a w32 frame can be taller than a maximized window, but if the
>>> taskbar is always on top, then part of it will be hidden behind the
>>> taskbar. That is why I sent this bug report.
>> So Emacs must know if the taskbar is configured to always be on top also?
>> Or does the API functions take that into account.  How about taskbars
>> that autohide?
> I suspect that once we find the way to get the relevant data (probably
> it's somewhere in an X display property or something), we'll see that
> this question is irrelevant (i.e. already solved by the window-manager).

Some is in X propertys (the dimensions), but stuff like autohide is in 
GConf.  But that is just Gnome, there is also W32 and NextStep.

     Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Fri, Oct 29, 2010 at 9:57 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> Stefan Monnier skrev 2010-10-29 18:24:
>>>
>>> On Gnome, the window manager won't let you do this, so when you set frame
>>
>> You mean: Gnome's default window-manager doesn't let you do it.
>> Many other window-managers that you can use with Gnome let you do it.
>
> Right, I only tested with Compiz and metacity.  Then again, it shows that
> the issue is more complicated than just replacing display-width/height with
> "available" width/height.

In what way do you mean this shows that using the available
width/height will fail?

At least on w32 there are system API:s that directly gives you the
available width/height, taking the taskbar etc status into account.
Nothing more than that is needed.

Maybe you mean that sometimes you want the total display width/height?

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-10-29 22.05:
> On Fri, Oct 29, 2010 at 9:57 PM, Jan D.<jan.h.d@swipnet.se>  wrote:
>> Stefan Monnier skrev 2010-10-29 18:24:
>>>>
>>>> On Gnome, the window manager won't let you do this, so when you set frame
>>>
>>> You mean: Gnome's default window-manager doesn't let you do it.
>>> Many other window-managers that you can use with Gnome let you do it.
>>
>> Right, I only tested with Compiz and metacity.  Then again, it shows that
>> the issue is more complicated than just replacing display-width/height with
>> "available" width/height.
>
> In what way do you mean this shows that using the available
> width/height will fail?
>
> At least on w32 there are system API:s that directly gives you the
> available width/height, taking the taskbar etc status into account.
> Nothing more than that is needed.
>
> Maybe you mean that sometimes you want the total display width/height?

The bug does not include any explanation why the current situation is a 
problem or a use case that describes it.  So I don't know what this 
information is for.  If it is for making an Emacs frame as tall as it can be, 
that information is not it.

For example, on OSX you can not make an Emacs frame cover the top menu bar. 
But x-display-pixel-height includes it.  Yet there has been no complaints of 
anything breaking.  The only bad behaviour I know of is that Emacs initial 
frame may cover the Gnome panels on a small screen.

	Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> The bug does not include any explanation why the current situation is a
> problem or a use case that describes it.  So I don't know what this
> information is for.  If it is for making an Emacs frame as tall as it can
> be, that information is not it.


The Emacs frame can be partly hidden by the taskbar even when the
frame is the active w32 window if the height is set to the value
x-dsiplay-pixel-height (when for example the frame is aligned to the
top and the taskbar is at the bottom of the display), that is the
problem. Sorry if that was unclear.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-10-30 11.25:
> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>> The bug does not include any explanation why the current situation is a
>> problem or a use case that describes it.  So I don't know what this
>> information is for.  If it is for making an Emacs frame as tall as it can
>> be, that information is not it.
>
>
> The Emacs frame can be partly hidden by the taskbar even when the
> frame is the active w32 window if the height is set to the value
> x-dsiplay-pixel-height (when for example the frame is aligned to the
> top and the taskbar is at the bottom of the display), that is the
> problem. Sorry if that was unclear.

What package does this?

	Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sat, Oct 30, 2010 at 12:45 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-10-30 11.25:
>>
>> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>
>>> The bug does not include any explanation why the current situation is a
>>> problem or a use case that describes it.  So I don't know what this
>>> information is for.  If it is for making an Emacs frame as tall as it can
>>> be, that information is not it.
>>
>>
>> The Emacs frame can be partly hidden by the taskbar even when the
>> frame is the active w32 window if the height is set to the value
>> x-dsiplay-pixel-height (when for example the frame is aligned to the
>> top and the taskbar is at the bottom of the display), that is the
>> problem. Sorry if that was unclear.
>
> What package does this?

Every function that tries to maximize just height will do it.

bug#7296: display-pixel-height not enough

[Drew Adams]

> >> The Emacs frame can be partly hidden by the taskbar...
> >> if the height is ... x-dsiplay-pixel-height...
> Every function that tries to maximize just height will do it.

Can you give a recipe starting from emacs -Q?  How are you setting the frame
height?  Remember that the frame `height' parameter should not include the frame
area outside the space available for text, and it is measured in lines, not
pixels.

If you are setting the `height' parameter based on the `x-display-pixel-height'
then you should first subtract frame borders, horizontal scroll bar (well, there
isn't any, but the same method applies for the width), title bar, and (except on
Mac) menu bar.  And then convert pixels to char size -  the `height' parameter
is the number of text lines available at the frame's char size.


See http://www.emacswiki.org/emacs/frame-cmds.el for examples.  The code
compensates for MacIntosh thingies that reduce the available space, but it uses
`x-display-pixel-height' otherwise.  See `maximize-frame-vertically' and
`maximize-frame', which do not overlap the Windows task bar.

Something like this calculates the `height' frame parameter:

(- (/ (- (x-display-pixel-height)
         (* 2 (cdr (assq 'border-width (frame-parameters FRAME))))
         (frame-extra-pixels-height FRAME)
         window-mgr-title-bar-pixel-height
         (smart-tool-bar-pixel-height))
      (frame-char-height FRAME))
   (if (eq window-system 'mac)
       0 ; Menu bar for Carbon Emacs is not in the frame.
     (cdr (assq 'menu-bar-lines (frame-parameters FRAME)))))))

Where:

(defun frame-extra-pixels-height (frame)
  "Pixel diff between FRAME total height and its text area height."
  (- (frame-pixel-height frame)
     (* (frame-char-height frame) (frame-height frame))))

(defcustom window-mgr-title-bar-pixel-height
           (if (eq window-system 'mac) 22 27)
  "*Height of frame title bar provided by the window manager, in pixels.
You might alternatively call this constant the title-bar \"width\" or
\"thickness\".  There is no way for Emacs to determine this, so you
must set it."
  :type 'integer)

(defun smart-tool-bar-pixel-height (&optional frame)
  "Pixel height of Mac smart tool bar."
  (if (and (boundp 'mac-tool-bar-display-mode)
           (> (frame-parameter frame 'tool-bar-lines) 0))
      (if (eq mac-tool-bar-display-mode 'icons) 40 56)
    0))

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sat, Oct 30, 2010 at 5:06 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> The Emacs frame can be partly hidden by the taskbar...
>> >> if the height is ... x-dsiplay-pixel-height...
>> Every function that tries to maximize just height will do it.
>
> Can you give a recipe starting from emacs -Q?  How are you setting the frame
> height?  Remember that the frame `height' parameter should not include the frame
> area outside the space available for text, and it is measured in lines, not
> pixels.

Yes, but it is not interesting here directly. Please see
winsize-max-frame-height in winsize.el in nXhtml.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-10-30 16.05:
> On Sat, Oct 30, 2010 at 12:45 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> Lennart Borgman skrev 2010-10-30 11.25:
>>>
>>> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>    wrote:
>>>>
>>>> The bug does not include any explanation why the current situation is a
>>>> problem or a use case that describes it.  So I don't know what this
>>>> information is for.  If it is for making an Emacs frame as tall as it can
>>>> be, that information is not it.
>>>
>>>
>>> The Emacs frame can be partly hidden by the taskbar even when the
>>> frame is the active w32 window if the height is set to the value
>>> x-dsiplay-pixel-height (when for example the frame is aligned to the
>>> top and the taskbar is at the bottom of the display), that is the
>>> problem. Sorry if that was unclear.
>>
>> What package does this?
>
> Every function that tries to maximize just height will do it.

I'd rather see that those functions let the window manager do the job, i.e. 
set fullscreen to fullheight.  I don't know if W32/Nextstep has something 
similar, but if they do, that is a better solution to implement.

	Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sat, Oct 30, 2010 at 7:27 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-10-30 16.05:
>>
>> On Sat, Oct 30, 2010 at 12:45 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>
>>>
>>> Lennart Borgman skrev 2010-10-30 11.25:
>>>>
>>>> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>    wrote:
>>>>>
>>>>> The bug does not include any explanation why the current situation is a
>>>>> problem or a use case that describes it.  So I don't know what this
>>>>> information is for.  If it is for making an Emacs frame as tall as it
>>>>> can
>>>>> be, that information is not it.
>>>>
>>>>
>>>> The Emacs frame can be partly hidden by the taskbar even when the
>>>> frame is the active w32 window if the height is set to the value
>>>> x-dsiplay-pixel-height (when for example the frame is aligned to the
>>>> top and the taskbar is at the bottom of the display), that is the
>>>> problem. Sorry if that was unclear.
>>>
>>> What package does this?
>>
>> Every function that tries to maximize just height will do it.
>
> I'd rather see that those functions let the window manager do the job, i.e.
> set fullscreen to fullheight.  I don't know if W32/Nextstep has something
> similar, but if they do, that is a better solution to implement.


Then please tell those that do the window managers this ;-)

Maybe I am not explaining this very well since you said this. What the
window manager on w32 does is giving the size of the total display and
the work area of the display (through some API:s). We are currently
using the total display size. What we should do instead is using the
work area size. (I don't know if the total display size actually is
useful at all on w32 since it is not needed to maximize a window on
w32.)

Can you please tell me what is unclear? (I of course expect similar
solutions on other platforms.)

bug#7296: display-pixel-height not enough

[Jan Djärv]

30 okt 2010 kl. 19:41 skrev Lennart Borgman <lennart.borgman@gmail.com>:

> On Sat, Oct 30, 2010 at 7:27 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>> 
>> Lennart Borgman skrev 2010-10-30 16.05:
>>> 
>>> On Sat, Oct 30, 2010 at 12:45 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>> 
>>>> 
>>>> Lennart Borgman skrev 2010-10-30 11.25:
>>>>> 
>>>>> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>    wrote:
>>>>>> 
>>>>>> The bug does not include any explanation why the current situation is a
>>>>>> problem or a use case that describes it.  So I don't know what this
>>>>>> information is for.  If it is for making an Emacs frame as tall as it
>>>>>> can
>>>>>> be, that information is not it.
>>>>> 
>>>>> 
>>>>> The Emacs frame can be partly hidden by the taskbar even when the
>>>>> frame is the active w32 window if the height is set to the value
>>>>> x-dsiplay-pixel-height (when for example the frame is aligned to the
>>>>> top and the taskbar is at the bottom of the display), that is the
>>>>> problem. Sorry if that was unclear.
>>>> 
>>>> What package does this?
>>> 
>>> Every function that tries to maximize just height will do it.
>> 
>> I'd rather see that those functions let the window manager do the job, i.e.
>> set fullscreen to fullheight.  I don't know if W32/Nextstep has something
>> similar, but if they do, that is a better solution to implement.
> 
> 
> Then please tell those that do the window managers this ;-)
> 
> Maybe I am not explaining this very well since you said this. What the
> window manager on w32 does is giving the size of the total display and
> the work area of the display (through some API:s). We are currently
> using the total display size. What we should do instead is using the
> work area size. (I don't know if the total display size actually is
> useful at all on w32 since it is not needed to maximize a window on
> w32.)
> 
> Can you please tell me what is unclear? (I of course expect similar
> solutions on other platforms.)

Emacs should refrain from trying to maximize frames itself, because it is not so simple as you state to just replace one height with another. I know that W32 has some mechanism to maximize a window without fiddling with height and width. You should check if there is a similar way to maximize just height by asking the system to do it. All this pixel calculating will be wrong on some platform under some circumstances. 

It is why Emacs only does maximizing and fullscreen by delegering it to the window manager in X.

   Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sat, Oct 30, 2010 at 8:30 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> 30 okt 2010 kl. 19:41 skrev Lennart Borgman <lennart.borgman@gmail.com>:
>
>> On Sat, Oct 30, 2010 at 7:27 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>>
>>> Lennart Borgman skrev 2010-10-30 16.05:
>>>>
>>>> On Sat, Oct 30, 2010 at 12:45 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>>>
>>>>>
>>>>> Lennart Borgman skrev 2010-10-30 11.25:
>>>>>>
>>>>>> On Sat, Oct 30, 2010 at 9:28 AM, Jan Djärv<jan.h.d@swipnet.se>    wrote:
>>>>>>>
>>>>>>> The bug does not include any explanation why the current situation is a
>>>>>>> problem or a use case that describes it.  So I don't know what this
>>>>>>> information is for.  If it is for making an Emacs frame as tall as it
>>>>>>> can
>>>>>>> be, that information is not it.
>>>>>>
>>>>>>
>>>>>> The Emacs frame can be partly hidden by the taskbar even when the
>>>>>> frame is the active w32 window if the height is set to the value
>>>>>> x-dsiplay-pixel-height (when for example the frame is aligned to the
>>>>>> top and the taskbar is at the bottom of the display), that is the
>>>>>> problem. Sorry if that was unclear.
>>>>>
>>>>> What package does this?
>>>>
>>>> Every function that tries to maximize just height will do it.
>>>
>>> I'd rather see that those functions let the window manager do the job, i.e.
>>> set fullscreen to fullheight.  I don't know if W32/Nextstep has something
>>> similar, but if they do, that is a better solution to implement.
>>
>>
>> Then please tell those that do the window managers this ;-)
>>
>> Maybe I am not explaining this very well since you said this. What the
>> window manager on w32 does is giving the size of the total display and
>> the work area of the display (through some API:s). We are currently
>> using the total display size. What we should do instead is using the
>> work area size. (I don't know if the total display size actually is
>> useful at all on w32 since it is not needed to maximize a window on
>> w32.)
>>
>> Can you please tell me what is unclear? (I of course expect similar
>> solutions on other platforms.)
>
> Emacs should refrain from trying to maximize frames itself, because it is not so simple as you state to just replace one height with another.

I never said something about using those values for maximizing a
frame. You simply do not do it that way on w32.

> I know that W32 has some mechanism to maximize a window without fiddling with height and width. You should check if there is a similar way to maximize just height by asking the system to do it.

I told how to do this earlier in this thread. Or did not that message reach you?

> It is why Emacs only does maximizing and fullscreen by delegering it to the window manager in X.

Yes, it should do it the same way on w32, but you can not do it for
just height or just width on w32. (But you can set height (or width)
to the same value as it is with a maximized window.)

bug#7296: display-pixel-height not enough

[Stefan Monnier]

> It is why Emacs only does maximizing and fullscreen by delegering it
> to the window manager in X.

That's what I was alluding to: trying to figure out how autohide
taskbars work is madness.


        Stefan

bug#7296: display-pixel-height not enough

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 30 Oct 2010 11:25:44 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:

> The Emacs frame can be partly hidden by the taskbar even when the
> frame is the active w32 window if the height is set to the value
> x-dsiplay-pixel-height (when for example the frame is aligned to the
> top and the taskbar is at the bottom of the display), that is the
> problem. Sorry if that was unclear.

Some X11 window managers automatically adjust window position/size
(and send some notifications to the application) when it appears, so
it fits in the screen.  On Mac OS X, Cocoa also does similar
adjustments for document windows (roughly speaking, windows with title
bar), and Carbon doesn't.

Sometimes it gives a cleaner implementation to emulate such window
manager tasks at the application side for non-X11 ports.  For example,
the Mac port emulates maximized, fullwidth, fullheight, and fullscreen
windows, which are (EWMH-aware) window-manager tasks on X11, at the
application side.  Perhaps W32 can do similar things for window
position/size adjustments so the window height is automatically
shortened when the specified height exceeds the "available" height.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sun, Oct 31, 2010 at 5:13 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>
> Some X11 window managers automatically adjust window position/size
> (and send some notifications to the application) when it appears, so
> it fits in the screen.  On Mac OS X, Cocoa also does similar
> adjustments for document windows (roughly speaking, windows with title
> bar), and Carbon doesn't.
>
> Sometimes it gives a cleaner implementation to emulate such window
> manager tasks at the application side for non-X11 ports.  For example,
> the Mac port emulates maximized, fullwidth, fullheight, and fullscreen
> windows, which are (EWMH-aware) window-manager tasks on X11, at the
> application side.  Perhaps W32 can do similar things for window
> position/size adjustments so the window height is automatically
> shortened when the specified height exceeds the "available" height.

It is possible to do this on w32. (But it is a bit more complicated
than what I suggested here.)

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-10-30 20.59:
> On Sat, Oct 30, 2010 at 8:30 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> Emacs should refrain from trying to maximize frames itself, because it is
>> not so simple as you state to just replace one height with another.
>
> I never said something about using those values for maximizing a frame. You
> simply do not do it that way on w32.

Hmm, what was this about then:
"Every function that tries to maximize just height will do it".

>
>> I know that W32 has some mechanism to maximize a window without fiddling
>> with height and width. You should check if there is a similar way to
>> maximize just height by asking the system to do it.
>
> I told how to do this earlier in this thread. Or did not that message reach
> you?

Actually you did not.  You showed how to get display pixel sizes.  More is 
needed to correctly calculate the Emacs frame dimensions.
One of the advantage of letting the window manager do it is that it knows 
about multiple displays.  It seems that on w32 you have to figure out this 
yourself.  I guess the lowlevel API functions can be used so that fullwidth 
and fullheight works on w32.  That is so much better than letting lisp code 
calculate frame sizes.

>
>> It is why Emacs only does maximizing and fullscreen by delegering it to
>> the window manager in X.
>
> Yes, it should do it the same way on w32, but you can not do it for just
> height or just width on w32. (But you can set height (or width) to the same
> value as it is with a maximized window.)

	Jan D.

bug#7296: display-pixel-height not enough

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-10-31 05.13:
>
> Sometimes it gives a cleaner implementation to emulate such window
> manager tasks at the application side for non-X11 ports.  For example,
> the Mac port emulates maximized, fullwidth, fullheight, and fullscreen
> windows, which are (EWMH-aware) window-manager tasks on X11, at the
> application side.  Perhaps W32 can do similar things for window
> position/size adjustments so the window height is automatically
> shortened when the specified height exceeds the "available" height.
>

When you say the "Mac port" I guess you mean your port, not Emacs trunk 
compiled for OSX?  We should put this in the trunk also.

	Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Sun, Oct 31, 2010 at 11:51 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>>> Emacs should refrain from trying to maximize frames itself, because it is
>>> not so simple as you state to just replace one height with another.
>>
>> I never said something about using those values for maximizing a frame.
>> You simply do not do it that way on w32.
>
> Hmm, what was this about then:
> "Every function that tries to maximize just height will do it".

Ah, I see. A misunderstanding. On w32 the window manager can maximize
a window, but it can't just maximize the height and not the width.
"Maximized" on w32 is a state where the window is not moveable and the
window occupies the working area of the display (taking into account
how the taskbars are configured).

>>> I know that W32 has some mechanism to maximize a window without fiddling
>>> with height and width. You should check if there is a similar way to
>>> maximize just height by asking the system to do it.
>>
>> I told how to do this earlier in this thread. Or did not that message
>> reach
>> you?
>
> Actually you did not.  You showed how to get display pixel sizes.  More is
> needed to correctly calculate the Emacs frame dimensions.

Some misunderstanding. I told the API:s for getting the size of the work area.

> One of the advantage of letting the window manager do it is that it knows
> about multiple displays.  It seems that on w32 you have to figure out this
> yourself.  I guess the lowlevel API functions can be used so that fullwidth
> and fullheight works on w32.  That is so much better than letting lisp code
> calculate frame sizes.

I do not understand what you mean. I gave references to the API:s to
do exactly this. What is unclear?

bug#7296: display-pixel-height not enough

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 31 Oct 2010 11:46:58 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:

>> Perhaps W32 can do similar things for window position/size
>> adjustments so the window height is automatically shortened when
>> the specified height exceeds the "available" height.

> It is possible to do this on w32. (But it is a bit more complicated
> than what I suggested here.)

As Drew and Jan pointed out, appropriate calculation at the Lisp level
is not that simple and requires platform-specific adjustment even if
we have a primitive for available pixel width/height.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 1:10 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Sun, 31 Oct 2010 11:46:58 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:
>
>>> Perhaps W32 can do similar things for window position/size
>>> adjustments so the window height is automatically shortened when
>>> the specified height exceeds the "available" height.
>
>> It is possible to do this on w32. (But it is a bit more complicated
>> than what I suggested here.)
>
> As Drew and Jan pointed out, appropriate calculation at the Lisp level
> is not that simple and requires platform-specific adjustment even if
> we have a primitive for available pixel width/height.

Yes, but it is not possible at all without the display working area size.

Could we, as a first step, do as Eli suggested, i.e. let
display-pixel-height/width return the working area size instead of the
total display size? Is there any reason not to do this now?

bug#7296: display-pixel-height not enough

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 1 Nov 2010 01:24:55 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:

> Could we, as a first step, do as Eli suggested, i.e. let
> display-pixel-height/width return the working area size instead of
> the total display size? Is there any reason not to do this now?

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.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 1:56 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Mon, 1 Nov 2010 01:24:55 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:
>
>> Could we, as a first step, do as Eli suggested, i.e. let
>> display-pixel-height/width return the working area size instead of
>> the total display size? Is there any reason not to do this now?
>
> 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)?

And how do you plan to implement the shortening without knowing what
the limits are?

bug#7296: display-pixel-height not enough

[YAMAMOTO Mitsuharu]

>>>>> 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.

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.  Also we
need to consider multiple-monitor environment.

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.

> And how do you plan to implement the shortening without knowing what
> the limits are?

Of course they are used, but just internally.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#7296: display-pixel-height not enough

[Jason Rumney]

On 01/11/2010 09:26, Lennart Borgman wrote:
> 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 recall some years ago seeing some lisp code that wanted to calculate 
the real dpi of the display, as opposed to what is reported by the 
system (which can be influenced by user settings for font size, or in 
some cases hardcoded to 72, 96 or other common values).

The change you are proposing would be incompatible with that way of 
using display-pixel-height.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 8:44 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 01/11/2010 09:26, Lennart Borgman wrote:
>>
>> 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 recall some years ago seeing some lisp code that wanted to calculate the
> real dpi of the display, as opposed to what is reported by the system (which
> can be influenced by user settings for font size, or in some cases hardcoded
> to 72, 96 or other common values).
>
> The change you are proposing would be incompatible with that way of using
> display-pixel-height.

Why would it be incompatible?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

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.)

bug#7296: display-pixel-height not enough

[Jan Djärv]

2010-10-31 13:46, Lennart Borgman skrev:
> On Sun, Oct 31, 2010 at 11:51 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>
>>>> I know that W32 has some mechanism to maximize a window without fiddling
>>>> with height and width. You should check if there is a similar way to
>>>> maximize just height by asking the system to do it.
>>>
>>> I told how to do this earlier in this thread. Or did not that message
>>> reach
>>> you?
>>
>> Actually you did not.  You showed how to get display pixel sizes.  More is
>> needed to correctly calculate the Emacs frame dimensions.
>
> Some misunderstanding. I told the API:s for getting the size of the work area.

Whis is not the same thing at all.  Making an Emacs frame maximized in height 
from lisp code is so much more, as others have told you.  And you need a sure 
way to do this for all platforms and for all window managers if it is to be 
any good at all.


>
>> One of the advantage of letting the window manager do it is that it knows
>> about multiple displays.  It seems that on w32 you have to figure out this
>> yourself.  I guess the lowlevel API functions can be used so that fullwidth
>> and fullheight works on w32.  That is so much better than letting lisp code
>> calculate frame sizes.
>
> I do not understand what you mean. I gave references to the API:s to
> do exactly this. What is unclear?

Nothing is unclear.  It is just that you want to change one value for another 
with unforseen consequences for various platforms instead of solving the 
problem, making a window maximized on height.

If we change display-height, it will cause problems on other platforms, X11 
comes to mind, where autohide and panel always on top is something the window 
manager keeps track of.  If we only do this for W32 display height means two 
different things.  Also as has been pointed out, stuff like calculating DPI 
will be wrong.

	Jan D.

bug#7296: display-pixel-height not enough

[Jan Djärv]

2010-11-01 11:20, Lennart Borgman skrev:
> On Mon, Nov 1, 2010 at 3:46 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp>  wrote:

>> 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?

What documentation says that display-pixel-height/width is 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.)

No, that way lies madness.  If you really feel you must fiddle with pixels 
yourself introduce new variables/functions.

	Jan D.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 12:37 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 2010-10-31 13:46, Lennart Borgman skrev:
>>
>> On Sun, Oct 31, 2010 at 11:51 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>>>> I know that W32 has some mechanism to maximize a window without
>>>>> fiddling
>>>>> with height and width. You should check if there is a similar way to
>>>>> maximize just height by asking the system to do it.
>>>>
>>>> I told how to do this earlier in this thread. Or did not that message
>>>> reach
>>>> you?
>>>
>>> Actually you did not.  You showed how to get display pixel sizes.  More
>>> is
>>> needed to correctly calculate the Emacs frame dimensions.
>>
>> Some misunderstanding. I told the API:s for getting the size of the work
>> area.
>
> Whis is not the same thing at all.  Making an Emacs frame maximized in
> height from lisp code is so much more, as others have told you.  And you
> need a sure way to do this for all platforms and for all window managers if
> it is to be any good at all.

Maybe you are misunderstanding part what I am saying. However I might
have misunderstood something here too. Some clarifications:

- I am speaking mainly about the w32 platform because I know how the
window manager behaves there. I know nothing about the window manages
on other platforms. So please just add suggestions for other platforms
too.

- On w32 display-pixel-height currently returns the total display size
instead of the work area (i.e. the area that the window managers
thinks fit for normally handled windows). I can't see that we have any
use of the total display size on w32. (Though Jason said there might
be. I asked him to clarify this.)

- On w32 you do not maximize a window by setting the size. (I do not
know how this is handled currently in the unpatched Emacs but I
changed it several years ago in my patched Emacs.)

- My initial proposal was to add new functions for the work area size.
However Eli suggested changing display-pixel-height instead on w32 (if
I did not misunderstood Eli). I don't care much which way we do it,
but I think we should have functions to get the size of the work area.


> Nothing is unclear.  It is just that you want to change one value for
> another with unforseen consequences for various platforms instead of solving
> the problem, making a window maximized on height.

I am trying to avoid bad consequences, of course (without beeing bug
back compatible).

You may want the max width or height without immediately setting them.


> If we change display-height, it will cause problems on other platforms, X11
> comes to mind, where autohide and panel always on top is something the
> window manager keeps track of.  If we only do this for W32 display height
> means two different things.  Also as has been pointed out, stuff like
> calculating DPI will be wrong.

Ok. On w32 the window manager also keeps track of those things (with
the API:s I pointed to, but not with the current implementation of
display-pixel-height/width).

So then it looks best to me to add new functions for the work area
size. What do you think of that?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 12:40 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 2010-11-01 11:20, Lennart Borgman skrev:
>>
>> On Mon, Nov 1, 2010 at 3:46 AM, YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp>  wrote:
>
>>> 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?
>
> What documentation says that display-pixel-height/width is that?

Actually I think the documentation is unclear. It should tell whether
it returns the total display size or the work area size. Maybe we
should start there?


>>> 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.)
>
> No, that way lies madness.  If you really feel you must fiddle with pixels
> yourself introduce new variables/functions.

It is not clear to me which way is best. Does not that depend on if
the current use of those functions mostly are written for total size
or work area size?

bug#7296: display-pixel-height not enough

[Drew Adams]

> >> Could we, as a first step, do as Eli suggested, i.e. let
> >> display-pixel-height/width return the working area size instead of
> >> the total display size? Is there any reason not to do this now?
> 
> 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)?

It's not that one or the other is better; it's that they are different.  If you
change the meaning and return value of an existing function then you break
existing code.  If you want to add an additional function that returns some
other value that you find more useful, that's one thing.  Proposing to change
the existing function is something else again.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 4:09 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> Could we, as a first step, do as Eli suggested, i.e. let
>> >> display-pixel-height/width return the working area size instead of
>> >> the total display size? Is there any reason not to do this now?
>>
>> 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)?
>
> It's not that one or the other is better; it's that they are different.  If you
> change the meaning and return value of an existing function then you break
> existing code.  If you want to add an additional function that returns some
> other value that you find more useful, that's one thing.  Proposing to change
> the existing function is something else again.

There is no clear description of what display-pixel-height currently
returns. So how do we know how it is currently used?

It looks like it is difficult to get this information, but as I said
the current return value must be documented. I suggest that we just
change the doc string and says that it returns value for the total
display.

And in addition to that it would probably be good to have the
"opposite" function too. At least I need it.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-11-01 13.00:
>
> So then it looks best to me to add new functions for the work area
> size. What do you think of that?

That is better, it can't break existing code.  But implementing 
fullheight/width on w32 is still better.

	Jan D.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Lennart Borgman skrev 2010-11-01 13.04:
> On Mon, Nov 1, 2010 at 12:40 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>> 2010-11-01 11:20, Lennart Borgman skrev:
>>>
>>> On Mon, Nov 1, 2010 at 3:46 AM, YAMAMOTO Mitsuharu
>>> <mituharu@math.s.chiba-u.ac.jp>    wrote:
>>
>>>> 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?
>>
>> What documentation says that display-pixel-height/width is that?
>
> Actually I think the documentation is unclear. It should tell whether
> it returns the total display size or the work area size. Maybe we
> should start there?
>

"Return the height of DISPLAY's screen in pixels."

That is totally clear to me.  This is X terms, and there is no room for 
interpretation.  It means the total height, and nothing else.

	Jan D.

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> Date: Mon, 01 Nov 2010 20:38:59 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: "7296@debbugs.gnu.org" <7296@debbugs.gnu.org>
> 
> But implementing fullheight/width on w32 is still better.

If you mean this:

  (w32-send-sys-command #xf030)

then it's already implemented.

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Mon, Nov 1, 2010 at 9:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 01 Nov 2010 20:38:59 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Cc: "7296@debbugs.gnu.org" <7296@debbugs.gnu.org>
>>
>> But implementing fullheight/width on w32 is still better.
>
> If you mean this:
>
>  (w32-send-sys-command #xf030)
>
> then it's already implemented.

This does not allow you to use just the max height or width.

bug#7296: display-pixel-height not enough

[Jan Djärv]

Eli Zaretskii skrev 2010-11-01 21.26:
>> Date: Mon, 01 Nov 2010 20:38:59 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: "7296@debbugs.gnu.org"<7296@debbugs.gnu.org>
>>
>> But implementing fullheight/width on w32 is still better.
>
> If you mean this:
>
>    (w32-send-sys-command #xf030)
>
> then it's already implemented.

That does maximize width and height? I mean maximize height only, maximize 
width only and fullscreen.  I think those are missing.

	Jan D.

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> Date: Mon, 01 Nov 2010 22:11:32 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: lennart.borgman@gmail.com, 7296@debbugs.gnu.org
> 
> >    (w32-send-sys-command #xf030)
> >
> > then it's already implemented.
> 
> That does maximize width and height?

Yes.

> I mean maximize height only, maximize width only and fullscreen.  I
> think those are missing.

I suspect they cannot be implemented with any degree of accuracy, not
with an arbitrary wm.  But that's me.

bug#7296: display-pixel-height not enough

[Jason Rumney]

On 02/11/2010 05:40, Eli Zaretskii wrote:

>> I mean maximize height only, maximize width only and fullscreen.  I
>> think those are missing.
>>      
> I suspect they cannot be implemented with any degree of accuracy, not
> with an arbitrary wm.  But that's me.
>    

They are already implemented for X, which is the only platform that may 
have an arbitrary wm. Making them work on Windows is fairly trivial 
using the system parameters that Lennart mentioned (and which we already 
use for ensuring tooltips remain visible and on a single screen).

bug#7296: display-pixel-height not enough

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 1 Nov 2010 11:20:16 +0100, Lennart Borgman <lennart.borgman@gmail.com> said:

>> 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.)

It seems that the current W32 code already does some kind of "window
manager emulation" with respect to the window size ("Force width and
height of client area to be exact multiples of the character cell
dimensions.") in response to WM_WINDOWPOSCHANGING.  I have no
experience of W32 programming, but I guess adding some code that
restricts width/height to the available area to this part would work.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> Date: Tue, 02 Nov 2010 09:09:18 +0800
> From: Jason Rumney <jasonr@gnu.org>
> Cc: 
> 
> On 02/11/2010 05:40, Eli Zaretskii wrote:
> 
> >> I mean maximize height only, maximize width only and fullscreen.  I
> >> think those are missing.
> >>      
> > I suspect they cannot be implemented with any degree of accuracy, not
> > with an arbitrary wm.  But that's me.
> >    
> 
> They are already implemented for X

Where?  Maybe I misunderstood, but my impression from this discussion
was that they aren't and actually the need for them and their utility
are debatable.

bug#7296: display-pixel-height not enough

[Jan D.]

Eli Zaretskii skrev 2010-11-02 05:01:
>> Date: Tue, 02 Nov 2010 09:09:18 +0800
>> From: Jason Rumney<jasonr@gnu.org>
>> Cc:
>>
>> On 02/11/2010 05:40, Eli Zaretskii wrote:
>>
>>>> I mean maximize height only, maximize width only and fullscreen.  I
>>>> think those are missing.
>>>>
>>> I suspect they cannot be implemented with any degree of accuracy, not
>>> with an arbitrary wm.  But that's me.
>>>
>> They are already implemented for X
> Where?  Maybe I misunderstood, but my impression from this discussion
> was that they aren't and actually the need for them and their utility
> are debatable.
>

In xterm.c, do_ewmh_fullscreen.  I don't know why you say they are 
debatable, it is the only way to correctly make an Emacs frame full 
height or full width or fullscreen or maximized.  It lets the WM do the 
job, so Emacs doesn't need to count pixels and panels and taskbars and 
autohide and whatever.

     Jan D.

bug#7296: display-pixel-height not enough

[Stefan Monnier]

>> 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)?
> It's not that one or the other is better; it's that they
> are different.

Indeed, and it goes even further: if someone cares about the workarea
enough to want to know its height and width, she may also want to know
its *position* on the screen.  So I'm not sure convinced that
adding display-pixel-work-height and display-pixel-work-width would be
sufficient either.


        Stefan

bug#7296: display-pixel-height not enough

[Eli Zaretskii]

> Date: Tue, 02 Nov 2010 14:25:49 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> Cc: 
> 
> >> They are already implemented for X
> > Where?  Maybe I misunderstood, but my impression from this discussion
> > was that they aren't and actually the need for them and their utility
> > are debatable.
> >
> 
> In xterm.c, do_ewmh_fullscreen.  I don't know why you say they are 
> debatable

Like I said, I probably misunderstood.  It's easy, what with all the
bikeshedding in this thread.

> it is the only way to correctly make an Emacs frame full 
> height or full width or fullscreen or maximized.  It lets the WM do the 
> job, so Emacs doesn't need to count pixels and panels and taskbars and 
> autohide and whatever.

I think the only practical way of doing the same on Windows is to
exclude the area reserved for the task bar.  It could be that in a few
rare cases this will produce less pixels than are strictly possible.
So what are the objections to this (my original suggestion) at this
point?  To be 100% clear, I suggest:

  . on w32, return the dimensions sans the reserved part(s)
  . on other GUI platforms, no change from the current behavior

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Tue, Nov 2, 2010 at 3:24 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> 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)?
>> It's not that one or the other is better; it's that they
>> are different.
>
> Indeed, and it goes even further: if someone cares about the workarea
> enough to want to know its height and width, she may also want to know
> its *position* on the screen.  So I'm not sure convinced that
> adding display-pixel-work-height and display-pixel-work-width would be
> sufficient either.

Yes, you are right it is not enough. On w32 you get the values for the
workarea as a rectangle with the functions I pointed to. Maybe we
should have a function that return a list with the work area values
(top left right bottom) instead?

bug#7296: display-pixel-height not enough

[Lennart Borgman]

On Tue, Nov 2, 2010 at 3:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> it is the only way to correctly make an Emacs frame full
>> height or full width or fullscreen or maximized.  It lets the WM do the
>> job, so Emacs doesn't need to count pixels and panels and taskbars and
>> autohide and whatever.
>
> I think the only practical way of doing the same on Windows is to
> exclude the area reserved for the task bar.  It could be that in a few
> rare cases this will produce less pixels than are strictly possible.
> So what are the objections to this (my original suggestion) at this
> point?  To be 100% clear, I suggest:
>
>  . on w32, return the dimensions sans the reserved part(s)
>  . on other GUI platforms, no change from the current behavior

Please see Stefan's objection and my reply to that. In addition to
that I suggest that we clearly document that
display-pixel-height/width returns the total size (even if that seems
self evident to some here).

bug#7296: display-pixel-height not enough

[Stefan Monnier]

> Yes, you are right it is not enough. On w32 you get the values for the
> workarea as a rectangle with the functions I pointed to. Maybe we
> should have a function that return a list with the work area values
> (top left right bottom) instead?

That would be more useful, yes.  Not sure if it would be useful at all,
in general, tho: e.g. I don't know if such data can be obtained for X11
and/or *Step.
If not, then maybe this data should be kept internal and only the
fullheight and fullwidth thingies should make use of it (under w32).


        Stefan

bug#7296: display-pixel-height not enough

[Drew Adams]

> So what are the objections to this (my original suggestion) at this
> point?  To be 100% clear, I suggest:
> 
>   . on w32, return the dimensions sans the reserved part(s)
>   . on other GUI platforms, no change from the current behavior

Hardly 100% clear.  Are you talking about changing the behavior of
`display-pixel-height' or defining a new function to do that?

You refer to your "original suggestion".  Do you mean this suggestion:

>> Wouldn't it make more sense for display-pixel-height/width
>> to return the height available for display?

and

>> "Available" means it does not include portions that are not
>> usable by any window.

If so, that sounds like a proposal to change the meaning/behavior of the
function.  I, for one, object to that (see the thread).

I have no objection to your defining a new function that does that (or anything
else), however.

bug#7296: display-pixel-height not enough

[Jan Djärv]

2010-11-02 15:53, Eli Zaretskii skrev:
>> Date: Tue, 02 Nov 2010 14:25:49 +0100
>> From: "Jan D."<jan.h.d@swipnet.se>
>> Cc:
>>
>>>> They are already implemented for X
>>> Where?  Maybe I misunderstood, but my impression from this discussion
>>> was that they aren't and actually the need for them and their utility
>>> are debatable.
>>>
>>
>> In xterm.c, do_ewmh_fullscreen.  I don't know why you say they are
>> debatable
>
> Like I said, I probably misunderstood.  It's easy, what with all the
> bikeshedding in this thread.
>
>> it is the only way to correctly make an Emacs frame full
>> height or full width or fullscreen or maximized.  It lets the WM do the
>> job, so Emacs doesn't need to count pixels and panels and taskbars and
>> autohide and whatever.
>
> I think the only practical way of doing the same on Windows is to
> exclude the area reserved for the task bar.  It could be that in a few
> rare cases this will produce less pixels than are strictly possible.
> So what are the objections to this (my original suggestion) at this
> point?  To be 100% clear, I suggest:
>
>    . on w32, return the dimensions sans the reserved part(s)
>    . on other GUI platforms, no change from the current behavior

Besides the position thing, it makes it impossible do some tasks, calculating 
dpi was mentioned.

But the biggest objection is that users will find that on w32 they can create 
a frame that doesn't cover the taskbar.  But when they run the same lisp code 
on X, it does cover the Gnome/KDE panels.

	Jan D.

bug#7296: display-pixel-height not enough

[Drew Adams]

For some reason, it seems this message never made it to the BUGS list.  Sending
again. 

-----Original Message-----
From: Drew Adams Sent: Monday, November 01, 2010 11:36 AM
To: 'Lennart Borgman' Cc: 'YAMAMOTO Mitsuharu'; '7296@debbugs.gnu.org'

> > It's not that one or the other is better; it's that they 
> > are different.  If you change the meaning and return value
> > of an existing function then you break existing code.  If
> > you want to add an additional function that returns some
> > other value that you find more useful, that's one thing.  
> > Proposing to change the existing function is something else again.
> 
> There is no clear description of what display-pixel-height currently
> returns. So how do we know how it is currently used?

I know how I currently use it (and I pointed you to the code).  And my code has
been been used by others as well (it is included in Aquamacs, AFAIK).  It seems
to DTRT.

How did I find out what `display-pixel-height' returns?  Well, I tried it out,
for one thing.  And I read the doc string, which I found clear enough.

You cannot change the behavior of something radically just because you feel the
doc is not precise enough.  Imprecise doc is not a license to change up to down
or whole to part.

These functions have been around quite a while.  If you want something
incompatibly different then create a new function.  Do not try to turn the
existing functions upside down.

> It looks like it is difficult to get this information, but as I said
> the current return value must be documented. I suggest that we just
> change the doc string and says that it returns value for the total
> display.

I'm all for clear doc.  But in this case I don't see the difference.  If I tell
you that function `foobar' returns the diameter of its input circle, is that
different from telling you that it returns the "total" diameter?

Is the length of your bicycle different from the length of your whole bicycle?
With no qualifier I think that the entire display is understood implicitly.

> And in addition to that it would probably be good to have the
> "opposite" function too. At least I need it.

It is in the doc of your new, partial-height function that you would state that
it returns the height of only part of the (total) display.

In sum, you are looking for a different behavior from what
`display-pixel-height' provides.  For that you should be asking for a different
function - exactly as you would do if you wanted to change the return units from
pixels to lines.

This is not a doc issue IMO, and IMO it is not a problem with
`display-pixel-height'.  What you are asking for is (or should be) a new,
additional function.

bug#7296: display-pixel-height not enough

[martin rudalics]

 > If you want to know how much height there is available to display a
 > frame then display-pixel-height does not give you the information you
 > need. The taskbar (w32 name, I have no idea what it is called on other
 > platform) and other "bars" may have reserved some of the vertical
 > space.

`display-monitor-attributes-list' should provide all the information you
need now.  Unless something was left out please consider closing this
bug.

Thanks, martin

bug#7296: display-pixel-height not enough

[martin rudalics]

> `display-monitor-attributes-list' should provide all the information you
> need now.  Unless something was left out please consider closing this
> bug.

Bug closed.

Thanks, martin