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

Previous Next

Full log

Message #341 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: Tue, 27 Oct 2015 22:42:00 +0100

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

Hi,

here is a patch to fix the problems with tool-bar-mode, please try it out.

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?

    -- 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)]

[toolbar.diff (text/plain, attachment)]

[emacs-commit-messages2.txt (text/plain, attachment)]

[start-crash.txt (text/plain, attachment)]

Previous Next

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