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 05:53:10 +0200 Message-ID: <83vc8h313t.fsf@gnu.org> References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1364097208 20282 80.91.229.3 (24 Mar 2013 03:53:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 03:53:28 +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 04:53:54 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 1UJc0H-0006PI-US for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 04:53:54 +0100 Original-Received: from localhost ([::1]:56603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJbzu-0004Pr-BE for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 23:53:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJbzp-0004PZ-Mk for emacs-devel@gnu.org; Sat, 23 Mar 2013 23:53:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJbzn-0004My-ON for emacs-devel@gnu.org; Sat, 23 Mar 2013 23:53:25 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJbzn-0004Mt-Fg for emacs-devel@gnu.org; Sat, 23 Mar 2013 23:53:23 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MK500D00BYIBU00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 24 Mar 2013 05:53:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK500D73C4FBQ10@a-mtaout20.012.net.il>; Sun, 24 Mar 2013 05:53:04 +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:158101 Archived-At: > Date: Sun, 24 Mar 2013 08:58:29 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org > > > 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)? What else can it do? Failing for invalid parameters is what Windows APIs always do. > > 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. 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. > 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". 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"). > 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. > 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.