From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame Date: Sat, 24 Oct 2015 23:43:52 +0200 Message-ID: References: <561E92D8.1050500@gmx.at> <561F7943.9090309@gmx.at> <562746AA.7090004@gmx.at> <5627B83F.9060303@gmx.at> <562BD487.20109@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11431b66d5fa7c0522e09f93 X-Trace: ger.gmane.org 1445723121 26899 80.91.229.3 (24 Oct 2015 21:45:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 21:45:21 +0000 (UTC) Cc: Keith David Bershatsky , 21415@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 24 23:45:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Zq6ch-0006f1-8m for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 23:45:11 +0200 Original-Received: from localhost ([::1]:45794 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq6cg-0001ku-47 for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 17:45:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq6cc-0001iV-Iu for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 17:45:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zq6cZ-00076i-Bd for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 17:45:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zq6cZ-00076T-8Y for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 17:45:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zq6cY-0002pR-Qh for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 17:45:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Oct 2015 21:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21415-submit@debbugs.gnu.org id=B21415.144572305610804 (code B ref 21415); Sat, 24 Oct 2015 21:45:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 24 Oct 2015 21:44:16 +0000 Original-Received: from localhost ([127.0.0.1]:37130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zq6bn-0002oC-6I for submit@debbugs.gnu.org; Sat, 24 Oct 2015 17:44:15 -0400 Original-Received: from mail-vk0-f46.google.com ([209.85.213.46]:36412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zq6bR-0002nN-VI for 21415@debbugs.gnu.org; Sat, 24 Oct 2015 17:44:13 -0400 Original-Received: by vkex70 with SMTP id x70so79853691vke.3 for <21415@debbugs.gnu.org>; Sat, 24 Oct 2015 14:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2E/0aC27yFAWRhHNE2wGosCjbSZboSucjefk9nLwpfA=; b=OsG4E8yxfcq9JVCZYxXXaM6FLaPWlk+U7te/ktEj0Vt6X0ZoDHrQfSBa/z4e17GYNf x8F2MGMpl0KtW5jDLCj3RZ7qjhxBy155vr+rcU+OgEQ68cj/tUrn3VdmJOhzwRetQaaI ZptJ2Nnrhf5OId7jxyRdklujaQf0htakr9UB03ue5mWHiYPI/gevILFiFkyIvfVRAKi0 +pD71vbiOymjEh5fTDNiPMTFnBlqSARrnphOgikN5RD581SLFraKLehtzaKG2Ch48BLf XjoJpROIkOnDHAa/qbCQJ7DAt1EHKK/nxLqqS3/2FqlOz48sddCaUKjcMxDZIgspMglb Gspg== X-Received: by 10.31.170.68 with SMTP id t65mr16290137vke.31.1445723033169; Sat, 24 Oct 2015 14:43:53 -0700 (PDT) Original-Received: by 10.31.210.133 with HTTP; Sat, 24 Oct 2015 14:43:52 -0700 (PDT) In-Reply-To: <562BD487.20109@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108003 Archived-At: --001a11431b66d5fa7c0522e09f93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics wrote: > > > Anyway, I think the problem you are seeing is due to the fact that I have > > replaced the code in "zoom" with custom code that simply resizes the frame. > > On OS X there is nothing special happening when maximizing the frame -- the > > outer frame (one pixel thick) is still there, no buttons should change > ^^^^^ > You mean the outer border, I presume. Here the border (some 5 pixels) > is probably removed by the window manager. Don't ask me why and how. > But this and most other problems I reported existed already before your > change. Was the outer frame removed and the icon changed before my rewrites? If so, try to use the old zoom system instead of the new. > I doubt it would help much. One basic problem with GNUStep here is that > the workarea as returned by =E2=80=98display-monitor-attributes-list=E2= =80=99 is the > same as the geometry returned by that function (are they the same on > OSX?). Hence I see no way to have the GNUStep build recognize the > presence of my taskbar and not hide it when maximizing the frame. You can check if the NSScreen "frame" and "visibleFrame" would return different frame. In "ns_menu_bar_height" I use this. Maybe it can be used under GNUStep to find the height of the taskbar? > BTW > > (set-frame-parameter nil 'fullscreen 'fullboth) > > is broken here just as it was before your changes. Does it work for you? Yes, it enters the real fullscreen mode. Does it work if you set `ns-use-native-fullscreen' to nil? > > When it comes to the double tool bar, I have unfortunately no idea what the > > problem is. > > The crazy thing is that with the old build I got it for a normal initial > frame and now I get for a maximized initial frame ;-) Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or initFrameFromEmacs in nsterm.m to see if any of those allocate more than one EmacsToolbar. I have located the toolbar error. When "setVisible" is called, OS X starts an animation. When this animation runs, windowWasResized tried to keep up and update rows and columns. On the way it got lost and the end result was a bad "row" could. When simply doing nothing when the animation runs, everything work OK. Hopefully, I will be able to push the end result within the next couple of days. -- Anders --001a11431b66d5fa7c0522e09f93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Sat, Oct 24, 2015 at 8:57 PM, martin rudalic= s <rudalics@gmx.at> wrote:
= >
> > Anyway, I think the problem you are seeing is due to the = fact that I have
> > replaced the code in "zoom" with cu= stom code that simply resizes the frame.
> > On OS X there is noth= ing special happening when maximizing the frame -- the
> > outer f= rame (one pixel thick) is still there, no buttons should change
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^
> You mean the outer border, I presume= .=C2=A0 Here the border (some 5 pixels)
> is probably removed by the = window manager.=C2=A0 Don't ask me why and how.
> But this and mo= st other problems I reported existed already before your
> change.
Was the outer frame removed and the icon changed before my rewrites? I= f so, try to use the old zoom system instead of the new.

=C2=A0
&= gt; I doubt it would help much.=C2=A0 One basic problem with GNUStep here i= s that
> the workarea as returned by =E2=80=98display-monitor-attribu= tes-list=E2=80=99 is the
> same as the geometry returned by that func= tion (are they the same on
> OSX?).=C2=A0 Hence I see no way to have = the GNUStep build recognize the
> presence of my taskbar and not hide= it when maximizing the frame.

You can check if the NSScreen "f= rame" and "visibleFrame" would return different frame. In &q= uot;ns_menu_bar_height" I use this. Maybe it can be used under GNUStep= to find the height of the taskbar?


> BTW
>
> (se= t-frame-parameter nil 'fullscreen 'fullboth)
>
> is bro= ken here just as it was before your changes.=C2=A0 Does it work for you?
Yes, it enters the real fullscreen mode.
=C2=A0
Does it work if= you set `ns-use-native-fullscreen' to nil?


> >= When it comes to the double tool bar, I have unfortunately no idea what th= e
> > problem is.
>
> The crazy thing is that with the= old build I got it for a normal initial
> frame and now I get for a = maximized initial frame ;-)

Bizzarre... I would check "update_f= rame_tool_bar" in nsmenu.m or initFrameFromEmacs in nsterm.m to see if= any of those allocate more than one EmacsToolbar.

<= br>
I have located the toolbar error. When "setVisible"= is called, OS X starts an animation. When this animation runs, windowWasRe= sized tried to keep up and update rows and columns. On the way it got lost = and the end result was a bad "row" could. When simply doing nothi= ng when the animation runs, everything work OK. Hopefully, I will be able t= o push the end result within the next couple of days.

<= div>=C2=A0 =C2=A0 -- Anders

--001a11431b66d5fa7c0522e09f93--