Proposed function: x-display-usable-bounds

Proposed function: x-display-usable-bounds

[Adrian Robert]

Hi,

On the Mac platform both the Carbon and Cocoa ports face the problem
of determining where on the display to place new frames.  For this it
is helpful not just to know the overall dimensions of the display
(x-display-pixel-width,height) but also the portion of the display
that is not obscured/reserved for the dock and menubar.  I assume this
issue comes up as well on Windows (task bar) and on X desktops such as
Gnome or KDE.

The Carbon port was defining its own function to return (top left
width height) for the usable screen area.  Since it seems relevant for
all platforms, it would seem appropriate to name this function with an
x- prefix, e.g., x-display-usable-bounds, and define it for all
platforms.  As a placeholder implementation, a list (0 0
x-display-pixel-width x-display-pixel-height) could be returned.  See
the thread below for the current Carbon and Cocoa implementations.

http://sourceforge.net/mailarchive/forum.php?thread_name=2CE05DE2-B276-4F80-918B-9C1A28DF169A%40gmail.com&forum_name=emacs-app-dev-

Re: Proposed function: x-display-usable-bounds

[Jan Djärv]

Adrian Robert skrev:
> Hi,
> 
> On the Mac platform both the Carbon and Cocoa ports face the problem
> of determining where on the display to place new frames.  For this it
> is helpful not just to know the overall dimensions of the display
> (x-display-pixel-width,height) but also the portion of the display
> that is not obscured/reserved for the dock and menubar.  I assume this
> issue comes up as well on Windows (task bar) and on X desktops such as
> Gnome or KDE.
> 

Gnome and KDE follow the Extended windowmanager hints specification.  It 
defines a property on the root window which gives the "usable" display area.

http://freedesktop.org/wiki/Specifications/wm-spec

The implementation for KDE and Gnome could easily be done in elisp.  Does your 
patch handle multiple desktops/screens?

> The Carbon port was defining its own function to return (top left
> width height) for the usable screen area.  Since it seems relevant for
> all platforms, it would seem appropriate to name this function with an
> x- prefix, e.g., x-display-usable-bounds, and define it for all
> platforms.  As a placeholder implementation, a list (0 0
> x-display-pixel-width x-display-pixel-height) could be returned.  See
> the thread below for the current Carbon and Cocoa implementations.
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=2CE05DE2-B276-4F80-918B-9C1A28DF169A%40gmail.com&forum_name=emacs-app-dev-
> 

ERROR

Either your mailing list name was misspelled or the list you specified does 
not exist. If you believe this message to be in error, there may be a 
temporary outage of Mailing List Archive services. Please consult Site Status 
for more information.

Re: Proposed function: x-display-usable-bounds

[Andreas Schwab]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

> On the Mac platform both the Carbon and Cocoa ports face the problem
> of determining where on the display to place new frames.

Isn't that the duty of the window manager?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Proposed function: x-display-usable-bounds

[Jason Rumney]

Andreas Schwab wrote:
> "Adrian Robert" <adrian.b.robert@gmail.com> writes:
>
>   
>> On the Mac platform both the Carbon and Cocoa ports face the problem
>> of determining where on the display to place new frames.
>>     
>
> Isn't that the duty of the window manager?
>   
Only if you don't explicitly specify where to put the window. It is
still useful for Emacs to know about the usable display area, for
handling the --fullscreen option, etc.

Re: Proposed function: x-display-usable-bounds

[Adrian Robert]

On Dec 3, 2007 12:40 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> The implementation for KDE and Gnome could easily be done in elisp.  Does your
> patch handle multiple desktops/screens?

For the Cocoa port (unsure about Carbon), screens throughout are
currently considered separate display areas; dimensions reported for
this and other x-display- functions correspond to the screen the frame
being asked about is on, or the main screen (where menubar and dock
are) if this information is not given.  (Other behaviors are possible,
but not necessarily preferable.)



> > http://sourceforge.net/mailarchive/forum.php?thread_name=2CE05DE2-B276-4F80-918B-9C1A28DF169A%40gmail.com&forum_name=emacs-app-dev-
> >
>
> ERROR

I think this was a transient server condition -- link just worked for
me after logging out of sourceforge.


> Isn't that the duty of the window manager?

On the Mac (or GNUstep) there is no auto-placement of windows.

Re: Proposed function: x-display-usable-bounds

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 3 Dec 2007 15:34:57 +0300, "Adrian Robert" <adrian.b.robert@gmail.com> said:

> On Dec 3, 2007 12:40 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>> The implementation for KDE and Gnome could easily be done in elisp.
>> Does your patch handle multiple desktops/screens?

> For the Cocoa port (unsure about Carbon), screens throughout are
> currently considered separate display areas; dimensions reported for
> this and other x-display- functions correspond to the screen the
> frame being asked about is on, or the main screen (where menubar and
> dock are) if this information is not given.  (Other behaviors are
> possible, but not necessarily preferable.)

The behavior of x-display-pixel-width/height in the Carbon port was
changed relatively recently (March, 2007): it now reports the
dimensions of the whole screen because this behavior is more
consistent with the X11 build.

http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-03/msg00420.html

>> Isn't that the duty of the window manager?

> On the Mac (or GNUstep) there is no auto-placement of windows.

The Carbon(+AppKit) ports place a new frame to the cascading position
with respect to the selected frame if the position is not specified
explicitly.  Both Carbon and Cocoa have support for this functionality
(RepositionWindow and -[NSWindow cascadeTopLeftFromPoint:],
respectively).  Both of them also do rollover so that more than half
of the window (Carbon) or whole part of the window (Cocoa) becomes
visible.

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

Re: Proposed function: x-display-usable-bounds

[Stefan Monnier]

> width height) for the usable screen area.  Since it seems relevant for
> all platforms, it would seem appropriate to name this function with an
> x- prefix, e.g., x-display-usable-bounds, and define it for all
> platforms.  As a placeholder implementation, a list (0 0

Actually, better *not* use an "x-" prefix for the main name.  I.e. name
it "display-usable-bounds".  It's implementation may just check the
display used by the selected frame and dispatch to
x-display-usable-bounds,  w32-display-usable-bounds,
mac-display-usable-bounds, ...


        Stefan "we may one day be able to build an Emacs executable that
                can not only control simultanously several X11s and ttys
                but also some W32/Carbon/GNUstep backend and maybe more".

Re: Proposed function: x-display-usable-bounds

[Adrian Robert]

On Dec 3, 2007 5:56 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > width height) for the usable screen area.  Since it seems relevant for
> > all platforms, it would seem appropriate to name this function with an
> > x- prefix, e.g., x-display-usable-bounds, and define it for all
> > platforms.  As a placeholder implementation, a list (0 0
>
> Actually, better *not* use an "x-" prefix for the main name.  I.e. name
> it "display-usable-bounds".  It's implementation may just check the
> display used by the selected frame and dispatch to
> x-display-usable-bounds,  w32-display-usable-bounds,
> mac-display-usable-bounds, ...

I followed the convention of x-display-pixel-width etc., which are a
class of lisp functions applicable on all windowing systems but called
directly as "x-..." from various places and very early, so that
aliasing didn't work (the Cocoa port tries to name its display
functions with a ns- prefix).

It seems the 'x-' prefix may sometimes mean "X-windows display
function" but is mostly used as "generic windowing system function".
Changing this might be good but it would make the most sense to do it
all at once after determining the best plan.

Note there is also an 'xw-' prefix used for some functions (e.g.
xw-color-defined-p).

Re: Proposed function: x-display-usable-bounds

[Stefan Monnier]

> It seems the 'x-' prefix may sometimes mean "X-windows display
> function" but is mostly used as "generic windowing system function".

Usually it started as "X-only" and then code started to use it and in
order not to have to fix it other backends also used "x-" when
implementing the corresponding feature.

But this is wrong and should be fixedm and has been fixed in several
cases (e.g. most of the functions that start with "display-").

> Changing this might be good but it would make the most sense to do it
> all at once after determining the best plan.

Yes, maybe it should be fixes wholesale as well, but at least let's not
make things worse than they already are.

> Note there is also an 'xw-' prefix used for some functions (e.g.
> xw-color-defined-p).

Indeed.  And notice that there's `color-defined-p' as well, which is the
one that should be used.


        Stefan