unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.

  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

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