From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Sun, 24 Mar 2013 18:19:33 +0200 Message-ID: <83obe83h4a.fsf@gnu.org> References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> <83vc8h313t.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1364142004 26872 80.91.229.3 (24 Mar 2013 16:20:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 16:20:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 24 17:20:26 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UJnei-00033b-BI for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 17:20:24 +0100 Original-Received: from localhost ([::1]:37639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJneK-0000D0-Lo for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 12:20:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJneG-0000Co-Rw for emacs-devel@gnu.org; Sun, 24 Mar 2013 12:19:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJneE-0005qM-On for emacs-devel@gnu.org; Sun, 24 Mar 2013 12:19:56 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:61088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJneE-0005nt-GR for emacs-devel@gnu.org; Sun, 24 Mar 2013 12:19:54 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MK600M00AO06100@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 24 Mar 2013 18:19:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK600LNLAOD86I0@a-mtaout20.012.net.il>; Sun, 24 Mar 2013 18:19:26 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158111 Archived-At: > Date: Sun, 24 Mar 2013 13:36:03 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org > > >>>>> On Sun, 24 Mar 2013 05:53:10 +0200, Eli Zaretskii 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?