[Top][All Lists]

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

Re: RFC: status icon support again

From: Tom Tromey
Subject: Re: RFC: status icon support again
Date: Sun, 03 Feb 2008 00:35:37 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux)

>>>>> ">" == YAMAMOTO Mitsuharu <address@hidden> writes:

>>>>> On Sat, 02 Feb 2008 23:35:18 -0700, Tom Tromey <address@hidden> said:
>> * I looked a little at rewriting so status icons would be part of
>> keymaps, but this looked complicated and I didn't see a benefit --
>> in particular this code has no relation to toolbars at all, and I
>> didn't think any code could be shared.

>> Of course code cannot be shared between them without changing the
>> fundamental design of your code for status icons.  Do you claim that
>> status icons and tool bar icons are inherently different enough to
>> resort to different design in implementation code and also in elisp
>> interface?

I don't want to make any very strong claims.  I am not really expert
at Emacs internals.

>> Another benefit of the use of keymaps is that it makes easier to move
>> between status icons from/to tool bar icons (and possibly also between
>> menu bar items?), in the case that the use of either is
>> impossible/inappropriate.

In my view toolbars and the status area are very different; though it
is true that there is some overlap between them.

Pretty much every buffer can be expected to have a toolbar.  It is
typical for the toolbar to change as the user uses different parts of
an application.

On the other hand, space for status icons is limited and generally
they should be used for more "global" things.  It would be
disconcerting if the visible status icons changed frequently, say in
response to switching buffers.

In an earlier message you mentioned toolbars being integrated into
redisplay.  This was one disconnect for me -- I don't see how, or why,
we would want to integrate status icons into redisplay.  They are not
connected to a frame at all.

>> I think user-configurable event dispatcher
>> tables should always be implemented as keymaps unless there are strong
>> reasons to avoid them.

May I ask why?

I have basically two reasons for the approach I have taken.

First, it is simple and easy to understand.  In Gtk, a status icon
only has two possible events; using a keymap for this seemed like

Second, unlike the keymap idea, I knew how to implement it this way.
I suppose ignorance is no excuse, though.

Could you help with the next reimplementation?


reply via email to

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