unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Toolbars on MacOSX
@ 2004-05-04 21:16 Piet van Oostrum
  2004-05-11  9:49 ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 16+ messages in thread
From: Piet van Oostrum @ 2004-05-04 21:16 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-11  9:49 ` YAMAMOTO Mitsuharu
@ 2004-05-11  9:48   ` Kim F. Storm
  2004-05-12  2:48   ` Steven Tamm
  1 sibling, 0 replies; 16+ messages in thread
From: Kim F. Storm @ 2004-05-11  9:48 UTC (permalink / raw)
  Cc: Piet van Oostrum, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-04 21:16 Toolbars on MacOSX Piet van Oostrum
@ 2004-05-11  9:49 ` YAMAMOTO Mitsuharu
  2004-05-11  9:48   ` Kim F. Storm
  2004-05-12  2:48   ` Steven Tamm
  0 siblings, 2 replies; 16+ messages in thread
From: YAMAMOTO Mitsuharu @ 2004-05-11  9:49 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> 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);

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-11  9:49 ` YAMAMOTO Mitsuharu
  2004-05-11  9:48   ` Kim F. Storm
@ 2004-05-12  2:48   ` Steven Tamm
  2004-05-12  8:07     ` Jason Rumney
  2004-05-12  8:12     ` YAMAMOTO Mitsuharu
  1 sibling, 2 replies; 16+ messages in thread
From: Steven Tamm @ 2004-05-12  2:48 UTC (permalink / raw)
  Cc: Piet van Oostrum, Kim F. Storm

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-12  2:48   ` Steven Tamm
@ 2004-05-12  8:07     ` Jason Rumney
  2004-05-12  8:44       ` Miles Bader
  2004-05-12  8:12     ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 16+ messages in thread
From: Jason Rumney @ 2004-05-12  8:07 UTC (permalink / raw)
  Cc: Piet van Oostrum, Kim F. Storm, YAMAMOTO Mitsuharu, emacs-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-12  2:48   ` Steven Tamm
  2004-05-12  8:07     ` Jason Rumney
@ 2004-05-12  8:12     ` YAMAMOTO Mitsuharu
  2004-05-12 14:13       ` Kim F. Storm
                         ` (2 more replies)
  1 sibling, 3 replies; 16+ messages in thread
From: YAMAMOTO Mitsuharu @ 2004-05-12  8:12 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-12  8:07     ` Jason Rumney
@ 2004-05-12  8:44       ` Miles Bader
  0 siblings, 0 replies; 16+ messages in thread
From: Miles Bader @ 2004-05-12  8:44 UTC (permalink / raw)
  Cc: Steven Tamm, Piet van Oostrum, emacs-devel, YAMAMOTO Mitsuharu,
	Kim F. Storm

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-12  8:12     ` YAMAMOTO Mitsuharu
@ 2004-05-12 14:13       ` Kim F. Storm
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
  2004-05-22  8:15       ` Toolbars on MacOSX YAMAMOTO Mitsuharu
  2 siblings, 0 replies; 16+ messages in thread
From: Kim F. Storm @ 2004-05-12 14:13 UTC (permalink / raw)
  Cc: steventamm, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* recenter-ratio (was: Re: Toolbars on MacOSX)
  2004-05-12  8:12     ` YAMAMOTO Mitsuharu
  2004-05-12 14:13       ` Kim F. Storm
@ 2004-05-13  4:33       ` Juri Linkov
  2004-05-13  5:04         ` Miles Bader
                           ` (3 more replies)
  2004-05-22  8:15       ` Toolbars on MacOSX YAMAMOTO Mitsuharu
  2 siblings, 4 replies; 16+ messages in thread
From: Juri Linkov @ 2004-05-13  4:33 UTC (permalink / raw)
  Cc: steventamm, emacs-devel

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/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: recenter-ratio (was: Re: Toolbars on MacOSX)
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
@ 2004-05-13  5:04         ` Miles Bader
  2004-05-13  8:02         ` David Kastrup
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 16+ messages in thread
From: Miles Bader @ 2004-05-13  5:04 UTC (permalink / raw)
  Cc: steventamm, YAMAMOTO Mitsuharu, emacs-devel

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!

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: recenter-ratio (was: Re: Toolbars on MacOSX)
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
  2004-05-13  5:04         ` Miles Bader
@ 2004-05-13  8:02         ` David Kastrup
  2004-05-13  8:46         ` Kim F. Storm
  2004-05-13  9:58         ` Andreas Schwab
  3 siblings, 0 replies; 16+ messages in thread
From: David Kastrup @ 2004-05-13  8:02 UTC (permalink / raw)
  Cc: steventamm, YAMAMOTO Mitsuharu, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: recenter-ratio (was: Re: Toolbars on MacOSX)
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
  2004-05-13  5:04         ` Miles Bader
  2004-05-13  8:02         ` David Kastrup
@ 2004-05-13  8:46         ` Kim F. Storm
  2004-05-13  9:58         ` Andreas Schwab
  3 siblings, 0 replies; 16+ messages in thread
From: Kim F. Storm @ 2004-05-13  8:46 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: recenter-ratio (was: Re: Toolbars on MacOSX)
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
                           ` (2 preceding siblings ...)
  2004-05-13  8:46         ` Kim F. Storm
@ 2004-05-13  9:58         ` Andreas Schwab
  3 siblings, 0 replies; 16+ messages in thread
From: Andreas Schwab @ 2004-05-13  9:58 UTC (permalink / raw)
  Cc: steventamm, YAMAMOTO Mitsuharu, emacs-devel

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."

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-12  8:12     ` YAMAMOTO Mitsuharu
  2004-05-12 14:13       ` Kim F. Storm
  2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
@ 2004-05-22  8:15       ` YAMAMOTO Mitsuharu
       [not found]         ` <D73CE7B6-AECF-11D8-A841-00039390AB82@mac.com>
  2004-06-05 15:53         ` Toolbars on MacOSX Andreas Schwab
  2 siblings, 2 replies; 16+ messages in thread
From: YAMAMOTO Mitsuharu @ 2004-05-22  8:15 UTC (permalink / raw)


[-- 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX (seem to work)
       [not found]           ` <wlzn7rhbmp.wl@church.math.s.chiba-u.ac.jp>
@ 2004-05-30  0:43             ` Steven Tamm
  0 siblings, 0 replies; 16+ messages in thread
From: Steven Tamm @ 2004-05-30  0:43 UTC (permalink / raw)
  Cc: emacs-devel

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>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Toolbars on MacOSX
  2004-05-22  8:15       ` Toolbars on MacOSX YAMAMOTO Mitsuharu
       [not found]         ` <D73CE7B6-AECF-11D8-A841-00039390AB82@mac.com>
@ 2004-06-05 15:53         ` Andreas Schwab
  1 sibling, 0 replies; 16+ messages in thread
From: Andreas Schwab @ 2004-06-05 15:53 UTC (permalink / raw)
  Cc: emacs-devel

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."

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2004-06-05 15:53 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-04 21:16 Toolbars on MacOSX Piet van Oostrum
2004-05-11  9:49 ` YAMAMOTO Mitsuharu
2004-05-11  9:48   ` Kim F. Storm
2004-05-12  2:48   ` Steven Tamm
2004-05-12  8:07     ` Jason Rumney
2004-05-12  8:44       ` Miles Bader
2004-05-12  8:12     ` YAMAMOTO Mitsuharu
2004-05-12 14:13       ` Kim F. Storm
2004-05-13  4:33       ` recenter-ratio (was: Re: Toolbars on MacOSX) Juri Linkov
2004-05-13  5:04         ` Miles Bader
2004-05-13  8:02         ` David Kastrup
2004-05-13  8:46         ` Kim F. Storm
2004-05-13  9:58         ` Andreas Schwab
2004-05-22  8:15       ` Toolbars on MacOSX YAMAMOTO Mitsuharu
     [not found]         ` <D73CE7B6-AECF-11D8-A841-00039390AB82@mac.com>
     [not found]           ` <wlzn7rhbmp.wl@church.math.s.chiba-u.ac.jp>
2004-05-30  0:43             ` Toolbars on MacOSX (seem to work) Steven Tamm
2004-06-05 15:53         ` Toolbars on MacOSX Andreas Schwab

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).