unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: tromey@redhat.com
Cc: emacs-devel@gnu.org
Subject: Re: RFC: status icon support again
Date: Sun, 03 Feb 2008 18:23:40 +0900 (JST)	[thread overview]
Message-ID: <20080203.182340.144431297.mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <m3r6fu4hme.fsf@fleche.redhat.com>

>>>>> On Sun, 03 Feb 2008 00:35:37 -0700, Tom Tromey <tromey@redhat.com> said:

>>> 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.

I can imagine that they are usually used for different purposes.
Nevertheless I think they are very similar in attributes they have and
functionality they provide.

> 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 can't say users never want to make changes to some attributes of
status icons depending on the frame.

>>> 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 think the reason is rather apparent.  That provides uniform
interface to elisp programmers and they can use existing keymap
functions to manipulate those tables.

> 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
> overkill.

Are you possibly thinking about using one keymap per one status icon?
It's natural to use one keymap for the set of all status icons, just
as in tool bar keymaps.

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

Generally speaking, I don't think it's a good idea to add a new
feature that is implemented without understanding how the existing
related/similar features are implemented in the target application.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp




  reply	other threads:[~2008-02-03  9:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03  6:35 RFC: status icon support again Tom Tromey
2008-02-03  7:37 ` YAMAMOTO Mitsuharu
2008-02-03  7:35   ` Tom Tromey
2008-02-03  9:23     ` YAMAMOTO Mitsuharu [this message]
2008-02-03 17:18       ` Tom Tromey
2008-02-03 10:12     ` YAMAMOTO Mitsuharu
2008-02-03 17:11       ` Tom Tromey
2008-02-04  3:13     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080203.182340.144431297.mituharu@math.s.chiba-u.ac.jp \
    --to=mituharu@math.s.chiba-u.ac.jp \
    --cc=emacs-devel@gnu.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).