emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: x-display-pixel-width/height inconsistency
Date: Sun, 24 Mar 2013 18:19:33 +0200

> Date: Sun, 24 Mar 2013 13:36:03 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: address@hidden
> 
> >>>>> 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.

The "normal" (i.e., non-buggy) behavior of the Windows APIs is to
return an error indication and set the error code (returned by
GetLastError) to ERROR_INVALID_PARAMETER.  I don't have access to NT 4
or Windows 95, but I verified that on XP passing 200 as the parameter
indeed yields this behavior for GetSystemMetrics.

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

Please include the necessary documentation changes to codify this
behavior, and then I have no objections to such a change.

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

I think documentation changes should be part of the proposed changes
in this case.

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

See this page, for example:

   
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145136%28v=vs.85%29.aspx

As you see, the origin is on the top-left corner of the _primary_
monitor, and if some other monitor is configured to display the
portion of the virtual screen to the left of the primary, the X
coordinates there will be negative.  What happens on X11 and NS in
this case?



reply via email to

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