[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: YAMAMOTO Mitsuharu
Subject: Re: x-display-pixel-width/height inconsistency
Date: Sun, 24 Mar 2013 08:58:29 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Sat, 23 Mar 2013 08:15:03 +0200, Eli Zaretskii <address@hidden> said:

>> > How did you deduce that SM_CXVIRTUALSCREEN and SM_CYVIRTUALSCREEN
>> > are not available on those old systems?  Can you point me to some
>> > documentation which has the details?
>> http://msdn.microsoft.com/ja-jp/library/cc429812.aspx (in Japanese.
>> But probably you can find "Window 98" and "Windows 2000" around

> Does it say something like "Starting from Windows 98 and Windows
> 2000"?  That's what I get from other sources on the Internet that
> talk about this subject.

It says "Window 98 AND Windows 2000".  Probably because this document
was written before XP or Me.

> I actually think we should always call GetSystemMetrics, and if that
> returns a failure indication, call the old code.  Testing versions
> is usually less desirable.

Could you check GetSystemMetrics safely returns 0 for unknown
arguments (because I can't test it)?  If so, avoiding version tests
would be better.

>> As I've already mentioned, the elisp info already contains the
>> description about the semantics under multi-monitor setups.
>> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00469.html

> That talks about display-pixel-width/height, while I was talking
> about x-display-pixel-width/height, the primitives where you propose
> the changes.  The latter are not mentioned in the ELisp manual at
> all, so their doc strings are the only source of documentation for
> them.

> Moreover, your changes touch x-display-mm-width/height as well, so
> now display-mm-width/height, whose documentation in the ELisp manual
> doesn't mention multiple terminals at all, will behave differently
> as well.

If these functions behave differently among the platforms on
multi-monitor setups, then they should be named with different
prefixes (i.e., w32-display-*, ns-display-*.  Note that the current
behavior is different even between W32 and NS).  Of course, I prefer
consistent behavior rather than having the different prefix.

>> Please look at my other posts:
>> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00553.html
>> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00555.html

> I've read all the thread, and I'm still asking the question, because
> nothing there seems to provide the answer.  Maybe you should re-read
> my question.

> What you say in those messages boils down to

>   . the X11 behavior is documented in the manual

>   . Emacs on X11 cannot distinguish between physical monitors that
> belong to the same display

> As I write above, the first point is only partially true
> (display-mm-width/height are not documented as describing the
> virtual screen, and the x-display-* primitives are not documented at
> all).  As for the second point, I don't see how it can be any
> guideline to make a decision, since both NS and W32 _can_
> distinguish between physical monitors (if we include the appropriate
> code).

> So the question still stands: which behavior should be considered
> "correct" and which a "missing feature".

My whole point is that functions for obtaining properties of each
physical monitor on multi-monitor setups should be provided as a new
function (or a new group of functions), rather than abusing the
existing functions x-display-* on displays primarily designed after
the notion of X11 "display" or "screen".  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.
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.

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]