From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Sun, 24 Mar 2013 13:36:03 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> <83vc8h313t.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1364099775 5412 80.91.229.3 (24 Mar 2013 04:36:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 04:36:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 24 05:36:41 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 1UJcfg-0004hh-9S for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 05:36:40 +0100 Original-Received: from localhost ([::1]:43203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcfI-00007e-Kw for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 00:36:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcfE-00006f-6u for emacs-devel@gnu.org; Sun, 24 Mar 2013 00:36:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJcfC-0007vU-Vh for emacs-devel@gnu.org; Sun, 24 Mar 2013 00:36:12 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcfA-0007v3-11; Sun, 24 Mar 2013 00:36:08 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id DFD3AC055D; Sun, 24 Mar 2013 13:36:03 +0900 (JST) In-Reply-To: <83vc8h313t.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 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:158103 Archived-At: >>>>> 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. > 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. As we currently have three different behaviors of (x-)display-pixel-width/height on different platforms, whatever we define the "normative" behavior, at least two of them must be changed if we try to make them consistent across the platforms. > 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"). Documentations could be updated accordingly once we determine the "normative" behavior as above. >> 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? >> 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. Aligning all the platforms to the X11 is not ad hoc but makes several things consistent, not only behaviors among multiple platforms but also the argument convention among x-display-* functions. A possible design for the new function would be: DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list, Sx_display_monitor_attributes_list, 0, 1, 0, doc: /* Return a list of physical monitor attributes on X display. Each element of the list represents the attributes of each physical monitor. The first element corresponds to the primary monitor. Attributes for a physical monitor is represented as an alist of attribute names and values as follows: Name | Value ----------|------------------------------------ geometry | position and size | of the form (LEFT TOP WIDTH HEIGHT) work-area | position and size of the work area | of the form (LEFT TOP WIDTH HEIGHT) mm-size | width and height in millimeters | of the form (WIDTH HEIGHT) where LEFT TOP WIDTH, and HEIGHT are integers. The optional argument TERMINAL specifies which display to ask about. TERMINAL should be a terminal object, a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display. */) (Lisp_Object terminal) The attributes are selected from the GdkScreen monitor functions. Some platform-specific attributes can also be included (if they are only meaningful on the platform), e.g., backing scale factor on OSX. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp