[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?
- Re: x-display-pixel-width/height inconsistency, (continued)
- Re: x-display-pixel-width/height inconsistency, grischka, 2013/03/20
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/03/20
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/03/21
- Re: x-display-pixel-width/height inconsistency, Eli Zaretskii, 2013/03/22
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/03/22
- Re: x-display-pixel-width/height inconsistency, Eli Zaretskii, 2013/03/23
- Re: x-display-pixel-width/height inconsistency, Jan Djärv, 2013/03/23
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/03/23
- Re: x-display-pixel-width/height inconsistency, Eli Zaretskii, 2013/03/23
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/03/24
- Re: x-display-pixel-width/height inconsistency,
Eli Zaretskii <=