pop-up tool-bar

pop-up tool-bar

[Drew Adams]

This code adds a minor mode, `tool-bar-here-mode', which is the same as
`tool-bar-mode', except that it affects only the selected frame.

It also adds a "button" named "Tool Bar" to the far right of the menu-bar
whenever the tool-bar is not visible (both `tool-bar-here-mode' and
`tool-bar-mode' are turned off). You can click the button to pop up the
tool-bar on the selected frame for the execution of a single command
(typically a tool-bar button click). The Tool Bar button is absent whenever
the tool-bar is visible, and vice versa.

The idea is to _conserve frame real estate_ but still have quick access to
the tool-bar: No reason to have a tool-bar on each frame. No reason to have
a tool-bar visible all the time; just pop it up when you need it.

Any interest in adding something like this to Emacs (file tool-bar.el)? It's
not intended to replace `tool-bar-mode'; it's just an alternative for people
who might want to use the tool-bar sometimes but don't want to sacrifice
real estate from every frame all the time.

 - Drew

---------------8<-----------------------------------

(define-key global-map [menu-bar temp-tool-bar]
  '(menu-item "Tool Bar" show-tool-bar-for-one-command
              :visible (and (not tool-bar-mode) (not tool-bar-here-mode))
              :enable (and (not tool-bar-mode) (not tool-bar-here-mode))
              :help "Use tool bar for one command"))

(setq menu-bar-final-items (append menu-bar-final-items (list
'temp-tool-bar)))


(define-minor-mode tool-bar-here-mode
  "Toggle use of the tool bar on this frame only.
With numeric ARG, display the tool bar if and only if ARG is positive.

See `tool-bar-add-item' and `tool-bar-add-item-from-menu' for
conveniently adding tool bar items."
  :init-value nil :global t :group 'mouse :group 'frames
  (and (display-images-p)
       (let ((lines (if tool-bar-here-mode 1 0)))
	 ;; Alter existing frame...
	 (modify-frame-parameters (selected-frame) (list (cons 'tool-bar-lines
lines))))
       (if (and tool-bar-here-mode
		(display-graphic-p)
		(= 1 (length (default-value 'tool-bar-map)))) ; not yet set up
	   (tool-bar-setup))))

(defun show-tool-bar-for-one-command ()
  "Pop up the tool bar so you can click a button.
The tool bar stays visible until one command is executed
\(whether or not it was initiated by clicking a button)."
  (interactive)
  (unwind-protect
      (let (evnt)
        (tool-bar-here-mode 99)         ; Show tool-bar
        (setq evnt (read-event))
        (push evnt unread-command-events))
    (tool-bar-here-mode -99)))          ; Hide tool-bar

Re: pop-up tool-bar

[Miguel Frasson]

"Drew Adams" <drew.adams@oracle.com> writes:

> This code adds a minor mode, `tool-bar-here-mode', which is the same as
> `tool-bar-mode', except that it affects only the selected frame.
> 
> It also adds a "button" named "Tool Bar" to the far right of the
> menu-bar whenever the tool-bar is not visible (both `tool-bar-here-mode'
> and `tool-bar-mode' are turned off). You can click the button to pop up
> the tool-bar on the selected frame for the execution of a single command
> (typically a tool-bar button click). The Tool Bar button is absent
> whenever the tool-bar is visible, and vice versa.

Hi

When I use the tool-bar-here-mode, and I show the toolbar clicking in the
menu item "Tool Bar"[1] , and then if I click in the window, the
mouse-down event is read, unactivating the toolbar.  The window size
changes, and the mouse-up event is in a different position, causing a
involuntier selection.  Could the toolbar deactivation be postponed to
avoid this?

Maybe, just disable the button could give a better feedback (that this
mechanism is on)

[1] It could be "ToolBar" because maybe it is not nice to have spaces in
top menu itens (top menu itens are separated by space).

Miguel Frasson.

-- 
Miguel Vinicius Santini Frasson
http://www.math.leidenuniv.nl/~frasson

RE: pop-up tool-bar

[Drew Adams]

Hi Miguel,

I see the pb. Good catch.

First, the name "Tool Bar" in the menu-bar. I don't know; I used to feel
like you do. Now I figure that since mouseover now highlights the
button/menu, there is no problem. Plus, the spacing between menus is
generally more than a single space, so it's not too difficult to parse,
visually. And ToolBar or Toolbar looks ugly to me. I suppose that if there's
a standard convention regarding this I should change the name - is there?.

Second, I don't understand your "Maybe..." paragraph. Is that related to the
pb you mentioned, or is it a different topic? Are you perhaps suggesting
here to disable the Tool Bar menu item, rather than hide it?

 - If so, yes, that could be done, but I think it's better to get rid of it
altogether - at least in the case where someone uses tool-bar-mode (shows
tool-bar everywhere all the time). Currently, if you turn off tool-bar-mode,
"Tool Bar" appears (assuming tool-bar-here-mode is on); if you turn on
tool-bar-mode, "Tool Bar" disappears. That makes sense to me.

 - If not, if this is a proposed solution to the selection pb, then disable
what button? when?

Third, in terms of the inadvertent selection pb: I don't have a good
solution. How can the tool-bar be hidden after the mouse-up event takes
place? The hiding needs to take place in the same command that shows it (and
that pushes the next event back onto unread-command-events).

The mouse-up event is two events removed from the event that triggers
command show-tool-bar-for-one-command: 1) click Tool Bar, 2) mouse-down, 3)
mouse-up. The Tool Bar click shows, then hides, the tool-bar, but the hiding
doesn't take place until the mouse-down.

I tried doing things like (if transient-mark-mode (deactivate-mark)) in the
unwind-protect (to not show the inadvertent selection), but that didn't
help. There's probably a simple solution I'm not seeing. Anyone?

Thanks for the pb report,

 - Drew

-----Original Message-----
From: Miguel Frasson

When I use the tool-bar-here-mode, and I show the toolbar clicking in the
menu item "Tool Bar"[1] , and then if I click in the window, the
mouse-down event is read, unactivating the toolbar.  The window size
changes, and the mouse-up event is in a different position, causing a
involuntier selection.  Could the toolbar deactivation be postponed to
avoid this?

Maybe, just disable the button could give a better feedback (that this
mechanism is on)

[1] It could be "ToolBar" because maybe it is not nice to have spaces in
top menu itens (top menu itens are separated by space).

Re: pop-up tool-bar

[Stefan Monnier]

> The mouse-up event is two events removed from the event that triggers
> command show-tool-bar-for-one-command: 1) click Tool Bar, 2) mouse-down, 3)
> mouse-up. The Tool Bar click shows, then hides, the tool-bar, but the hiding
> doesn't take place until the mouse-down.

It looks like the problem is that the event you get from read-event is not
"valid" any more after you remove the toolbar (becaue the position is
changed).

Using read-event is generally a source a trouble.  But the alternatives
aren't great either.  Maybe you can try something like the appended code.

Note: you should pay attention to the case where the frame has been deleted
by the next command.

Also, you declare your minor mode to be ":global t" but it is frame-local,
so you should add (make-variable-frame-local 'tool-bar-here-mode) somewhere
at the toplevel.


        Stefan


(defun add-hook-once (hook function append local)
  "Same as `add-hook', but FUN is only run once.
Also contrary to `add-hook', this is not idempotent."
  (let ((code (list 'lambda)))
    (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
    (add-hook hook code append local)))

...

(defun show-tool-bar-for-one-command ()
  "Pop up the tool bar so you can click a button.
The tool bar stays visible until one command is executed
\(whether or not it was initiated by clicking a button)."
  (interactive)
  (tool-bar-here-mode 1)
  (add-hook-once 'post-command-hook
                 `(lambda ()
                    ;; We're just now done with show-tool-bar-for-one-command.
                    (add-hook-once 'post-command-hook
                                   (lambda ()
                                     ;; We're done with the next command.
                                     (select-frame ',(selected-frame))
                                     (tool--bar-here-mode -1))))))

RE: pop-up tool-bar

[Drew Adams]

Good input. I wasn't even aware of `make-variable-frame-local', though I see
now that it's at least as old as Emacs 20.

I see you put "valid" in quotes, but I'm still not sure I know what you
mean. If the next event is a (valid) mouse-down, that's seems to be OK. The
mouse-down occurs at the right position in the buffer (as evidenced by the
highlighted region and cursor position), so I don't think that's the pb.
What happens, I think, is that when the tool-bar disappears, without your
having moved the mouse relative to the display, the mouse nevertheless has
moved relative to the displayed buffer -- so a region has been selected.

Now that I think of it, that could provide a solution, if we could be sure
to know the tool-bar height at all times in terms of # of buffer lines. We
could scroll the buffer down that number of lines, to compensate for the
buffer lines moving up relative to the display because the tool-bar
disappears. Maybe I'll give that a try. (Looking at tool-bar margins and
button-relief margins might be kind of a pain, though, and perhaps the
tool-bar height is not always an integral number of buffer lines, and maybe
we'll have to worry about different-size fonts - ugh.)

Can you elaborate on your "Note" - Is it meant to apply to my original code
or to your code (or both)? With my code, if I click "Buttons" and then
delete the frame instead of clicking a button, it seems to behave as I would
expect, at least on Windows: the frame is gone, that's all.

Maybe I'm doing something wrong, but your code doesn't work for me:

 - The tool-bar doesn't disappear afterward, no matter how I end
   (click a button or do something else.
 - "Buttons" doesn't come back to the menu-bar, and I can't get it
   back again, even by turning tool-bar-mode on, then off.
 - I get this error when I click "Buttons":
   show-tool-bar-for-one-command: Wrong number of arguments:
   (lambda (hook function append local)...

No doubt the first two symptoms are due to the last pb.

Don't you need an unwind-protect to be sure to turn the mode back off, in
case, for instance, the user does C-g -- or will the post-command-hook
always take care of that?

 - Drew


---------------
From: Stefan Monnier

It looks like the problem is that the event you get from read-event is not
"valid" any more after you remove the toolbar (becaue the position is
changed).

Using read-event is generally a source a trouble.  But the alternatives
aren't great either.  Maybe you can try something like the appended code.

Note: you should pay attention to the case where the frame has been deleted
by the next command.

Also, you declare your minor mode to be ":global t" but it is frame-local,
so you should add (make-variable-frame-local 'tool-bar-here-mode) somewhere
at the toplevel.


        Stefan


(defun add-hook-once (hook function append local)
  "Same as `add-hook', but FUN is only run once.
Also contrary to `add-hook', this is not idempotent."
  (let ((code (list 'lambda)))
    (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
    (add-hook hook code append local)))

...

(defun show-tool-bar-for-one-command ()
  "Pop up the tool bar so you can click a button.
The tool bar stays visible until one command is executed
\(whether or not it was initiated by clicking a button)."
  (interactive)
  (tool-bar-here-mode 1)
  (add-hook-once 'post-command-hook
                 `(lambda ()
                    ;; We're just now done with
show-tool-bar-for-one-command.
                    (add-hook-once 'post-command-hook
                                   (lambda ()
                                     ;; We're done with the next command.
                                     (select-frame ',(selected-frame))
                                     (tool--bar-here-mode -1))))))

RE: pop-up tool-bar

[Drew Adams]

That brings up a question. I don't know if this has been discussed and
decided already. If so, sorry.

Which is less disconcerting for you when you hide the tool-bar?

 - (current behavior) Move the buffer text up, so the same buffer line
starts the window as before you hid the tool-bar. That is, the buffer text
visible in the window doesn't change, but the physical position of the
window changes, so the text is effectively moved up, relative to the display
(rest of the world).

 - Move the buffer text down, to compensate for the tool-bar disappearance.
That is, replace the tool-bar with an equivalent number of lines of buffer
text. The text then stays in the same position relative to the display. This
would show a couple new lines at the window top, and, if the window size
remains the same, it would hide a couple lines previously shown at the
window bottom. The window doesn't show the same contents, but the contents
stay put (relative to everything in the world except the window).

I'm guessing that maybe the second would be better -- in most cases. The
text stays put -- just keep reading it. The first requires you to refind
where you were reading, because it has moved up a couple lines (relative to
your display).

What do you think?  If others agree, then the right thing to do would be to
fix this behavior. That would automatically fix the
behind-the-scenes-mouse-selection pb discussed previously (but I'm not
suggesting this to fix that). I realize there are arguments for each
behavior -- which is best overall?

Note: Obviously, if the window already shows the buffer beginning, then
there is no difference between the two behaviors (except perhaps at the
window bottom). And, in that case, the behind-the-scenes-mouse-selection pb
remains a pb.

 - Drew

FWIW, my Windows email client, Outlook, does what Emacs currently does.


-----Original Message-----
From: Drew Adams [mailto:drew.adams@oracle.com]

Now that I think of it, that could provide a solution, if we could be sure
to know the tool-bar height at all times in terms of # of buffer lines. We
could scroll the buffer down that number of lines, to compensate for the
buffer lines moving up relative to the display because the tool-bar
disappears. Maybe I'll give that a try. (Looking at tool-bar margins and
button-relief margins might be kind of a pain, though, and perhaps the
tool-bar height is not always an integral number of buffer lines, and maybe
we'll have to worry about different-size fonts - ugh.)

Re: pop-up tool-bar

[Richard Stallman]

     - Move the buffer text down, to compensate for the tool-bar disappearance.
    That is, replace the tool-bar with an equivalent number of lines of buffer
    text. The text then stays in the same position relative to the display. 

In general, line heights can vary, so this would require displaying a
partial line.

RE: pop-up tool-bar

[Drew Adams]

You're right, in terms of the implementation that I sent. That uses
`scroll-down', which depends on the height of the text at the top of the
window (and if a line has mixed font sizes, the maximum face height in the
line appears to be determinant).

The `tool-bar-lines' frame property is measured in line units that
correspond to the height of the font that is the `frame-font' frame
property. What's really needed is to scroll this amount, regardless of the
text font size.

I don't know of a way to do that in Lisp. It could be done in C, I'm sure.
The implementation I sent was intended as a proof of concept, to help us see
if a pop-up tool-bar would be useful.

In the email you quoted, I was not referring to this implementation, however
(that was in a separate email of the same thread). I was speaking in terms
of general principles, raising the question of which behavior is more
intuitive for users. If the compensatory scroll were exactly equal to
tool-bar-lines in height, then which would be preferable for a user?

I probably should have posed the choice differently, because, if the current
behavior for _displaying_ the tool-bar is kept, then you don't want the
buffer to scroll when the tool-bar _disappears_. That is, the same
mechanism, whatever it is, needs to be used for both displaying and removing
the tool-bar.

What I really meant was this choice:
-----------------------------------

 1. When displaying the tool-bar, let it _replace_ the first few lines
displayed in the window. When removing the tool-bar, _redisplay_ those
displaced lines. Then, the buffer lines don't jump up and down with the
appearance and disappearance of the tool-bar. The tool-bar just masks buffer
lines; the lines don't move up or down.

 2. When displaying the tool-bar, do as is done currently: shift the buffer
text down, so that the same lines remain visible. When removing the
tool-bar, move the buffer text back up. In this case, the tool-bar doesn't
replace (mask) lines; it is an addition.

I don't know which is preferable, in general. I would guess that it depends
on how often you display & remove the tool-bar. If you don't do that often,
then choice 2 is probably better. But if you display and remove the tool-bar
often, as in a pop-up tool-bar, then choice 1 is probably better.

I'm guessing that many (most) Emacs users will _not_ want to display the
tool-bar on each and every frame all the time. Some of them will want to use
the tool-bar, however (that's why we added it!), so a pop-up tool-bar that
is displayed only on the selected frame is a good compromise. For a pop-up
tool-bar, choice 1 may be preferable: let the temporary tool-bar _mask_ the
first few buffer lines, so that the buffer text doesn't visually shift up
and down for the temporary tool-bar display.

 - Drew

-----Original Message-----From: Richard Stallman

     - Move the buffer text down, to compensate for the tool-bar
disappearance.
    That is, replace the tool-bar with an equivalent number of lines of
buffer
    text. The text then stays in the same position relative to the display.

In general, line heights can vary, so this would require displaying a
partial line.

RE: pop-up tool-bar

[Drew Adams]

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

Please try this version of the pop-up tool-bar, and see what you think about
including it in Emacs as an option. I've added it to `tool-bar.el'; patch
attached.

The added code adds two new minor modes:

 - tool-bar-here-mode
 - tool-bar-pop-up-mode

The former is not strictly related to the pop-up tool-bar. It is simply the
same thing as `tool-bar-mode', but local to the selected frame only. I'd
propose it independently, even if folks decided against including the pop-up
mode. The pop-up tool-bar uses the frame-local tool-bar
(`tool-bar-here-mode') to do its work, but `tool-bar-here-mode' does not
need `tool-bar-pop-up-mode'.

So, with this addition, we will have three modes:

 - tool-bar-mode:        global (all frames)
 - tool-bar-here-mode:   local to selected frame
 - tool-bar-pop-up-mode: local to selected frame; tool-bar pops up on demand

Command `tool-bar-pop-up-mode' functions as a toggle only if neither
`tool-bar-mode' nor `tool-bar-here-mode' is on. If either of those modes is
on, then command `tool-bar-pop-up-mode' turns them both off and turns
`tool-bar-pop-up-mode' on (regardless of whether or not variable
`tool-bar-pop-up-mode' considers the pop-up mode to already be on).

Conversely, turning on one of the other tool-bar modes effectively nullifies
`tool-bar-pop-up-mode'. In terms of user-visible effect, the two are thus
mutually exclusive: either pop-up or not. By default, `tool-bar-mode' is on
(and the other two are off).

This version of the tool-bar pop-up code solves an interesting pb that arose
with the previous version when you clicked the mouse while the tool-bar was
temporarily visible. Because the tool-bar disappearance caused the buffer
text (the window) to move relative to an unmoving mouse, the mouse click
caused a region selection. That is, even though the mouse didn't move (you
just clicked), the movement of the _window_ relative to the mouse caused a
selection.

The fix was to scroll the buffer (window) `tool-bar-lines' to compensate for
the window movement. This scrolling happens for mouse events only, since
other events do not cause the problem (and you don't want to scroll the
buffer each time you click a tool-bar button).

It's easier to experience all of this than to describe it, so please give it
a try. To use the pop-up tool-bar, patch the file tool-bar.el, then load it
and `M-x tool-bar-popup-mode'. Then click "Buttons" in the menu-bar to pop
up the tool-bar for a single command (button click). Pound on it a bit, and
let me know what you think.

Thanks,

  Drew

[-- Attachment #2: diff-tool-bar-pop-up.txt --]
[-- Type: text/plain, Size: 4268 bytes --]

diff -c "c:/emacs-21.3.50/lisp/toolbar/tool-bar.el" "c:/drews-lisp-20/tool-bar-w-popup.el"
*** c:/emacs-21.3.50/lisp/toolbar/tool-bar.el	Mon Jul 26 09:42:32 2004
--- c:/drews-lisp-20/tool-bar-w-popup.el	Fri Oct  8 09:46:22 2004
***************
*** 40,45 ****
--- 40,49 ----
  
  ;;; Code:
  
+ 
+ \f
+ ;;; Global Tool Bar Mode ------------------------
+ 
  ;;;###autoload
  (define-minor-mode tool-bar-mode
    "Toggle use of the tool bar.
***************
*** 266,271 ****
--- 270,366 ----
  		     :help "Pop up the Help menu")
    )
  
+ 
+ 
+ \f
+ ;;; Local Tool Bar Mode -------------------------
+ 
+ (define-minor-mode tool-bar-here-mode
+   "Toggle use of the tool bar on this frame only.
+ With numeric ARG, display the tool bar if and only if ARG is positive.
+ 
+ See `tool-bar-add-item' and `tool-bar-add-item-from-menu' for
+ conveniently adding tool bar items."
+   :init-value nil :global t :group 'mouse :group 'frames
+   (and (display-images-p)
+        (let ((lines (if tool-bar-here-mode 1 0)))
+ 	 ;; Alter existing frame...
+ 	 (modify-frame-parameters (selected-frame) (list (cons 'tool-bar-lines lines))))
+        (if (and tool-bar-here-mode
+ 		(display-graphic-p)
+ 		(= 1 (length (default-value 'tool-bar-map)))) ; not yet set up
+ 	   (tool-bar-setup))))
+ 
+ (make-variable-frame-local 'tool-bar-here-mode)
+ 
+ 
+ \f
+ ;;; Pop-Up Tool Bar Mode ------------------------
+ 
+ ;; If either of the normal tool-bar modes is turned on, then
+ ;; `tool-bar-popup-mode' is not available.
+ (define-key global-map [menu-bar pop-up-tool-bar]
+   '(menu-item
+     "Buttons" show-tool-bar-for-one-command
+     :visible (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode))
+     :enable  (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode))
+     :help "Use tool bar for one command"))
+ 
+ (setq menu-bar-final-items (append menu-bar-final-items (list 'pop-up-tool-bar)))
+ 
+ 
+ 
+ (define-minor-mode tool-bar-pop-up-mode
+   "Toggle tool-bar pop-up.
+ With numeric ARG, turn on tool-bar pop-up if and only if ARG is positive.
+ 
+ Note: Command `tool-bar-pop-up-mode' functions as a toggle only
+       if neither `tool-bar-mode' nor `tool-bar-here-mode' is on.
+ 
+       If either of those modes is on, then command
+       `tool-bar-pop-up-mode' turns them both off and turns
+       `tool-bar-pop-up-mode' on."
+   :init-value nil :global t :group 'mouse :group 'frames
+   (when (or tool-bar-mode tool-bar-here-mode)
+     (setq tool-bar-pop-up-mode t)
+     (tool-bar-mode -99)
+     (tool-bar-here-mode -99)))
+ 
+ 
+ ;; Note: This treats mouse events specially: it scrolls the buffer
+ ;; text (window) down to compensate for the disappearance of the
+ ;; tool-bar.  That is, it replaces the tool-bar with an equivalent
+ ;; number of lines of buffer text.
+ ;;
+ ;; The reason for this is so that where you click the mouse when the
+ ;; tool-bar is visible corresponds to where the mouse is after the
+ ;; tool-bar disappears. Otherwise, the buffer text moves up, relative
+ ;; to the mouse, and a region is selected (without ever physically
+ ;; moving the mouse).
+ ;;
+ (defun show-tool-bar-for-one-command ()
+   "Pop up the tool bar so you can click a button.
+ The tool bar stays visible until one command is executed
+ \(whether or not it was initiated by clicking a button)."
+   (interactive)
+   (unless tool-bar-pop-up-mode
+     (error "You must turn on `tool-bar-pop-up-mode' to use this command"))
+   (let (evnt tb-lines)
+     (unwind-protect
+         (progn
+           (tool-bar-here-mode 99)     ; Show tool-bar
+           (setq evnt (read-event))
+           (push evnt unread-command-events))
+       (when (and (consp evnt)
+                  (member (event-basic-type (car evnt)) '(mouse-1 mouse-2 mouse-3)))
+         (setq tb-lines (cdr (assq 'tool-bar-lines (frame-parameters (selected-frame)))))
+         (when tb-lines (scroll-down tb-lines)))
+       (tool-bar-here-mode -99))))     ; Hide tool-bar
+ 
+ 
+ 
+ ;;;;;;;;;;;;;;;;;;
+ 
  (provide 'tool-bar)
  
  ;;; arch-tag: 15f30f0a-d0d7-4d50-bbb7-f48fd0c8582f

Diff finished.  Fri Oct 08 09:46:52 2004

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

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

Re: pop-up tool-bar

[Stefan]

> The fix was to scroll the buffer (window) `tool-bar-lines' to compensate for
> the window movement. This scrolling happens for mouse events only, since
> other events do not cause the problem (and you don't want to scroll the
> buffer each time you click a tool-bar button).

This kind of really super ugly nasty brittle dark hack should be kept for
extreme circumstances where there's really no other possible option.
What else have you tried?


        Stefan

Re: pop-up tool-bar

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

>> The fix was to scroll the buffer (window) `tool-bar-lines' to compensate for
>> the window movement. This scrolling happens for mouse events only, since
>> other events do not cause the problem (and you don't want to scroll the
>> buffer each time you click a tool-bar button).
>
> This kind of really super ugly nasty brittle dark hack should be kept for
> extreme circumstances where there's really no other possible option.
> What else have you tried?

Maybe we could let the toolbar disappear only with the button-release
event?  I think that would be more visually appealing anyhow, as you
can witness the depression of the button for as long as you desire.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: pop-up tool-bar

[Drew Adams]

Could folks please _try_ the code, before discussing its hypothetical
behavior?

Let's discuss this more concretely, in terms of the actual behavior. It
doesn't make sense to discuss hypothetical fixes to hypothetical pbs. Please
try it out first.

As I said to Stefan, I'm open wrt the implementation. But at least look at
what I've done.

Thanks,

  Drew

-----Original Message-----From: David Kastrup

Stefan <monnier@iro.umontreal.ca> writes:

>> The fix was to scroll the buffer (window) `tool-bar-lines' to compensate
for
>> the window movement. This scrolling happens for mouse events only, since
>> other events do not cause the problem (and you don't want to scroll the
>> buffer each time you click a tool-bar button).
>
> This kind of really super ugly nasty brittle dark hack should be kept for
> extreme circumstances where there's really no other possible option.
> What else have you tried?

Maybe we could let the toolbar disappear only with the button-release
event?  I think that would be more visually appealing anyhow, as you
can witness the depression of the button for as long as you desire.

RE: pop-up tool-bar

[Drew Adams]

What else have I tried? Well, I tried the code you offered, but it didn't
work for me, as I mentioned previously. You never replied to my report of
those pbs and my request for info on what I might be doing wrong (copied
below). Did you actually _run_ your code successfully?

If you have another suggestion, let's try it. But please _try_ this code
too, before dismissing it out of hand. Please pound on it, so we can see
just how brittle it is.

I'm curious: just what part of the quoted mouse-click fix do you find to be
a "really super ugly nasty brittle dark hack"?  What makes it so? Are you
speaking in terms of the code being brittle or the user experience (e.g.
being nonintuitive), or both?

You raise (I guess) two issues:

 - bad code
 - bad user interface

I'm open to improvement on both accounts. But let's be specific about what
is wrong. In terms of the code, please point out just what is brittle/bad
style/poor performance/whatever or suggest improvements. In terms of the UI,
please _try_ the code, and then report on what you find to be a pb. So far,
you seem to be reacting to a description of the behavior, and, as I said,
it's easier to experience the behavior than to describe it.

Abstractly name-calling the code or the UI doesn't help, I think. Please be
specific. I'm sure that you can come up with good, concrete improvements,
just as you did with the Info quotes highlighting. You already did offer a
concrete suggestion about `make-variable-frame-local', which I used.

I think we should offer users a pop-up tool-bar feature; that's all. I don't
push for my implementation of that feature; the best implementation should
be used. Frankly, I'd rather that someone else code this feature.

Thanks,

  Drew


-----Original Message-----From: Stefan

> The fix was to scroll the buffer (window) `tool-bar-lines' to compensate
for
> the window movement. This scrolling happens for mouse events only, since
> other events do not cause the problem (and you don't want to scroll the
> buffer each time you click a tool-bar button).

This kind of really super ugly nasty brittle dark hack should be kept for
extreme circumstances where there's really no other possible option.
What else have you tried?

        Stefan

-----Original Message-----From: Drew Adams

Good input. I wasn't even aware of `make-variable-frame-local', though I see
now that it's at least as old as Emacs 20.

I see you put "valid" in quotes, but I'm still not sure I know what you
mean. If the next event is a (valid) mouse-down, that's seems to be OK. The
mouse-down occurs at the right position in the buffer (as evidenced by the
highlighted region and cursor position), so I don't think that's the pb.
What happens, I think, is that when the tool-bar disappears, without your
having moved the mouse relative to the display, the mouse nevertheless has
moved relative to the displayed buffer -- so a region has been selected.

Now that I think of it, that could provide a solution, if we could be sure
to know the tool-bar height at all times in terms of # of buffer lines. We
could scroll the buffer down that number of lines, to compensate for the
buffer lines moving up relative to the display because the tool-bar
disappears. Maybe I'll give that a try. (Looking at tool-bar margins and
button-relief margins might be kind of a pain, though, and perhaps the
tool-bar height is not always an integral number of buffer lines, and maybe
we'll have to worry about different-size fonts - ugh.)

Can you elaborate on your "Note" - Is it meant to apply to my original code
or to your code (or both)? With my code, if I click "Buttons" and then
delete the frame instead of clicking a button, it seems to behave as I would
expect, at least on Windows: the frame is gone, that's all.

Maybe I'm doing something wrong, but your code doesn't work for me:

 - The tool-bar doesn't disappear afterward, no matter how I end
   (click a button or do something else.
 - "Buttons" doesn't come back to the menu-bar, and I can't get it
   back again, even by turning tool-bar-mode on, then off.
 - I get this error when I click "Buttons":
   show-tool-bar-for-one-command: Wrong number of arguments:
   (lambda (hook function append local)...

No doubt the first two symptoms are due to the last pb.

Don't you need an unwind-protect to be sure to turn the mode back off, in
case, for instance, the user does C-g -- or will the post-command-hook
always take care of that?

 - Drew

---------------From: Stefan Monnier

It looks like the problem is that the event you get from read-event is not
"valid" any more after you remove the toolbar (becaue the position is
changed).

Using read-event is generally a source a trouble.  But the alternatives
aren't great either.  Maybe you can try something like the appended code.

Note: you should pay attention to the case where the frame has been deleted
by the next command.

Also, you declare your minor mode to be ":global t" but it is frame-local,
so you should add (make-variable-frame-local 'tool-bar-here-mode) somewhere
at the toplevel.

        Stefan

(defun add-hook-once (hook function append local)
  "Same as `add-hook', but FUN is only run once.
Also contrary to `add-hook', this is not idempotent."
  (let ((code (list 'lambda)))
    (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
    (add-hook hook code append local)))

...

(defun show-tool-bar-for-one-command ()
  "Pop up the tool bar so you can click a button.
The tool bar stays visible until one command is executed
\(whether or not it was initiated by clicking a button)."
  (interactive)
  (tool-bar-here-mode 1)
  (add-hook-once 'post-command-hook
                 `(lambda ()
                    ;; We're just now done with
show-tool-bar-for-one-command.
                    (add-hook-once 'post-command-hook
                                   (lambda ()
                                     ;; We're done with the next command.
                                     (select-frame ',(selected-frame))
                                     (tool--bar-here-mode -1))))))

Re: pop-up tool-bar

[Stefan Monnier]

> What else have I tried? Well, I tried the code you offered, but it didn't
> work for me, as I mentioned previously.

Sorry, I thought the problem was obvious enough: just add an `&optional'
before the last two args of add-hook-once.

> You never replied to my report of those pbs and my request for info on
> what I might be doing wrong (copied below). Did you actually _run_ your
> code successfully?

No, my code was 100% untested, of course ;-).  It was only shown to give you
a hint of a possible other approach, not necessarily about the
implementation (I just used Elisp instead of English).  I don't even know
whether the approach might work.
And as for the "Note", it only referred to my suggested code, in your case
the frame should still be guaranteed to be live.

> If you have another suggestion, let's try it. But please _try_ this code
> too, before dismissing it out of hand. Please pound on it, so we can see
> just how brittle it is.

I'm sure it works.  But the approach used is brittle in the face of the fact
that scroll-down might fail, or in the face of variable height lines, or in
the face of changes to the scrolling behavior, or in the presence of other
events like mouse-4, or ...  I.e. it's brittle.

> I'm curious: just what part of the quoted mouse-click fix do you find to be
> a "really super ugly nasty brittle dark hack"?  What makes it so? Are you
> speaking in terms of the code being brittle or the user experience (e.g.
> being nonintuitive), or both?

> You raise (I guess) two issues:

>  - bad code
>  - bad user interface

Neither: it simply relies on way too many unguaranteed assumptions.

A good rule of thumb is that if a code works around a problem by reverting
a bad action rather than by eliminating it, it's a "nasty ugly brittle hack"
because reverting an action is usually not 100% possible and because it
will break every time the bad action changes.
Doesn't mean such code doesn't deserve to exist, but just that it "should be
kept for extreme circumstances where there's really no other possible
option".

> Abstractly name-calling the code or the UI doesn't help,
> I think. Please be specific. I'm sure that you can come up with good,
> concrete improvements, just as you did with the Info quotes
> highlighting. You already did offer a concrete suggestion about
> `make-variable-frame-local', which I used.

OK, you're right, I'm sorry, I should have been more diplomatic.
All the suggestion I can think of is to try and remove the tool-bar from
a timer function or from a post-command-hook so that it happens at a moment
of relative quietness.  Basically my suggestion decomposed in two parts:
1 - use post-command-hook in place of read-event to wait for the
    next event.
2 - use post-command-hook to delay the "remove tool-bar" to after the next
    command is executed.
I think point 2 is the one that holds promise of solving your problem (tho
it'll probably come with its own set of problems).


        Stefan

RE: pop-up tool-bar

[Drew Adams]

Sigh. I didn't ask you to be diplomatic. Diplomacy I don't need. I asked you
to be specific.

I would like to see specific reports of pbs, before we start envisioning
solutions to hypothetical pbs. In other words, breaking the code would be
useful: show some specific pbs you encounter. Pound on it; it's just code.

Don't get me wrong. I'm not pushing away, for all time, any abstract
argument about possible future pbs such as potential "changes to the
scrolling behavior", or principles like ~avoid/prevent pbs instead of
undoing/reverting them~, or discussions of relative advantages of different
design approaches. I hear what you're saying, and I agree with much of it.
I'd just like to _first_ address what this code does and what concrete
problems it has (now).

As I said, I'm not attached to the design or the implementation of this
feature; I'm promoting the feature, not the code. Before anyone (I, anyway)
spends energy redesigning or reimplementing, however, let's at least see
what this does, concretely.

Beyond finding specific pbs, the reason I'd like people to try it is to see
if such a feature (a pop-up tool bar) is something we want to add to Emacs,
regardless of its implementation.

 - Drew

-----Original Message-----Stefan Monnier
> Abstractly name-calling the code or the UI doesn't help, I think.
> Please be specific.

OK, you're right, I'm sorry, I should have been more diplomatic.
All the suggestion I can think of is to try and remove the tool-bar from
a timer function or from a post-command-hook so that it happens at a moment
of relative quietness.  Basically my suggestion decomposed in two parts:
1 - use post-command-hook in place of read-event to wait for the
    next event.
2 - use post-command-hook to delay the "remove tool-bar" to after the next
    command is executed.
I think point 2 is the one that holds promise of solving your problem (tho
it'll probably come with its own set of problems).

RE: pop-up tool-bar

[Drew Adams]

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

For those interested, attached is a new patch for the pop-up tool-bar
implementation that I sent previously. It fixes a minor bug (scroll-down
when bobp).

To use: patch the standard file tool-bar.el, load it, and `M-x
tool-bar-popup-mode'. Then click "Buttons" in the menu-bar to pop up the
tool-bar for a single command (button click).  - Drew

[-- Attachment #2: diff-tool-bar-pop-up-10-10.txt --]
[-- Type: text/plain, Size: 4411 bytes --]

cd c:/drews-lisp-20/
diff -c "c:/emacs-21.3.50/lisp/toolbar/tool-bar.el" "c:/drews-lisp-20/tool-bar-w-popup-10-10.el"
*** c:/emacs-21.3.50/lisp/toolbar/tool-bar.el	Mon Jul 26 09:42:32 2004
--- c:/drews-lisp-20/tool-bar-w-popup-10-10.el	Sun Oct 10 21:23:58 2004
***************
*** 40,45 ****
--- 40,49 ----
  
  ;;; Code:
  
+ 
+ \f
+ ;;; Global Tool Bar Mode ------------------------
+ 
  ;;;###autoload
  (define-minor-mode tool-bar-mode
    "Toggle use of the tool bar.
***************
*** 266,271 ****
--- 270,367 ----
  		     :help "Pop up the Help menu")
    )
  
+ 
+ 
+ \f
+ ;;; Local Tool Bar Mode -------------------------
+ 
+ (define-minor-mode tool-bar-here-mode
+   "Toggle use of the tool bar on this frame only.
+ With numeric ARG, display the tool bar if and only if ARG is positive.
+ 
+ See `tool-bar-add-item' and `tool-bar-add-item-from-menu' for
+ conveniently adding tool bar items."
+   :init-value nil :global t :group 'mouse :group 'frames
+   (and (display-images-p)
+        (let ((lines (if tool-bar-here-mode 1 0)))
+ 	 ;; Alter existing frame...
+ 	 (modify-frame-parameters (selected-frame) (list (cons 'tool-bar-lines lines))))
+        (if (and tool-bar-here-mode
+ 		(display-graphic-p)
+ 		(= 1 (length (default-value 'tool-bar-map)))) ; not yet set up
+ 	   (tool-bar-setup))))
+ 
+ (make-variable-frame-local 'tool-bar-here-mode)
+ 
+ 
+ \f
+ ;;; Pop-Up Tool Bar Mode ------------------------
+ 
+ ;; If either of the normal tool-bar modes is turned on, then
+ ;; `tool-bar-popup-mode' is not available.
+ (define-key global-map [menu-bar pop-up-tool-bar]
+   '(menu-item
+     "Buttons" show-tool-bar-for-one-command
+     :visible (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode))
+     :enable  (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode))
+     :help "Use tool bar for one command"))
+ 
+ (setq menu-bar-final-items (append menu-bar-final-items (list 'pop-up-tool-bar)))
+ 
+ 
+ 
+ (define-minor-mode tool-bar-pop-up-mode
+   "Toggle tool-bar pop-up.
+ With numeric ARG, turn on tool-bar pop-up if and only if ARG is positive.
+ 
+ Note: Command `tool-bar-pop-up-mode' functions as a toggle only
+       if neither `tool-bar-mode' nor `tool-bar-here-mode' is on.
+ 
+       If either of those modes is on, then command
+       `tool-bar-pop-up-mode' turns them both off and turns
+       `tool-bar-pop-up-mode' on."
+   :init-value nil :global t :group 'mouse :group 'frames
+   (when (or tool-bar-mode tool-bar-here-mode)
+     (setq tool-bar-pop-up-mode t)
+     (tool-bar-mode -99)
+     (tool-bar-here-mode -99)))
+ 
+ 
+ ;; Note: This treats mouse events specially: it scrolls the buffer
+ ;; text (window) down to compensate for the disappearance of the
+ ;; tool-bar.  That is, it replaces the tool-bar with an equivalent
+ ;; number of lines of buffer text.
+ ;;
+ ;; The reason for this is so that where you click the mouse when the
+ ;; tool-bar is visible corresponds to where the mouse is after the
+ ;; tool-bar disappears. Otherwise, the buffer text moves up, relative
+ ;; to the mouse, and a region is selected (without ever physically
+ ;; moving the mouse).
+ ;;
+ (defun show-tool-bar-for-one-command ()
+   "Pop up the tool bar so you can click a button.
+ The tool bar stays visible until one command is executed
+ \(whether or not it was initiated by clicking a button)."
+   (interactive)
+   (unless tool-bar-pop-up-mode
+     (error "You must turn on `tool-bar-pop-up-mode' to use this command"))
+   (let (evnt tb-lines)
+     (unwind-protect
+         (progn
+           (tool-bar-here-mode 99)     ; Show tool-bar
+           (setq evnt (read-event))
+           (push evnt unread-command-events))
+       (when (and (consp evnt)
+                  (member (event-basic-type (car evnt)) '(mouse-1 mouse-2 mouse-3)))
+         (setq tb-lines (cdr (assq 'tool-bar-lines (frame-parameters (selected-frame)))))
+         (condition-case nil
+             (when tb-lines (scroll-down tb-lines))
+           (error (tool-bar-here-mode -99)))) ; E.g. "Beginning of buffer" error
+       (tool-bar-here-mode -99))))     ; Hide tool-bar
+ 
+ 
+ ;;;;;;;;;;;;;;;;;;
+ 
  (provide 'tool-bar)
  
  ;;; arch-tag: 15f30f0a-d0d7-4d50-bbb7-f48fd0c8582f

Diff finished at Sun Oct 10 21:24:58

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

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

Re: pop-up tool-bar

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> Hi Miguel,
>
> I see the pb. Good catch.
>
> First, the name "Tool Bar" in the menu-bar. I don't know; I used to feel
> like you do. Now I figure that since mouseover now highlights the
> button/menu, there is no problem.

Disagree.  Additional hints are nice, but relying on them is a bad
idea.  For example, on a congested machine, visual feedback might be
seriously delayed.  The X protocol is optimized not to necessitate
round trip operations, and a forced roundtrip for user interaction is
not a universally good idea.  In addition, it might confuse screen
readers and similar stuff for visually impaired people (which might
not be able to properly discern highlighting, anyway).

Apart of which, my GTK toolkit does not provide mouse-over
highlighting before I actually click on a menu item in the meny bar.

> Plus, the spacing between menus is generally more than a single
> space, so it's not too difficult to parse, visually. And ToolBar or
> Toolbar looks ugly to me. I suppose that if there's a standard
> convention regarding this I should change the name - is there?.

While I would not want to condone StUdLyCaPs, "Toolbar" looks ok to
me.  Since the menu entry does not cause a permanent Toolbar,
"Buttons" would also be ok.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: pop-up tool-bar

[Drew Adams]

"Buttons" works.

I hear your point about feedback, and agree with the principle.

I'm not sure that a single space in "Tool Bar" would be a problem, but I
agree that it is more ambiguous (confusing) than having no space.

I'd also say that, in general, we should try to (and should be able to) come
up with a single word for any menu.

I'm curious as to whether there are standard conventions about this (how to
represent multiple-word menu names). In particular (obviously), whether
there is a GNU Emacs convention about this.

BTW, no one has replied concerning whether or not it would be good to add
such an on-demand tool-bar option to Emacs (after we get it right).

Thanks,

 - Drew

-----Original Message-----
From: David Kastrup [mailto:dak@gnu.org]
Sent: Thursday, October 07, 2004 1:09 PM
To: Drew Adams
Cc: Miguel Frasson; Emacs-Devel
Subject: Re: pop-up tool-bar


"Drew Adams" <drew.adams@oracle.com> writes:

> Hi Miguel,
>
> I see the pb. Good catch.
>
> First, the name "Tool Bar" in the menu-bar. I don't know; I used to feel
> like you do. Now I figure that since mouseover now highlights the
> button/menu, there is no problem.

Disagree.  Additional hints are nice, but relying on them is a bad
idea.  For example, on a congested machine, visual feedback might be
seriously delayed.  The X protocol is optimized not to necessitate
round trip operations, and a forced roundtrip for user interaction is
not a universally good idea.  In addition, it might confuse screen
readers and similar stuff for visually impaired people (which might
not be able to properly discern highlighting, anyway).

Apart of which, my GTK toolkit does not provide mouse-over
highlighting before I actually click on a menu item in the meny bar.

> Plus, the spacing between menus is generally more than a single
> space, so it's not too difficult to parse, visually. And ToolBar or
> Toolbar looks ugly to me. I suppose that if there's a standard
> convention regarding this I should change the name - is there?.

While I would not want to condone StUdLyCaPs, "Toolbar" looks ok to
me.  Since the menu entry does not cause a permanent Toolbar,
"Buttons" would also be ok.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: pop-up tool-bar

[Stefan Monnier]

> I'm curious as to whether there are standard conventions about this (how to
> represent multiple-word menu names). In particular (obviously), whether
> there is a GNU Emacs convention about this.

For what it's worth, the Elisp major mode uses "Emacs-Lisp" for its menu.
I think using a `-' as a word-separator is a fairly entrenched tradition at
least in Unix circles.


        Stefan

Re: pop-up tool-bar

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> BTW, no one has replied concerning whether or not it would be good
> to add such an on-demand tool-bar option to Emacs (after we get it
> right).

I am afraid that almost the only way to find out whether this is a
good idea is to actually try it for a while.  If one finds out that
the idea sucks after all, it might be a bit frustrating, but it
certainly is worth the effort to try.  And if feelings are mixed, one
can at least keep it a user option, or try finding how to improve
those areas where one things the behavior dissatisfactory.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: pop-up tool-bar

[Miguel Frasson]

"Drew Adams" <drew.adams@oracle.com> writes:

> Second, I don't understand your "Maybe..." paragraph. Is that related to the
> pb you mentioned, or is it a different topic? Are you perhaps suggesting
> here to disable the Tool Bar menu item, rather than hide it?
> 
>  - If so, yes, that could be done, but I think it's better to get rid of it
> altogether - at least in the case where someone uses tool-bar-mode (shows
> tool-bar everywhere all the time). Currently, if you turn off tool-bar-mode,
> "Tool Bar" appears (assuming tool-bar-here-mode is on); if you turn on
> tool-bar-mode, "Tool Bar" disappears. That makes sense to me.
> 
>  - If not, if this is a proposed solution to the selection pb, then disable
> what button? when?

My post, in this topic, was confising.  I meant something like: if
permanent toolbar, no "Buttons" menu item; if temporary toolbar (like, if
I use toolbar and it will disappear), then deactivate "Buttons" menu item.

> Third, in terms of the inadvertent selection pb: I don't have a good
> solution. How can the tool-bar be hidden after the mouse-up event takes
> place? The hiding needs to take place in the same command that shows it (and
> that pushes the next event back onto unread-command-events).
> 
> The mouse-up event is two events removed from the event that triggers
> command show-tool-bar-for-one-command: 1) click Tool Bar, 2) mouse-down, 3)
> mouse-up. The Tool Bar click shows, then hides, the tool-bar, but the hiding
> doesn't take place until the mouse-down.
> 
> I tried doing things like (if transient-mark-mode (deactivate-mark)) in the
> unwind-protect (to not show the inadvertent selection), but that didn't
> help. There's probably a simple solution I'm not seeing. Anyone?

I have not tried, but did you try something with `run-with-idle-timer'?
I don't know if Emacs is not idle meanwhile the mouse events are not
complete... if it is idle, this can provide a solution.

Its a good idea if the variable customizable variable `idle-update-delay'
(if I understand its function) is respected.  No problem if the toolbar
stays a little longer visible, if user likes so.  But I am not sure if
this is the meaning of `idle-update-delay' (maybe this is for tooltips or
so...)

Maybe the delay for the hide of the toolbar could be an option.  I don't
know whether this is a good idea.

Miguel.

-- 
Miguel Vinicius Santini Frasson
http://www.math.leidenuniv.nl/~frasson

Re: pop-up tool-bar

[Richard Stallman]

We do not want to add new features like this just now.  People can
discuss this topic if they want, but the feature won't be added until
after the next release.  As a result, today's discussions can't lead
to a final decision.

Re: pop-up tool-bar

[Stefan Monnier]

> The idea is to _conserve frame real estate_ but still have quick access to
> the tool-bar: No reason to have a tool-bar on each frame. No reason to have
> a tool-bar visible all the time; just pop it up when you need it.

The way I see it, the "Tool Bar button" should be the menubar itself, so
that whenever the mouse moves into the menubar area, the toolbar pops up (or
slides down ;-).

The same could be done to the menu bar.  This "auto hide" trick is one of
the rare developments in GUI-stuff that I find interesting (not that it's
new, tho: it's basically the same as the "pop up scrollbars" of SmallTalk).


        Stefan

RE: pop-up tool-bar

[Drew Adams]

I wanted to make that possibility available too, but didn't know how, from
Lisp. How is it done?

That behavior (just as the behavior I provided) should be a user option. I
can imagine lots of people (including me) _not_ wanting the tool-bar popping
up each time they move the mouse into the menu-bar area!

But, I definitely agree that other people would like that behavior, and it
would be good to provide it. Please tell us how.

Likewise, for a disappearing menu-bar. I personally hate such behavior (e.g.
Windows "Auto-hide the taskbar" option). But I know that some people like
it, especially when real estate is limited (e.g. on a laptop).

 - Drew

-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Stefan Monnier
Sent: Thursday, October 07, 2004 8:14 AM
To: Drew Adams
Cc: gnu-emacs-sources@gnu.org; Emacs-Devel
Subject: Re: pop-up tool-bar


> The idea is to _conserve frame real estate_ but still have quick access to
> the tool-bar: No reason to have a tool-bar on each frame. No reason to
have
> a tool-bar visible all the time; just pop it up when you need it.

The way I see it, the "Tool Bar button" should be the menubar itself, so
that whenever the mouse moves into the menubar area, the toolbar pops up (or
slides down ;-).

The same could be done to the menu bar.  This "auto hide" trick is one of
the rare developments in GUI-stuff that I find interesting (not that it's
new, tho: it's basically the same as the "pop up scrollbars" of SmallTalk).


        Stefan


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