bug#1133: Tool-bar and multi-tty

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: dann@ics.uci.edu,  1133@emacsbugs.donarmstrong.com,  emacs-devel@gnu.org
> Date: Fri, 10 Oct 2008 15:43:30 -0400
> 
>   (defun tool-bar-setup (&optional frame)
>     (unless (or tool-bar-setup
> ! 	      (null tool-bar-mode))
>       (with-selected-frame (or frame (selected-frame))
>         ;; People say it's bad to have EXIT on the tool bar, since users
>         ;; might inadvertently click that button.
> 
> 
> Suppose you apply this patch, and start emacs on a tty with `emacs -nw',
> then start a server with M-x server-start RET.  Then, open a graphical
> client with `emacsclient -c'.
> 
> The result is an ugly, low-color toolbar; not the usual high-color
> toolbar.
> 
> I thought this was due to GTK settings, but further investigation
> reveals that the low-color settings come from these lines in
> tool-bar-local-item-from-menu:
> 
>  (image-exp `(tool-bar-find-image
>    (if (display-color-p)
>        ',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec)
>      ',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))))
> 
> Calling tool-bar-local-item-from-menu from the tty loads the lo-spec
> images, whereas deferring this call until X is started up loads the
> hi-spec images.  But deferring the call, as I suggested, doesn't seem to
> be satisfactory either.
> 
> Probably the way to do this correctly is to change update_frame_tool_bar
> to dynamically update the icons to deal with the latest display
> settings.
> 
> Alternatively, we could drop support for "low-color" images on the
> toolbar entirely.

I'd rather not drop support for low-color images, unless the dynamic
update you are suggesting turns out to be too hard.  Dynamically
updating the icons sounds right to me, especially since we could have
several frames with different color capabilities, at least in
principle.