Toolbars on MacOSX

Toolbars on MacOSX

[Piet van Oostrum]

Now there's image support in CVS emacs for MacOSX, I would think toolbars
should work. However, I can't get it working (I tried for VM).
Is there anything that prevents toolbars on MacOSX or is there some
incantation that I missed?
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Toolbars on MacOSX

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> 
> I would suggest enabling toolbars by default together with the XPM
> support code that I posted the other day.

Please do what's needed.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbars on MacOSX

[YAMAMOTO Mitsuharu]

>>>>> On 04 May 2004 23:16:20 +0200, Piet van Oostrum <piet@cs.uu.nl> said:

> Now there's image support in CVS emacs for MacOSX, I would think
> toolbars should work. However, I can't get it working (I tried for
> VM).  Is there anything that prevents toolbars on MacOSX or is there
> some incantation that I missed?

Currently, toolbars are not enabled by default.  Try M-x tool-bar-mode
RET.

There is a bug that a toolbar button is not highlighted just after
being clicked.  The following patch will solve the problem.

I would suggest enabling toolbars by default together with the XPM
support code that I posted the other day.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.67
diff -c -r1.67 macterm.c
*** src/macterm.c	7 May 2004 17:46:50 -0000	1.67
--- src/macterm.c	10 May 2004 13:04:26 -0000
***************
*** 1210,1216 ****
        FOR_EACH_FRAME (rest, frame)
  	x_flush (XFRAME (frame));
      }
!   else if (FRAME_X_P (f))
      XFlush (FRAME_MAC_DISPLAY (f));
    UNBLOCK_INPUT;
  #endif /* TARGET_API_MAC_CARBON */
--- 1210,1216 ----
        FOR_EACH_FRAME (rest, frame)
  	x_flush (XFRAME (frame));
      }
!   else if (FRAME_MAC_P (f))
      XFlush (FRAME_MAC_DISPLAY (f));
    UNBLOCK_INPUT;
  #endif /* TARGET_API_MAC_CARBON */
***************
*** 1410,1416 ****
  XTframe_up_to_date (f)
       struct frame *f;
  {
!   if (FRAME_X_P (f))
      {
        struct mac_display_info *dpyinfo = FRAME_MAC_DISPLAY_INFO (f);
  
--- 1410,1416 ----
  XTframe_up_to_date (f)
       struct frame *f;
  {
!   if (FRAME_MAC_P (f))
      {
        struct mac_display_info *dpyinfo = FRAME_MAC_DISPLAY_INFO (f);

Re: Toolbars on MacOSX

[Steven Tamm]

I've checked in the XPM patch and enabled tool-bar-mode by default.  
I've played around with it for a while now, and it appears to have the 
same behaviour as the X and NT GUIs.
To go back to the old "no toolbar" behavior, you need customize the 
tool-bar-mode variable or set tool-bar-lines to 0 in .emacs.  (setq 
default-frame-alist '(tool-bar-lines . 0)) will do.

The only major "hole" is the fact that tool-tips aren't supported with 
Carbon, yet.  In fact, tooltips might be the only "hole" in Carbon 
Emacs?  I've always had this idea that implementing tool-tips natively 
might be easier than porting over the w32 code (which creates a small 
highly-customized frame)... any thoughts?

-Steven

On May 11, 2004, at 2:49 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On 04 May 2004 23:16:20 +0200, Piet van Oostrum <piet@cs.uu.nl> 
>>>>>> said:
>
>> Now there's image support in CVS emacs for MacOSX, I would think
>> toolbars should work. However, I can't get it working (I tried for
>> VM).  Is there anything that prevents toolbars on MacOSX or is there
>> some incantation that I missed?
>
> Currently, toolbars are not enabled by default.  Try M-x tool-bar-mode
> RET.
>
> There is a bug that a toolbar button is not highlighted just after
> being clicked.  The following patch will solve the problem.
>
> I would suggest enabling toolbars by default together with the XPM
> support code that I posted the other day.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
> Index: src/macterm.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
> retrieving revision 1.67
> diff -c -r1.67 macterm.c
> *** src/macterm.c	7 May 2004 17:46:50 -0000	1.67
> --- src/macterm.c	10 May 2004 13:04:26 -0000
> ***************
> *** 1210,1216 ****
>         FOR_EACH_FRAME (rest, frame)
>   	x_flush (XFRAME (frame));
>       }
> !   else if (FRAME_X_P (f))
>       XFlush (FRAME_MAC_DISPLAY (f));
>     UNBLOCK_INPUT;
>   #endif /* TARGET_API_MAC_CARBON */
> --- 1210,1216 ----
>         FOR_EACH_FRAME (rest, frame)
>   	x_flush (XFRAME (frame));
>       }
> !   else if (FRAME_MAC_P (f))
>       XFlush (FRAME_MAC_DISPLAY (f));
>     UNBLOCK_INPUT;
>   #endif /* TARGET_API_MAC_CARBON */
> ***************
> *** 1410,1416 ****
>   XTframe_up_to_date (f)
>        struct frame *f;
>   {
> !   if (FRAME_X_P (f))
>       {
>         struct mac_display_info *dpyinfo = FRAME_MAC_DISPLAY_INFO (f);
>
> --- 1410,1416 ----
>   XTframe_up_to_date (f)
>        struct frame *f;
>   {
> !   if (FRAME_MAC_P (f))
>       {
>         struct mac_display_info *dpyinfo = FRAME_MAC_DISPLAY_INFO (f);
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Toolbars on MacOSX

[Jason Rumney]

Steven Tamm <steventamm@mac.com> writes:

> I've always had this idea that implementing tool-tips natively
> might be easier than porting over the w32 code (which creates a small
> highly-customized frame)... any thoughts?

With an Emacs frame, you have all the flexibility of Emacs buffers,
should anyone want to take advantage of it in future. With native
tooltips, you are probably stuck with text in a single font with a
single color.

Re: Toolbars on MacOSX

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 11 May 2004 19:48:38 -0700, Steven Tamm <steventamm@mac.com> said:

> I've checked in the XPM patch and enabled tool-bar-mode by default.

Thanks.  It seems all TABs in the image.c patch are converted into
spaces.  I can send you a diff to fix that if you need.

> I've played around with it for a while now, and it appears to have
> the same behaviour as the X and NT GUIs.

Actually, behaviour involving dragging is slightly different from that
in others.  Namely, holding a mouse button on one toolbar button
followed by releasing it on another one activates the command bound to
the latter button.  That is because the current event handling code
does not make use of dpyinfo->grabbed.

I'm thinking about adding a tool-bar control button on the title bar.

  http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_16_section_3.html#//apple_ref/doc/uid/20000961/BABIFCFJ
  (Figure 13-8)

I'd like to associate some (lisp-level) input event to the button, and
then bind a command that toggle the status of the toolbar.  If such a
feature is acceptable, what should the input event look like?

  1. [toolbar-control]
  2. [toolbar toolbar-control]
  3. [toolbar control]
  4. others

> The only major "hole" is the fact that tool-tips aren't supported
> with Carbon, yet.  In fact, tooltips might be the only "hole" in
> Carbon Emacs?  I've always had this idea that implementing tool-tips
> natively might be easier than porting over the w32 code (which
> creates a small highly-customized frame)... any thoughts?

The window creation/deletion part for tool-tips is already posted to
another list:

  http://mail.gnu.org/archive/html/emacs-pretest-bug/2004-04/msg00321.html

I'm currently working for its event handling part, which is almost
ready.  But it still has tiny problems and the scroll bar handling is
temporarily disabled now, so maybe I need another week to post the
patch.

I'm also working for context-aware mouse pointer shapes such as I-beam
or hand cursor, though it may be a minor "hole".

			     YAMAMOTO Mitsuharu
			mituharu@math.s.chiba-u.ac.jp

Re: Toolbars on MacOSX

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> > I've always had this idea that implementing tool-tips natively
> > might be easier than porting over the w32 code (which creates a small
> > highly-customized frame)... any thoughts?
> 
> With an Emacs frame, you have all the flexibility of Emacs buffers,
> should anyone want to take advantage of it in future.

FWIW, I regularly use tooltips containing faces, newlines, and non-latin
text, all of which I'd be a bit suspicious of the native toolkit
handling correctly (well, I guess faces definitely wouldn't work).

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Toolbars on MacOSX

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I'm thinking about adding a tool-bar control button on the title bar.
> 
>   http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_16_section_3.html#//apple_ref/doc/uid/20000961/BABIFCFJ
>   (Figure 13-8)
> 
> I'd like to associate some (lisp-level) input event to the button, and
> then bind a command that toggle the status of the toolbar.  If such a
> feature is acceptable, what should the input event look like?
> 
>   1. [toolbar-control]
>   2. [toolbar toolbar-control]
>   3. [toolbar control]
>   4. others

[title-bar tool-bar] perhaps ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

recenter-ratio (was: Re: Toolbars on MacOSX)

[Juri Linkov]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>   http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_16_section_3.html#//apple_ref/doc/uid/20000961/BABIFCFJ

I must say that Apple human interface guidelines define very
well-researched principles of implementing the good user interfaces.
I will not discuss its usefulness for Emacs design now, but one
chapter reminded me about an improvement I wanted to propose for
addition to Emacs.  The chapter at

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_16_section_4.html#//apple_ref/doc/uid/20000961-BACFHDHE

defines a concept of "visually centered placement", where the distance
from the bottom to the center should be approximately twice the
distance as that from the center to the top.  This applies to the
window positioning, but the same principle makes sense also for the
cursor positioning in Emacs.  Currently by default the cursor is
always placed exactly in the center of the window (i.e. on the window
line equal to the window height divided by the constant 2).  I use
a special key to scroll the window to adjust the place with the cursor
to more convenient vertical position (which is about 1/3 of the window
height).  Unfortunately, currently it is not possible to change the
hard-coded default cursor position.

The following patch introduces a new variable with the default value 2.
Its value defines a ratio at which the cursor is placed by default
from the top of the window relative to the window height.  It even
can be set to the Golden Ratio if one wishes so:

(setq recenter-ratio (expt (/ (1+ (sqrt 5)) 2) 2))

Index: emacs/src/window.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/window.c,v
retrieving revision 1.465
diff -u -r1.465 window.c
--- emacs/src/window.c	7 May 2004 00:43:49 -0000	1.465
+++ emacs/src/window.c	13 May 2004 04:34:11 -0000
@@ -120,6 +120,10 @@
 
 Lisp_Object Vother_window_scroll_buffer;
 
+Lisp_Object Vrecenter_ratio;
+
 /* Non-nil means it's function to call to display temp buffers.  */
 
 Lisp_Object Vtemp_buffer_show_function;
@@ -5172,7 +5221,7 @@
       int ht = window_internal_height (w);
 
       if (center_p)
-	arg = make_number (ht / 2);
+	arg = make_number (ht / XFLOATINT (Vrecenter_ratio));
       else if (XINT (arg) < 0)
 	arg = make_number (XINT (arg) + ht);
 
@@ -5241,7 +5290,7 @@
 
   lines = displayed_window_lines (w);
   if (NILP (arg))
-    XSETFASTINT (arg, lines / 2);
+    XSETFASTINT (arg, lines / XFLOATINT (Vrecenter_ratio));
   else
     {
       arg = Fprefix_numeric_value (arg);
@@ -6474,6 +6523,10 @@
 	       doc: /* If non-nil, this is a buffer and \\[scroll-other-window] should scroll its window.  */);
   Vother_window_scroll_buffer = Qnil;
 
+  DEFVAR_LISP ("recenter-ratio", &Vrecenter_ratio,
+	       doc: /* Ratio to recenter cursor.  */);
+  Vrecenter_ratio = 2;
+
   DEFVAR_BOOL ("pop-up-frames", &pop_up_frames,
 	       doc: /* *Non-nil means `display-buffer' should make a separate frame.  */);
   pop_up_frames = 0;

Index: emacs/src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.888
diff -u -r1.888 xdisp.c
--- emacs/src/xdisp.c	10 May 2004 11:16:37 -0000	1.888
+++ emacs/src/xdisp.c	13 May 2004 03:34:29 -0000
@@ -229,6 +229,8 @@
 extern Lisp_Object Qwhen;
 extern Lisp_Object Qhelp_echo;
 
+extern Lisp_Object Vrecenter_ratio;
+
 Lisp_Object Qoverriding_local_map, Qoverriding_terminal_local_map;
 Lisp_Object Qwindow_scroll_functions, Vwindow_scroll_functions;
 Lisp_Object Qredisplay_end_trigger_functions;
@@ -11722,7 +11724,7 @@
 	  /* If point does not appear, try to move point so it does
 	     appear. The desired matrix has been built above, so we
 	     can use it here.  */
-	  new_vpos = window_box_height (w) / 2;
+	  new_vpos = window_box_height (w) / XFLOATINT (Vrecenter_ratio);
 	}
 
       if (!make_cursor_line_fully_visible (w, 0))
@@ -11922,7 +11924,7 @@
   /* Finally, just choose place to start which centers point */
 
  recenter:
-  centering_position = window_box_height (w) / 2;
+  centering_position = window_box_height (w) / XFLOATINT (Vrecenter_ratio);
 
  point_at_top:
   /* Jump here with centering_position already set to 0.  */

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: recenter-ratio (was: Re: Toolbars on MacOSX)

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I must say that Apple human interface guidelines define very
> well-researched principles of implementing the good user interfaces.

Ha ha ha!

Be careful -- Apple _used_ to be good at this sort of thing (or at least
tried), but in recent years, they've seem to have simply gone nuts, and
apparently just do whatever seems kewl at the moment.

[One minor but irritating example:  they switched to the windoze
window-manager button layout which places the close button _right_ next
to the minimize/maximize buttons -- and _removed the labels_ from the
buttons when you're not mousing over them!  Mouse slip?  Whoops!]

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: recenter-ratio (was: Re: Toolbars on MacOSX)

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> The following patch introduces a new variable with the default value 2.
> Its value defines a ratio at which the cursor is placed by default
> from the top of the window relative to the window height.  It even
> can be set to the Golden Ratio if one wishes so:
> 
> (setq recenter-ratio (expt (/ (1+ (sqrt 5)) 2) 2))

> -	arg = make_number (ht / 2);
> +	arg = make_number (ht / XFLOATINT (Vrecenter_ratio));

> +  DEFVAR_LISP ("recenter-ratio", &Vrecenter_ratio,
> +	       doc: /* Ratio to recenter cursor.  */);
> +  Vrecenter_ratio = 2;

[...]

Nobody can understand how this variable needs to be set.  And the
same goes for the description.  Please make it the inverse instead,
something like
arg = make_number (ht * XFLOATINT (Vrecenter_ratio))

...
recenter_ratio = 0.5;

You also need to make sure that one can't crash Emacs with unusual
settings of the variable: For example, if on some small window heights
recentering fails to bring the cursor back on the window after the
change.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: recenter-ratio (was: Re: Toolbars on MacOSX)

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> 
> The following patch introduces a new variable with the default value 2.
> Its value defines a ratio at which the cursor is placed by default
> from the top of the window relative to the window height.  It even
> can be set to the Golden Ratio if one wishes so:
> 
> (setq recenter-ratio (expt (/ (1+ (sqrt 5)) 2) 2))

Very nice idea!  

But I would rather call it recenter-position and make it a float
between 0.0 and 1.0 indicating the relative distance from the top of
the window, i.e. the defaul being 0.5.

(value <= 0 means top line, value >= 1 means bottom line)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: recenter-ratio (was: Re: Toolbars on MacOSX)

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> @@ -11722,7 +11724,7 @@
>  	  /* If point does not appear, try to move point so it does
>  	     appear. The desired matrix has been built above, so we
>  	     can use it here.  */
> -	  new_vpos = window_box_height (w) / 2;
> +	  new_vpos = window_box_height (w) / XFLOATINT (Vrecenter_ratio);
>  	}
>  
>        if (!make_cursor_line_fully_visible (w, 0))
> @@ -11922,7 +11924,7 @@
>    /* Finally, just choose place to start which centers point */
>  
>   recenter:
> -  centering_position = window_box_height (w) / 2;
> +  centering_position = window_box_height (w) / XFLOATINT (Vrecenter_ratio);
>  
>   point_at_top:
>    /* Jump here with centering_position already set to 0.  */

I think you need to be careful to avoid an infinite redisplay loop when
recenter-ratio does not contain a number.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Toolbars on MacOSX

[YAMAMOTO Mitsuharu]

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

>>>>> On Wed, 12 May 2004 17:12:51 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I'm currently working for its event handling part, which is almost
> ready.  But it still has tiny problems and the scroll bar handling
> is temporarily disabled now, so maybe I need another week to post
> the patch.

The attached is a patch for tooltip support and "context-aware mouse
pointer shapes" support on Carbon Emacs.  Because it includes the
following patches, please backout them or use CVS version before
applying it if you've already applied them.

  http://mail.gnu.org/archive/html/emacs-devel/2004-03/msg00529.html
  http://mail.gnu.org/archive/html/emacs-pretest-bug/2004-04/msg00321.html
  http://mail.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00078.html

Although there are many rewritten parts in XTread_socket with respect
to scrollbar handing, I suppose its behaviour is same as before (for
good or bad).  The exception is that the `(PORTION . WHOLE)' part in a
scrollbar click event is now set to a plausible value.  So clicking a
scrollbar thumb no longer gets you to the end of buffer.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: diff-tip-shape.bz2 --]
[-- Type: application/octet-stream, Size: 19802 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Toolbars on MacOSX (seem to work)

[Steven Tamm]

Hi,

I've checked them in.  Tooltips seem to work appropriately.  There are 
a few colouring issues (i.e. not using my background colour in the 
whole tooltip, but instead using white in the top margin and bottom 
left; not having enough margin in the tooltip compared to the X11 
version; etc.).  However, they are minor, and I would suggest that 
other people with less whacked-out .emacs files figure it out.
Also, the scroll bars appear to be indented a few pixels.  But 
functionality, it seems to work.

Thanks for fixing one of the last features in the Carbon Port!

-Steven

On May 29, 2004, at 1:37 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 25 May 2004 21:47:49 -0700, Steven Tamm 
>>>>>> <steventamm@mac.com> said:
>
>> I went over most of these changes and I'd like to check them in.
>> Can you come up with a unified patch & ChangeLog if possible; I can
>> do the ChangeLog if you don't have the time.
>
> Hi.  I made a ChangeLog and a patch for the latest CVS. (I thought "a
> unified patch" meant a patch generated by "diff -u".  Was that right?)
> Thanks for you kind offer about ChangeLog.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
> <ChangeLog.bz2><diff-tip-shape2.bz2>

Re: Toolbars on MacOSX

[Andreas Schwab]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> The attached is a patch for tooltip support and "context-aware mouse
> pointer shapes" support on Carbon Emacs.

That doesn't compile on MacOS 10.1.3, kWindowIgnoreClicksAttribute is not
defined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."