Re: x-display-pixel-width/height inconsistency

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 24 Mar 2013 05:53:10 +0200, Eli Zaretskii <address@hidden> said:

>> Could you check GetSystemMetrics safely returns 0 for unknown
>> arguments (because I can't test it)?

> What else can it do?  Failing for invalid parameters is what Windows
> APIs always do.

I'm not a W32 expert.  So I thought the possibility of aborting (as a
fatal program bug) or writing warning messages to some syslog
counterparts for invalid parameters.

> That's a different issue.  My point was that your patch should
> include changes to doc strings that describe what these functions
> will do after the changes are installed.

> As for different names, it depends on what we decide to be the
> "normative" behavior.

OK.  My proposal is to determine that the term "display" in Emacs
refers to the notion of that in X11 (the whole screen spanning
possibly multiple all the physical monitors) so that we can define
"normative" behaviors the functions (x-)display-*.  Very simple and no
change required for X11.

As we currently have three different behaviors of
(x-)display-pixel-width/height on different platforms, whatever we
define the "normative" behavior, at least two of them must be changed
if we try to make them consistent across the platforms.

> No one said that "display" refers to all the monitors on the X11
> display.  It could be just a coincidence, since these functions were
> written when each X11 display had only one monitor.  And as for
> "screen", that term does not appear in the functions' names or in
> their doc strings (which talk about "terminal").

Documentations could be updated accordingly once we determine the
"normative" behavior as above.

>> Users would want to know several kinds of information about each
>> monitor, such as the geometry (including the origin) or the
>> workarea, not just about size in pixels.
> The problem of geometry and the origin exists for a single virtual
> display as well.

??? Could you expand?

>> Tweeking x-display-pixel-width/height in a platform-specific way or
>> adding functions such as display-usable-bounds in the NS port
>> without considering the whole design for operations on monitors
>> looks rather ad hoc to me.

> Then please present a design that would make sense, not just an
> ad-hoc set of changes to align all the platforms to the X11
> behavior.

Aligning all the platforms to the X11 is not ad hoc but makes several
things consistent, not only behaviors among multiple platforms but
also the argument convention among x-display-* functions.

A possible design for the new function would be:

DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list, 
Sx_display_monitor_attributes_list,
       0, 1, 0,
       doc: /* Return a list of physical monitor attributes on X display.

Each element of the list represents the attributes of each physical
monitor.  The first element corresponds to the primary monitor.

Attributes for a physical monitor is represented as an alist of
attribute names and values as follows:

    Name      | Value
    ----------|------------------------------------
    geometry  | position and size
              | of the form (LEFT TOP WIDTH HEIGHT)
    work-area | position and size of the work area
              | of the form (LEFT TOP WIDTH HEIGHT)
    mm-size   | width and height in millimeters
              | of the form (WIDTH HEIGHT)

where LEFT TOP WIDTH, and HEIGHT are integers.

The optional argument TERMINAL specifies which display to ask about.
TERMINAL should be a terminal object, a frame or a display name (a string).
If omitted or nil, that stands for the selected frame's display.  */)
  (Lisp_Object terminal)

The attributes are selected from the GdkScreen monitor functions.
Some platform-specific attributes can also be included (if they are
only meaningful on the platform), e.g., backing scale factor on OSX.

                                     YAMAMOTO Mitsuharu
                                address@hidden