From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tool-bar and multi-tty Date: Fri, 10 Oct 2008 23:32:15 +0200 Message-ID: References: <873aj56v2p.fsf@cyd.mit.edu> <87prm8fkjn.fsf@cyd.mit.edu> <873aj48cd9.fsf@cyd.mit.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1223674356 3690 80.91.229.12 (10 Oct 2008 21:32:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Oct 2008 21:32:36 +0000 (UTC) Cc: 1133@emacsbugs.donarmstrong.com, dann@ics.uci.edu, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 10 23:33:34 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KoPc5-0002Ik-PC for ged-emacs-devel@m.gmane.org; Fri, 10 Oct 2008 23:33:34 +0200 Original-Received: from localhost ([127.0.0.1]:54536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoPb1-0001Io-J5 for ged-emacs-devel@m.gmane.org; Fri, 10 Oct 2008 17:32:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoPaw-0001IU-As for emacs-devel@gnu.org; Fri, 10 Oct 2008 17:32:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoPav-0001I8-HO for emacs-devel@gnu.org; Fri, 10 Oct 2008 17:32:21 -0400 Original-Received: from [199.232.76.173] (port=34401 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoPav-0001Hz-7K for emacs-devel@gnu.org; Fri, 10 Oct 2008 17:32:21 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]:33250) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoPau-0003ZL-RS for emacs-devel@gnu.org; Fri, 10 Oct 2008 17:32:21 -0400 Original-Received: from HOME-C4E4A596F7 ([77.127.3.182]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K8J009TPL7WMLL3@i_mtaout4.012.net.il> for emacs-devel@gnu.org; Fri, 10 Oct 2008 23:33:38 +0200 (IST) In-reply-to: <873aj48cd9.fsf@cyd.mit.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104470 Archived-At: > From: Chong Yidong > 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.