bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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,

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@gmail.com> wrote:
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


Attachment: toolbar.diff
Description: Text document

Attachment: emacs-commit-messages2.txt
Description: Text document

Attachment: start-crash.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]