Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

From: Anders Lindgren <[email-masked]>
Date: Sat, 24 Oct 2015 23:43:52 +0200

Hi,

On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <[email-masked]> 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