bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1133: Tool-bar and multi-tty


From: Chong Yidong
Subject: bug#1133: Tool-bar and multi-tty
Date: Fri, 10 Oct 2008 15:43:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> What properties require X resources?  Can we refactor the code so that
> it only accesses X resources when the tool bar is about to be
> displayed?

OK, I looked further into this.  I was mistaken in my diagnosis of the
problem: it's not X resources that are the issue.

First, let me explain the problem more precisely.

To preload the tool-bar, we just need to make the following change to
tool-bar.el:

*** trunk/lisp/tool-bar.el.~1.19.~      2008-10-10 15:15:38.000000000 -0400
--- trunk/lisp/tool-bar.el      2008-10-10 15:16:57.000000000 -0400
***************
*** 262,273 ****
  
  (defun tool-bar-setup (&optional frame)
    (unless (or tool-bar-setup
!             (null tool-bar-mode)
!             ;; No-op if the initial frame is on a tty, deferring
!             ;; action until called from x-create-frame-with-faces.
!             ;; Tool-bar icons can depend on X settings, which are
!             ;; initially unavailable in this case.
!             (not (display-graphic-p frame)))
      (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.
--- 262,268 ----
  
  (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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]