GNU bug report logs -
#21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Previous Next
Reported by: Keith David Bershatsky <esq <at> lawlist.com>
Date: Fri, 4 Sep 2015 17:43:01 UTC
Severity: wishlist
Found in version 25.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #338 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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)]
This bug report was last modified 4 years and 251 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.