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: Fri, 22 Mar 2013 12:33:36 +0200 Message-ID: <831ub767wf.fsf@gnu.org> References: <514A5DE1.10009@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1363948450 1228 80.91.229.3 (22 Mar 2013 10:34:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2013 10:34:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 22 11:34:34 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 1UIzIv-0005EU-Th for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2013 11:34:34 +0100 Original-Received: from localhost ([::1]:57162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIzIY-0004ih-HZ for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2013 06:34:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIzIU-0004iI-1W for emacs-devel@gnu.org; Fri, 22 Mar 2013 06:34:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIzIR-0008Ta-8L for emacs-devel@gnu.org; Fri, 22 Mar 2013 06:34:05 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:50644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIzIQ-0008Sd-Vt for emacs-devel@gnu.org; Fri, 22 Mar 2013 06:34:03 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MK20080055IBD00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 22 Mar 2013 12:33:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK20081X5BY5OB0@a-mtaout21.012.net.il>; Fri, 22 Mar 2013 12:33:35 +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.169 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:158057 Archived-At: > Date: Fri, 22 Mar 2013 08:29:55 +0900 > From: YAMAMOTO Mitsuharu > > >>>>> On Thu, 21 Mar 2013 10:44:29 +0900, YAMAMOTO Mitsuharu said: > > >> Then use > >> w = GetSystemMetrics(SM_CXVIRTUALSCREEN); > >> h = GetSystemMetrics(SM_CYVIRTUALSCREEN); > > > Thanks. I tried making a patch using them. Do you happen to know an > > appropriate way to exclude Windows 95 and NT 4 where > > SM_CXVIRTUALSCREEN and SM_CYVIRTUALSCREEN are not available? > > Patch updated. I used the condition (w32_major_version == 4 && > w32_minor_version == 0) to distinguish Windows 95 and NT 4 from the > other versions. How did you deduce that SM_CXVIRTUALSCREEN and SM_CYVIRTUALSCREEN are not available on those old systems? Can you point me to some documentation which has the details? If we do need to distinguish those systems, there's os_subtype variable, which can help you be sure that you include both Windows 9X and NT 4.0, as version info on 9X is somewhat tricky. > --- 4731,4745 ---- > { > struct w32_display_info *dpyinfo = check_x_display_info (display); > HDC hdc; > ! float mm_per_pixel; > > ! hdc = GetDC (NULL); > ! mm_per_pixel = ((float) GetDeviceCaps (hdc, VERTSIZE) > ! / GetDeviceCaps (hdc, VERTRES)); > ! ReleaseDC (NULL, hdc); > > ! return make_number ((int) (x_display_pixel_height (dpyinfo) * mm_per_pixel > ! + 0.5f)); > } > > DEFUN ("x-display-mm-width", Fx_display_mm_width, Sx_display_mm_width, 0, 1, 0, I'm bothered by the fact that you change the behavior of these functions in backward-incompatible ways, without properly documenting what values they return. The new doc strings do not add _anything_ to the vagueness of the previous description wrt what exactly are the "display dimensions". Now, you may be right about what these primitives do on X11 (I don't know enough about that to tell, and the man pages I've seen are not helpful), but if so, we should clearly document their semantics, either in the doc strings or/and in the ELisp manual. We certainly should mention the change in behavior in NEWS. Personally, I am still unsure how will dimensions of "the bounding rectangle of all display monitors" be helpful to any Lisp program; can you tell why you think returning that is a good idea? Maybe we should change the X11 implementation instead?