|
From: | Anders Lindgren |
Subject: | bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame |
Date: | Tue, 27 Oct 2015 22:42:00 +0100 |
Hi,
On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <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 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
toolbar.diff
Description: Text document
emacs-commit-messages2.txt
Description: Text document
start-crash.txt
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |