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: frame size&position woes Date: Tue, 23 Jul 2013 05:45:37 +0300 Message-ID: <83y58yvvse.fsf@gnu.org> References: <51EBEA23.2000805@gmx.at> <51ECEBDB.8010203@gmx.at> <837ggiy4ko.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1374550388 11665 80.91.229.3 (23 Jul 2013 03:33:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2013 03:33:08 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 23 05:33:09 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 1V1TLW-000806-TK for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2013 05:33:07 +0200 Original-Received: from localhost ([::1]:33762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1TLW-00054e-8F for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 23:33:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1Sbm-00030Q-D4 for emacs-devel@gnu.org; Mon, 22 Jul 2013 22:45:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1Sbk-0002AP-VA for emacs-devel@gnu.org; Mon, 22 Jul 2013 22:45:50 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1Sbk-0002AB-Ds for emacs-devel@gnu.org; Mon, 22 Jul 2013 22:45:48 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MQD00400BL4YL00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 23 Jul 2013 05:45:46 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MQD004MBBOAM470@a-mtaout20.012.net.il>; Tue, 23 Jul 2013 05:45:46 +0300 (IDT) 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:162082 Archived-At: > From: Juanma Barranquero > Date: Mon, 22 Jul 2013 22:36:33 +0200 > Cc: martin rudalics , Emacs developers > > > If the latter, can you describe the unsolved problem(s) you have in > > that case? > > The biggest problem right now is not related to frame-height, but > frame-pixel-height, that is, we'd need a function that returned (for > every available window system and toolkit) the real width & height of > an Emacs frame in pixels, not of the client area, but the whole frame. > It's the only sane way to check whether a frame is currently visible > in a monitor. Why do you need all that? Isn't frame-height, frame-width, and the top and left frame parameters enough to restore the frame's dimensions and position? > > People who wrap menus deserve that. > > On one hand, I agree with you. It's ugly and I would never do it. On > the other hand, I'm not trying to make desktop-restore-frames work for > me, but for as many users as possible. And we have an elisp API to > create a frame without menu-bar or remove it from one (via frame > parameters), but I don't think we have a UI command to do that, so if > the user wants to use menus, but s/he also wants to have a narrow > frame for some reason (let's say, to follow the output of some command > which only prints short lines), s/he's forced to make the frame wider, > or accept a wrapped menu. If s/he then saves & restores... ...then the frame will not be restored to the exact size it was, but maybe one or two lines more or less. I don't see a big problem here, it's a marginal use case, one I doubt even exists.