From: "Jan D." <jan.h.d@swipnet.se>
Cc: Emacs-Devel <emacs-devel@gnu.org>
Subject: Re: suggestions on toolbar icons
Date: Thu, 17 Mar 2005 08:11:23 +0100 [thread overview]
Message-ID: <b6d71523c7ddaeb3c711e3b1103d4a9a@swipnet.se> (raw)
In-Reply-To: <MEEKKIABFKKDFJMPIOEBCECGCKAA.drew.adams@oracle.com>
> Some minor suggestions on toolbar icons (in Windows version, at
> least). No need for a lot of discussion. If any of this makes
> sense, good; if not, forget it.
>
The tool bar icons follow the Gnome stock items
(http://www.gtk.org/api/2.6/gtk/gtk-Stock-Items.html). I think Emacs
should follow them as close as it can, but we can of course change if
there is a good reason. There may be places in Emacs where a good fit
to those stock items can't be found, a change there is more likely.
You could try convice the Gnome project though. The point of stock
items is that themes may change them and applications that uses stock
items change appearence automatically. I have a patch for this for
Emacs, but as it only can be made to work for GTK, I have not installed
it yet.
If you really want a change to happen it would be more likely if you
have made the icons already (both bitmap and pixmap format), and shown
us a picture of them in Emacs.
> ALL BUFFERS
> -----------
>
> - Magnifying glass for search: This symbol is often used for
> Zoom, and it should be reserved for Zoom.
This is the Gnome stock find icon. Gnome has other icons for zoom.
> Suggestion: Use binoculars instead. (People don't search with
> magnifying glasses, anyway.)
>
> - Manuscript "X" for quit/exit: This symbol is often used for
> Delete. It's not too bad for quitting (killing) a buffer, but
> extending this to stand for "quit" generally (e.g. Info) is
> not good.
Gnome stock close. It is not used for delete in Gnome.
>
> Suggestion (my preference): Use the "exit" international
> symbol, which is an arrow leaving a box by its open end:
>
> +----+
> |
> <---- |
> |
> +----+
>
> Reserve the manuscript X for a real delete operation that
> cannot be assimilated with quitting. Whenever "delete" can be
> considered to mean quit, use the exit symbol.
>
> Alternative suggestion (but I prefer the one above): Use a
> non-manuscript X for quit (perhaps like the one Windows uses
> to close a frame, in the upper-right corner). It is only the
> _manuscript_ X that means delete and so can be confusing.
The Gnome stock quit could be used in info to quit, it is an arrow
pointing to an open door.
>
> - Tooltip for quit/exit:
>
> Suggestion: Use "Quit buffer", or "Delete buffer" instead of
> "Discard current buffer". I prefer "Quit buffer".
But "Quit Buffer" is not clear, it could mean the same as "Quit Info"
i.e. leaving the buffer intact, just switching to another buffer.
> INFO BUFFER
> -----------
>
> - Right arrow targeting yellow disk (go to named node):
>
> Suggestion: Arrow should point to the word "Node" or "Xxxx",
> not to a nameless yellow disk.
Gnome stock jump to.
>
> - Index:
>
> Suggestion: Add the letter "i" at the top of the icon
> (lowercase i, as in the information symbol, but without any
> enclosing circle). Split the "text" of each line, to show that
> these are entries in a list (index):
>
> _ _________ ___________
> _ _________ is better than ___________
> _ _________ ___________
Gnome stck index.
>
> - Arrows Previous, Next, Up, History Back, and History Forward:
> The structural-move icons (Previous, Next, Up) look too much
> like the chronological-move icons of Web browsers. I don't
> have a slam-dunk suggestion here, but we should come up with
> something better: browser users are used to these fat arrows
> for chronological moves. (It's best to avoid them altogether.)
Gnome stock left/right/up.
>
> Suggestion (my preference): U-turn arrows for chronological
> moves (right-then-left for back, left-then-right for forward);
> small arrows with ellipsis (indicating continuation) for
> structural moves: ...<-- and -->...
>
> By "U-turn" arrows, I don't mean the current curly arrows, but
> arrows that make a full sideways turn, like a U on its side.
>
> Alternative suggestion (but I prefer the one above): U-turn
> arrows for chronological moves; thin arrows for structural
> moves. (The current curly arrows would not be good for
> structural moves, because their shape suggests moving up and
> over.)
>
> Second alternative: If people don't like U-turn arrows, then
> use the fat arrows for chronological moves, a la web browsers.
You have to make these icon first before even considering a change.
And besides, the stock icons are there, so I don't think we should
change.
> - Tooltip for Up arrow: Should say "Go to parent node", not "Go
> up in the Info tree".
>
> - Home (Info-top-node): Icon is good. However...
>
> It takes you to the top node of the current file. Once there,
> the icon remains active, although it then does nothing. Either
> it should then be deactivated, or (better, IMO) `Info-top-node'
> should take you to (dir) if you are already at the top of a
> manual. We already have the notion of "Home" being relative
> (different manuals have different homes), so letting it have
> two levels this way would not be disruptive - in a sense there
> _are_ two levels of "home" (or "top").
I'll let someone more familiar with info internals comment on this.
> - Folder (for "file): This is _not_ good. A folder icon is used
> ubiquitously for, well, a folder - that is, a directory.
You are talking Microsoft products here I guess. This is the Gnome
stock open icon, I see no advantage to adopt a different set of
guidelines different from Gnome where the folder icon is not at all is
ubiquitously used for directory. Check out any Gnome application.
>
> Suggestion: The new-file and existing-file icons should be
> very similar. Use the current new-file icon for both, but, in
> the case of new-file, make it slightly smaller and have tiny
> "sparkle" lines emanating from it ("[ ]" here represents a
> slightly smaller version of the current new-file icon):
>
> ` | '
> - [ ] -
>
> ' | `
>
> Such sparkle lines (I don't know the real term) are often used
> to indicate action, change of state, newness, or creation.
Again, you have to make these icons first, but I'd be against changing
them, these are the most seen Gnome stock icons as almost all
applications have them. To make Emacs use something else serves no
point and is confusing to users.
> - Directory (Dired):
>
> Suggestion: Use a regular folder icon. Duh?
For what action? This is one place where no suitable Gnome stock item
exists, but assuming open file is not changhing, it need to be distinct
from it. Nobody has made any icon to replace it yet. But if someone
will do it, I think any suggestion should be similar to open file.
> - Help:
> Suggestion (my preference): Use a large, lowercase "i" in a
> circle, the international symbol for information.
Where do you find the standard that has these international symbols?
This is the Gnome stock help icon.
> - Preferences: This wrench+screwdriver icon is commonly used for
> Preferences, so it will be recognized by users. However,
> although common, it is not a good choice for preferences, and
> it can be confused with the kind of thing that is in the Tools
> menu.
Gnome stock preference icon, not easily confused by Gnome users.
I use a lot of different environments besides Gnome, but Gnome is the
GNU desktop environment, so aligning Emacs with Gnome where possible
makes sense. It does not make sense to me to change Emacs for the
benefit of any other platform. Now, if someone would like to make a
general solution, like adding the feature that an Emacs user can select
from several different icon themes or make his own theme, that would be
something.
Jan D.
next prev parent reply other threads:[~2005-03-17 7:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-17 1:27 suggestions on toolbar icons Drew Adams
2005-03-17 6:45 ` Lennart Borgman
2005-03-17 7:11 ` Jan D. [this message]
2005-03-17 17:08 ` Lennart Borgman
2005-03-17 20:06 ` Jan D.
2005-03-17 20:22 ` Lennart Borgman
2005-03-17 21:08 ` Jan D.
2005-03-17 18:33 ` Drew Adams
2005-03-17 19:41 ` Jan D.
2005-03-17 22:47 ` Drew Adams
2005-03-18 5:52 ` Jan D.
2005-03-18 7:36 ` David Kastrup
2005-03-18 17:37 ` Jan D.
2005-03-18 18:03 ` David Kastrup
2005-03-18 17:16 ` Drew Adams
2005-03-18 17:49 ` Jan D.
2005-03-17 21:44 ` David Kastrup
2005-03-18 1:40 ` Miles Bader
2005-03-18 17:16 ` Drew Adams
2005-03-18 17:56 ` David Kastrup
2005-03-18 18:20 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6d71523c7ddaeb3c711e3b1103d4a9a@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.