all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Reitter <david.reitter@gmail.com>
To: Adrian Robert <adrian.b.robert@gmail.com>
Cc: 2546@emacsbugs.donarmstrong.com
Subject: bug#2546: toolbar bug
Date: Fri, 6 Mar 2009 10:28:32 -0500	[thread overview]
Message-ID: <960A3BEA-17C7-44EF-AD66-848B87D174A5@gmail.com> (raw)
In-Reply-To: <3D55069C-A596-46D9-86E3-3F553041F034@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

On 6 Mar 2009, at 09:56, Adrian Robert wrote:

> The calculation method that was commented out in x_set_window_size()  
> works here, and I've committed it to CVS.  As mentioned in the  
> comment, this would sometimes fail previously if the toolbar had not  
> been displayed yet.  I believe the relevant call would be [toolbar  
> setVisible: true] and this normally happens in nsmenu.c:  
> ns_update_toolbar().  When a new frame is created, it is initially  
> set to NOT visible in EmacsView-initFrameFromEmacs, because it will  
> be turned on if needed and after it is ready by  
> ns_update_toolbar().  However, if this gets called AFTER  
> x_set_window_size(), it could cause the failure.  If you still see  
> it in your environment, could you try throwing in a call to [[view  
> toolbar] setVisible: true] in the 'if (tb)' section before calling  
> frameRectForContentRect, and see if that helps?
>
> BTW I changed the order of the COCOA and GNUstep implementations to  
> agree with the XXX comment just above.  This was accidentally  
> reversed during a time when emacs-devel was asking me to get rid of  
> one of NS_IMPL_COCOA, NS_IMPL_GNUSTEP and I did not realize at first  
> that this was impossible.


I've come to similar conclusions yesterday and tried a few things  
(including the setVisible, or a call to update_frame_toolbar to fill  
it) without much success.
However, what does seem to work is to only add the toolbar height if  
it is visible.  Try the patch below.

What would be better though is to set the toolbar before the frame is  
drawn, since the resizing effect is quite ugly.

Also, there is another bug that causes window content to be drawn  
briefly at the wrong position while the toolbar appears, i.e., after  
you click on the toolbar button to turn it on.  It's similar to the  
ugliness we see when resizing frames.  I haven't found that one yet.

- David






Index: nsterm.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.m,v
retrieving revision 1.58
diff -c -r1.58 nsterm.m
*** nsterm.m	7 Feb 2009 11:04:07 -0000	1.58
--- nsterm.m	6 Mar 2009 15:23:04 -0000
***************
*** 1162,1178 ****
   			    styleMask: [window styleMask]])
           - FRAME_NS_TITLEBAR_HEIGHT (f);
   #else
!     FRAME_NS_TOOLBAR_HEIGHT (f) = 32;
!       /* actually get wrong result here if toolbar not yet displayed
            NSHeight ([window frameRectForContentRect: NSMakeRect (0,  
0, 0, 0)])
            - FRAME_NS_TITLEBAR_HEIGHT (f); */
   #endif
     else
       FRAME_NS_TOOLBAR_HEIGHT (f) = 0;
!
     wr.size.width = pixelwidth + f->border_width;
!   wr.size.height = pixelheight + FRAME_NS_TITLEBAR_HEIGHT (f)
!                   + FRAME_NS_TOOLBAR_HEIGHT (f);

     /* constrain to screen if we can */
     if (screen)
--- 1169,1188 ----
   			    styleMask: [window styleMask]])
           - FRAME_NS_TITLEBAR_HEIGHT (f);
   #else
!       FRAME_NS_TOOLBAR_HEIGHT (f) = 32; // 47;
!       /* actually get wrong result here if toolbar not yet displayed
            NSHeight ([window frameRectForContentRect: NSMakeRect (0,  
0, 0, 0)])
            - FRAME_NS_TITLEBAR_HEIGHT (f); */
+
   #endif
     else
       FRAME_NS_TOOLBAR_HEIGHT (f) = 0;
!
     wr.size.width = pixelwidth + f->border_width;
!   wr.size.height = pixelheight + FRAME_NS_TITLEBAR_HEIGHT (f);
!
!   if ([[FRAME_NS_VIEW (f) toolbar] isVisible])
!     wr.size.height += FRAME_NS_TOOLBAR_HEIGHT (f);

     /* constrain to screen if we can */
     if (screen)


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

  reply	other threads:[~2009-03-06 15:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06 14:56 bug#2546: toolbar bug Adrian Robert
2009-03-06 15:28 ` David Reitter [this message]
2009-03-06 15:42 ` David Reitter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=960A3BEA-17C7-44EF-AD66-848B87D174A5@gmail.com \
    --to=david.reitter@gmail.com \
    --cc=2546@emacsbugs.donarmstrong.com \
    --cc=adrian.b.robert@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.