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: Wed, 28 Oct 2015 08:54:16 +0100 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=001a113dc2724c3c2a05232580c1 X-Trace: ger.gmane.org 1446018921 27635 80.91.229.3 (28 Oct 2015 07:55:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Oct 2015 07:55: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 Wed Oct 28 08:55: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 1ZrLZe-00060Y-RJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Oct 2015 08:55:11 +0100 Original-Received: from localhost ([::1]:36019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrLZe-0000OF-0H for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Oct 2015 03:55:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrLZa-0000Ma-Eg for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2015 03:55:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrLZX-000216-2h for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2015 03:55:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrLZW-000210-Ug for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2015 03:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZrLZW-0002sp-IR for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2015 03:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Oct 2015 07:55: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.144601888011030 (code B ref 21415); Wed, 28 Oct 2015 07:55:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 28 Oct 2015 07:54:40 +0000 Original-Received: from localhost ([127.0.0.1]:41140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZrLZ9-0002rp-34 for submit@debbugs.gnu.org; Wed, 28 Oct 2015 03:54:39 -0400 Original-Received: from mail-vk0-f42.google.com ([209.85.213.42]:33722) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZrLYn-0002r4-KP for 21415@debbugs.gnu.org; Wed, 28 Oct 2015 03:54:36 -0400 Original-Received: by vkgy127 with SMTP id y127so137512915vkg.0 for <21415@debbugs.gnu.org>; Wed, 28 Oct 2015 00:54:16 -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=RmJURpRy2VOALGL0o8jIW5W5AzrrHO/GPwaVw9WaRo8=; b=foEEH5/QeSgbmo1BEF71WqoOFfOKKpSsxaPWHz3mNFX95cf1C9kWGykGPYrbyaO41g m/+fWkbxx8dJA0GO0dS9//iNhvE6UxK4VV9uvCsAx/Dw/y80KMt/UUReqGQJsjHetnIq koMyAguTTc81OfikqjXoqA2F/sDfbL4YWeLxgeMDonddHqs6oJXgV8QbIfGhEm3clte+ Tuhl32h5UVlmYVps+jA4fBk9J1og7sbCY6sBybEB7pUoHqFwyaJXAvsV4WLbcZfRhG7O FYPMwxvwQifvXozG+75Btw67iWqBNjmQrfI5krTJszkWGNLlPfVRz0mDpWN/FtpnRAhL mrlg== X-Received: by 10.31.33.200 with SMTP id h191mr33622475vkh.105.1446018856780; Wed, 28 Oct 2015 00:54:16 -0700 (PDT) Original-Received: by 10.31.210.133 with HTTP; Wed, 28 Oct 2015 00:54:16 -0700 (PDT) In-Reply-To: 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:108092 Archived-At: --001a113dc2724c3c2a05232580c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > One thing that I have noticed lately is that Emacs often crash when > started. I managed to get a call stack by running gdb, but it doesn't mea= n > much to me. Do any of you have an idea what is going on? > I think I have solved this one. Input events started coming in before the init code had finished. By surrounding it by a block_input() and unblock_input() pair it seems to work better. I will run it for a couple of days and, if the problems have gone away, I will commit it. -- Anders > On Sat, Oct 24, 2015 at 11:43 PM, Anders Lindgren > wrote: > >> 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 chan= ge >> > ^^^^^ >> > 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 you= r >> > 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 th= at >> > 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 use= d >> 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 initi= al >> > 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 animati= on >> runs, everything work OK. Hopefully, I will be able to push the end resu= lt >> within the next couple of days. >> >> -- Anders >> >> > --001a113dc2724c3c2a05232580c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One thing that I have noti= ced lately is that Emacs often crash when started. I managed to get a call = stack by running gdb, but it doesn't mean much to me. Do any of you hav= e an idea what is going on?

I t= hink I have solved this one. Input events started coming in before the init= code had finished. By surrounding it by a block_input() and unblock_input(= ) pair it seems to work better. I will run it for a couple of days and, if = the problems have gone away, I will commit it.

=C2= =A0 =C2=A0 -- Anders

=C2=A0
On Sat, Oct 24, 2015 at 11:43 PM, Anders L= indgren <andlind@gmail.com> wrote:
Hi,

On Sat, Oct 24, 2015 at 8:57 P= M, martin rudalics <rudalics@gmx.at> wrote:
>
> > Anyway, I think the pr= oblem you are seeing is due to the fact that I have
> > replaced t= he code in "zoom" with custom code that simply resizes the frame.=
> > On OS X there is nothing special happening when maximizing th= e frame -- the
> > outer frame (one pixel thick) is still there, n= o buttons should change
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^
> Y= ou mean the outer border, I presume.=C2=A0 Here the border (some 5 pixels)<= br>> is probably removed by the window manager.=C2=A0 Don't ask me w= hy and how.
> But this and most other problems I reported existed alr= eady before your
> change.

Was the outer frame removed = and the icon changed before my rewrites? If so, try to use the old zoom sys= tem instead of the new.

=C2=A0
> I doubt it would help m= uch.=C2=A0 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<= br>> 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 fra= me.

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


> BTW
>
> (set-frame-parame= ter nil 'fullscreen 'fullboth)
>
> is broken here just = as it was before your changes.=C2=A0 Does it work for you?

Ye= s, it enters the real fullscreen mode.
=C2=A0
Does it work if you se= t `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 m= aximized initial frame ;-)

Bizzarre... I would check "up= date_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, windo= wWasResized 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.

=C2=A0 =C2=A0 -- Anders
<= br>


--001a113dc2724c3c2a05232580c1--