GNU bug report logs - #21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

Previous Next

Full log

Message #344 received at 21415 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Keith David Bershatsky <esq <at> lawlist.com>, 21415 <at> debbugs.gnu.org
Subject: Re: bug#21415: 25.0.50;
 Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Wed, 28 Oct 2015 08:54:16 +0100

[Message part 1 (text/plain, inline)]

>
> 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 mean
> 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 <andlind <at> gmail.com>
> wrote:
>
>> Hi,
>>
>> On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics <at> 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 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 ‘display-monitor-attributes-list’ 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
>>
>>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.