From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: frame size&position woes Date: Mon, 22 Jul 2013 22:36:33 +0200 Message-ID: References: <51EBEA23.2000805@gmx.at> <51ECEBDB.8010203@gmx.at> <837ggiy4ko.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1374525446 31424 80.91.229.3 (22 Jul 2013 20:37:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jul 2013 20:37:26 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 22 22:37: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 1V1MrG-0006xg-5c for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 22:37:26 +0200 Original-Received: from localhost ([::1]:40107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1MrF-0006fe-Ny for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 16:37:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1Mr9-0006Xp-Tt for emacs-devel@gnu.org; Mon, 22 Jul 2013 16:37:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1Mr7-0006lM-GR for emacs-devel@gnu.org; Mon, 22 Jul 2013 16:37:19 -0400 Original-Received: from mail-ea0-x236.google.com ([2a00:1450:4013:c01::236]:38002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1Mr4-0006ju-U9; Mon, 22 Jul 2013 16:37:15 -0400 Original-Received: by mail-ea0-f182.google.com with SMTP id d10so4094105eaj.27 for ; Mon, 22 Jul 2013 13:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OSTWDeeozYa8S6JOMqQKDYUBpYxSEvwr+lGkm7GhNJM=; b=OISYoV419nE2vfDPYzDRAwkS18MpBw45y1GeCL+WITGXzqbpusniZYFT5wevvhsCsM meX7TDlG0XcG5pamZ1PzNUNPeFFFwmSsmB7ClQsWjRv4K+uBCwtVdxJMyQqCRxkfi3Fw lxoE7FEk0Qwl7n1JK/49sHXQL3szeHzrtbOUa+4DNvhaNM7Fx8jmSqAEFtaqMgamAK+U LQKWnCGHVvRPZv0sVLopzqWNaeTG4EuDx4Y3RSF8GDBMQ9fHiIqBap7mlzDhzfUD9Z+w oxpoxul98h/ls7+++ctAqdYkWMcOFf0Sdgm6t4HuVJV07n3pCAM+dH/MDmykJGlzhI+K 3lcQ== X-Received: by 10.15.21.78 with SMTP id c54mr29206475eeu.14.1374525433575; Mon, 22 Jul 2013 13:37:13 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Mon, 22 Jul 2013 13:36:33 -0700 (PDT) In-Reply-To: <837ggiy4ko.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::236 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:162076 Archived-At: On Mon, Jul 22, 2013 at 5:52 PM, Eli Zaretskii wrote: > Is your problem, in practice, only with those weirdo frames that have > their tool bars and/or menu bars wrapped? Or do you have problems > with the more "dull" use cases as well? Tool bars are much better behaved than menu bars, even when wrapped, though there's bug#14795, that some consider a feature. "Dull" use cases, as you say, don't pose any problem (or none related to frame size anyway; there's still things to fix but unrelated to the physical appearance of frames). > 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. > 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... > It's not complex. AFAIK, "(make-frame '((height . N)))" creates a > frame whose "(frame-height)" returns N plus the value returned by > tool-bar-lines-needed. I didn't even know that tool-bar-lines-needed existed. Anyway, I still think it's horrible that height means something different for make-frame and set-frame-parameter/modify-frame-parameters, but as there are workarounds, I won't argue the point again. > I expect the same to be true on X, with the > exception of a GTK build, where we might need to do something special. Well, let's hope someone tries desktop-restore-frames on GTK and reports the result. > Does this solve the problem with visible frames? If not, what is > left? As said above, knowing their real, physical size in pixels, instead of some Emacs interpretation of it in arbitrary "character" units, would be helpful. Juanma