suggestions on toolbar icons

suggestions on toolbar icons

[Drew Adams]

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.

ALL BUFFERS
-----------

 - Magnifying glass for search: This symbol is often used for
   Zoom, and it should be reserved 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.

   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.

 - Tooltip for quit/exit:

   Suggestion: Use "Quit buffer", or "Delete buffer" instead of
   "Discard current buffer". I prefer "Quit 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.

 - 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 ___________
   _ _________                ___________

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

   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.

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


EDITING BUFFER
--------------

 - Folder (for "file): This is _not_ good. A folder icon is used
   ubiquitously for, well, a folder - that is, a directory.

   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.

   Alternative suggestion (perhaps better): Put just a tiny
   sparkle star in one corner of the new-file icon. Example:


http://did.mat.uni-bayreuth.de/geonext/ru/start.html?CONTENT=help&head=Dokum
entation

 - Directory (Dired):

   Suggestion: Use a regular folder icon. Duh?

 - Tooltip for Directory:

   Suggestion: Mention "Dired" - "Operate on files in directory
   (Dired)".

 - Help:

   Suggestion (my preference): Use a large, lowercase "i" in a
   circle, the international symbol for information.

   Alternative suggestion (but I prefer the one above): Use a
   question mark (?) in a circle. A question mark is closer to
   the meaning of Help, but Emacs Help is more than help; it's
   really an Information center.

   BTW - Why is the Help icon not available in an Info buffer (in
   all buffers)?

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

   Suggestion: Use an icon with a pair of checkboxes, one
   checked, one unchecked. Examples:


http://did.mat.uni-bayreuth.de/geonext/ru/start.html?CONTENT=help&head=Dokum
entation,
   http://www.tobiasjung.net/html/popmonitor.php,
   http://www.databeacon.com/rele60/rele/user/help/general_preferences.htm,
   http://www.ej-technologies.com/products/install4j/tour.html,
   http://www.aurora-solutions.net/trn/discover/userguide.htm,
   http://argouml.tigris.org/documentation/defaulthtml/manual/ch09s04.html,
   http://www.boreas.dti.ne.jp/~air1/ud/ud_sr1.html,
   http://wildfruit.gayone.com/sys13/tour/2.html,
   http://www.inklineglobal.com/products/mb/.




In GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on
 NONIQPC Distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (3.3) --cflags
 -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
 -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
 -I../../zlib-1.2.2/include'

Re: suggestions on toolbar icons

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

I do not use the toolbar very often, but I think it is good to have it as
easy to understand as possible. I agree with much of your suggestions, but
there are some things I would like a bit different:


>  - Magnifying glass for search: This symbol is often used for
>    Zoom, and it should be reserved for Zoom.
>
>    Suggestion: Use binoculars instead. (People don't search with
>    magnifying glasses, anyway.)

I believe magnifying glass is common for search. Firefox uses it for
example. And it is perhaps also a bit easier to make a small picture of a
magnigying glass than of binoculars.


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

Why not use the fat arrows for chronological moves?

Why do we need the arrows for Prev, Next and Up? There are already text
links for this in the Info buffer. If you are using a single window they are
right under the toolbar.


>  - Help:

To me the help toolbar seems to contain many items that have no connection
with help.

Re: suggestions on toolbar icons

[Jan D.]

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

Re: suggestions on toolbar icons

[Lennart Borgman]

----- Original Message ----- 
From: "Jan D." <jan.h.d@swipnet.se>

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

Thanks for this pointer.


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

I can actually not find that on the page above. That is I can find
GTK_STOCK_GO_UP, but there is as far as I can see nothing like
GTK_STOCK_GO_PREVIOUS (or LEFT). It seems like they forgot to distinguish
between GTK_STOCK_GO_BACK (ie a chronological move) and ...PREVIOUS (ie a
structural move).

I think this is pretty bad if you need both. On the page above they have
actually used filled arrows for structural moves (see the top). Is that
consistent with their suggestions?

I think we should distinguish between structural and cronological moves. As
I said in another message perhaps we do not need the structural moves in the
toolbar since they are in the text.

Re: suggestions on toolbar icons

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

>> Gnome stock left/right/up.
>
> I can actually not find that on the page above. That is I can find
> GTK_STOCK_GO_UP, but there is as far as I can see nothing like
> GTK_STOCK_GO_PREVIOUS (or LEFT). It seems like they forgot to 
> distinguish
> between GTK_STOCK_GO_BACK (ie a chronological move) and ...PREVIOUS 
> (ie a
> structural move).

No, previous and next are missing.  As is open directory.  I guess they 
make stock items for the most common operations, previus/next/open 
directory does not seem to be among them.

>
> I think this is pretty bad if you need both. On the page above they 
> have
> actually used filled arrows for structural moves (see the top). Is that
> consistent with their suggestions?

They really don't say mush on the issue, the guidelines are at 
http://developer.gnome.org/projects/gup/hig/2.0/.  Some applications, 
like gthumb, uses a filled arrow that points into a "file"-like 
background, see attachement.


[-- Attachment #2: prev.jpg --]
[-- Type: image/jpeg, Size: 1094 bytes --]

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]



	Jan D.



[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: suggestions on toolbar icons

[Lennart Borgman]

----- Original Message ----- 
From: "Jan D." <jan.h.d@swipnet.se>

> No, previous and next are missing.
..
> > I think this is pretty bad if you need both. On the page above they
> > have
> > actually used filled arrows for structural moves (see the top). Is that
> > consistent with their suggestions?
>
> They really don't say mush on the issue, the guidelines are at
> http://developer.gnome.org/projects/gup/hig/2.0/.  Some applications,
> like gthumb, uses a filled arrow that points into a "file"-like
> background, see attachement.

Funny enough this was one of the idea I had. It kind of make sense to me -
"moving withing the document tree structure".

Can't we borrow this? Is there something similar for up? (The gnome icon for
up is inconsistent, probably because they have failed to see the difference
between structural and chronological moves which Drew pointed out. There is
no chronological up... - in three dimensional space.)


----------------------------------------------------------------------------
----






----------------------------------------------------------------------------
----


>
>
> Jan D.
>
>
>

Re: suggestions on toolbar icons

[Jan D.]

>>
>> They really don't say mush on the issue, the guidelines are at
>> http://developer.gnome.org/projects/gup/hig/2.0/.  Some applications,
>> like gthumb, uses a filled arrow that points into a "file"-like
>> background, see attachement.
>
> Funny enough this was one of the idea I had. It kind of make sense to 
> me -
> "moving withing the document tree structure".
>
> Can't we borrow this?

I guess so.  Note that newer versions of gthumb has other icons for 
this.

>  Is there something similar for up?

Not that I know of.

	Jan D.

RE: suggestions on toolbar icons

[Drew Adams]

I won't belabor this, but I do have a few responses. Your reply is, in
essence, "GNOOOOMMME" (shades of Allen Ginsberg w/ "Oommmm"). If GNOME's
choices are not always the best, we will nevertheless live with it.

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

    >  - Directory (Dired):
    >    Suggestion: Use a regular folder icon. Duh?

GTK_STOCK_DIRECTORY _is_ a standard folder icon. This _agrees_ with my
suggestion (not at all Microsoftesque) that a standard folder icon should be
used for Dired. If you think advocating that a folder icon be used to
represent a folder editor implies advocating adopting Microsoft conventions,
then I would suggest that you are overly zealous in your struggle. Oommmm.

Similarly, GTK_STOCK_FILE is a standard file icon. This _agrees_ with my
suggestion to keep this icon.

The question then is, what about new-file vs existing-file? I suggested
using something similar for both of these. GTK_STOCK_NEW is in fact
_identical_ to GTK_STOCK_FILE, showing that GNOME and I think alike on this
one.

Emacs, however, currently uses the _directory_ icon, GTK_STOCK_DIRECTORY for
opening an existing file - it happens that this icon is identical to
GTK_STOCK_OPEN. Using a folder to represent opening a _file_ flies in the
face of every UI I've ever seen. Are you sure that GTK_STOCK_OPEN is
intended for files, not for directories? Does using it for opening a file
make sense to you?

Finally, if you are going to use GNOME as a litmus test, then why not be
consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for Info's
Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which is, presumably,
chronological) - as in Web browsers? Why use the GNOME undo/redo icon
(GTK_STOCK_REDO) for Back and Forward? I suspect that we are already
departing dangerously from the GNOME Oommmmm. It's a slippery slope...

    The Gnome stock quit could be used in info to quit, it is an arrow
    pointing to an open door.

Yes, that's better, although the icon is ambiguous (entering or exiting?)
and is not very clear (the door is hard to distinguish). I prefer the
international exit sign - the one you look for when there's a fire.

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

"Quit" is clearer (and more common) than "discard". At this level, the
distinction between leaving the buffer intact and killing it is not
important - and "discard" doesn't help with this distinction anyway.

    The point of stock items is that themes may change them and
    applications that uses stock items change appearence automatically.

I think that Emacs could do better than what is there now, but I do respect
that general argument. I wasn't aware of this.

    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.

This is not about "any other platform". Aligning Emacs with GNOME is fine,
in principle. Recognize, however, that it can also mean a straightjacket at
times - Emacs will not be _better_ than whatever GNOME has already defined.

    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.

Agreed.

    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.

Sorry, I'm not an artist or an image guru. I think my descriptions got the
point across. It's a moot point anyway, if we are to adhere to the GNOME
"standard".

I said I wouldn't belabor this, but I did run on a bit. I'll not follow up -
do whatever you like. Oommmm.

 - Drew

Re: suggestions on toolbar icons

[Jan D.]

> I won't belabor this, but I do have a few responses. Your reply is, in
> essence, "GNOOOOMMME" (shades of Allen Ginsberg w/ "Oommmm"). If 
> GNOME's
> choices are not always the best, we will nevertheless live with it.

No,they are not always the best, far from it.  But there is a point in 
aligning with them.

>
>>  - 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.
>
>>  - Directory (Dired):
>>    Suggestion: Use a regular folder icon. Duh?
>
> GTK_STOCK_DIRECTORY _is_ a standard folder icon. This _agrees_ with my
> suggestion (not at all Microsoftesque) that a standard folder icon 
> should be
> used for Dired. If you think advocating that a folder icon be used to
> represent a folder editor implies advocating adopting Microsoft 
> conventions,
> then I would suggest that you are overly zealous in your struggle. 
> Oommmm.

I don't have any "struggle".  I'm just pointing out that Gnome should 
have higher priority than any other desktop, be it KDE, OSX or 
whatever.  GTK_STOCK_OPEN and GTK_STOCK_DIRECTORY are confusingly 
similar (did I just say that Gnome isn't always the best?).  OPEN is 
what the action is, not FILE.  Sometimes (without file dialog or the 
Motif dialog), you can actually open directories with open.  So FILE 
does not apply.


>
> Similarly, GTK_STOCK_FILE is a standard file icon. This _agrees_ with 
> my
> suggestion to keep this icon.

It is not FILE, it is NEW we are using.  And should be using, as the 
action is NEW as in new buffer, not FILE.  Again, it is possible to 
make a new buffer without any file with this under the right settings.

>
> The question then is, what about new-file vs existing-file? I suggested
> using something similar for both of these. GTK_STOCK_NEW is in fact
> _identical_ to GTK_STOCK_FILE, showing that GNOME and I think alike on 
> this
> one.
>
> Emacs, however, currently uses the _directory_ icon, 
> GTK_STOCK_DIRECTORY for
> opening an existing file - it happens that this icon is identical to
> GTK_STOCK_OPEN. Using a folder to represent opening a _file_ flies in 
> the
> face of every UI I've ever seen. Are you sure that GTK_STOCK_OPEN is
> intended for files, not for directories? Does using it for opening a 
> file
> make sense to you?

Check out any Gnome application, it is the most common icon (as is 
OPEN), it is indeed used for opening existing files.  We did not put 
this in Emacs on a hunch.

>
> Finally, if you are going to use GNOME as a litmus test, then why not 
> be
> consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for 
> Info's
> Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which is, 
> presumably,
> chronological) - as in Web browsers? Why use the GNOME undo/redo icon
> (GTK_STOCK_REDO) for Back and Forward? I suspect that we are already
> departing dangerously from the GNOME Oommmmm. It's a slippery slope...

HOME was used because previous Emacs versions use HOME from GTK 1.x.    
BACK is used in info, I presume that is what you mean.  Are you 
suggesting BACK for two actions?  The previous version of Emacs used 
redo/undo, so we keep that.  As you pointed out, there are icons 
missing.

>
>     The Gnome stock quit could be used in info to quit, it is an arrow
>     pointing to an open door.
>
> Yes, that's better, although the icon is ambiguous (entering or 
> exiting?)
> and is not very clear (the door is hard to distinguish). I prefer the
> international exit sign - the one you look for when there's a fire.

Make that icon, so we can see what it looks like.

>
>>  - 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.
>
> "Quit" is clearer (and more common) than "discard". At this level, the
> distinction between leaving the buffer intact and killing it is not
> important - and "discard" doesn't help with this distinction anyway.

It is very important.  It is a great difference between just burying a 
buffer and discarding it.

	Jan D.

RE: suggestions on toolbar icons

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3486 bytes --]

    OPEN is what the action is, not FILE. Sometimes (without file dialog or
the
    Motif dialog), you can actually open directories with open.  So FILE
    does not apply.

Yes, despite the name, `find-file-existing' can also open directories. I
still think the folder icon is misleading here.

    > Similarly, GTK_STOCK_FILE is a standard file icon. This _agrees_ with
    > my suggestion to keep this icon.

    It is not FILE, it is NEW we are using.  And should be using, as the
    action is NEW as in new buffer, not FILE.  Again, it is possible to
    make a new buffer without any file with this under the right settings.

Fine. How would I know which you use, without checking the code? FILE and
NEW are _identical_ icons; they are both standard file icons.

So, what is FILE for? Is it perhaps for opening an existing file? It is
normal that the two actions "open a new file" and "open an existing file"
have similar icons - that's just what I was suggesting we need. Similar,
yes; identical, no. File, yes (for both); folder, no.

    > Are you sure that GTK_STOCK_OPEN is
    > intended for files, not for directories?

    it is indeed used for opening existing files.

OK. Too bad.

    > if you are going to use GNOME as a litmus test, then why not
    > be consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for
    > Info's Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which
is,
    > presumably, chronological) - as in Web browsers? Why use the GNOME
    > undo/redo icon (GTK_STOCK_REDO) for Back and Forward?

    HOME was used because previous Emacs versions use HOME from GTK 1.x.

Legacy.

    BACK is used in info, I presume that is what you mean. Are you
    suggesting BACK for two actions?

I said "why not use GTK_STOCK_GO_BACK for Back (which is, presumably,
chronological)."  It is used in Info for Previous, not for chronological
Back. I already pointed out that it is _not_ good to use undo/redo for
chronological moves.

    The previous version of Emacs used redo/undo, so we keep that.

Legacy. Are we tied to legacy as well as to GNOME? And if (as is the case
here) they happen to conflict? Apparently legacy wins.

To be clear: _IF_ we are to be consistent in adherence to GNOME, then we
should 1) use BACK/FORWARD for Back/Forward (chronological moves), 2) use
something else (not BACK/FORWARD and not UNDO/REDO) for structural moves,
and 3) use TOP (not HOME) for Top. Hang legacy, for things like toolbar
icons!

    > the international exit sign.

    Make that icon, so we can see what it looks like.

Attached (google for "exit"). Also attached: the information symbol (google
for "information"). Even countries that don't use international signs use
these two in airplanes, airports, and such, so I can't imagine many people
haven't seen them. Also attached: possibilities I mentioned for
"Preferences" (Customize) and "New File".

    > "Quit" is clearer (and more common) than "discard". At this level, the
    > distinction between leaving the buffer intact and killing it is not
    > important - and "discard" doesn't help with this distinction anyway.

    It is very important.  It is a great difference between just burying a
    buffer and discarding it.

Of course, but it is not a difference that is reflected in "discard" any
more than in "quit". If you really want to be a stickler about this, use
"delete". The point is that "discard" is as ambiguous as "quit", but it is
less familiar to many people.


[-- Attachment #2: exitsign.jpg --]
[-- Type: image/jpeg, Size: 1814 bytes --]

[-- Attachment #3: information.jpg --]
[-- Type: image/jpeg, Size: 607 bytes --]

[-- Attachment #4: preferences.jpg --]
[-- Type: image/jpeg, Size: 797 bytes --]

[-- Attachment #5: new.gif --]
[-- Type: image/gif, Size: 710 bytes --]

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: suggestions on toolbar icons

[Jan D.]

>     OPEN is what the action is, not FILE. Sometimes (without file 
> dialog or
> the
>     Motif dialog), you can actually open directories with open.  So 
> FILE
>     does not apply.
>
> Yes, despite the name, `find-file-existing' can also open directories. 
> I
> still think the folder icon is misleading here.

You should try to influence Gnome then.


>     It is not FILE, it is NEW we are using.  And should be using, as 
> the
>     action is NEW as in new buffer, not FILE.  Again, it is possible to
>     make a new buffer without any file with this under the right 
> settings.
>
> Fine. How would I know which you use, without checking the code? FILE 
> and
> NEW are _identical_ icons; they are both standard file icons.

Why should you know?  The tooltip tells you what it does, that is all 
any user wants to know.

> So, what is FILE for? Is it perhaps for opening an existing file? It is
> normal that the two actions "open a new file" and "open an existing 
> file"
> have similar icons - that's just what I was suggesting we need. 
> Similar,
> yes; identical, no. File, yes (for both); folder, no.

Also a Gnome issue, take it up there.

>> if you are going to use GNOME as a litmus test, then why not
>> be consistent and use GTK_STOCK_GOTO_TOP instead of GTK_STOCK_HOME for
>> Info's Top? Likewise, why not use GTK_STOCK_GO_BACK for Back (which
> is,
>> presumably, chronological) - as in Web browsers? Why use the GNOME
>> undo/redo icon (GTK_STOCK_REDO) for Back and Forward?
>
>     HOME was used because previous Emacs versions use HOME from GTK 
> 1.x.
>
> Legacy.
>
>     BACK is used in info, I presume that is what you mean. Are you
>     suggesting BACK for two actions?
>
> I said "why not use GTK_STOCK_GO_BACK for Back (which is, presumably,
> chronological)."  It is used in Info for Previous, not for 
> chronological
> Back. I already pointed out that it is _not_ good to use undo/redo for
> chronological moves.
>
>     The previous version of Emacs used redo/undo, so we keep that.
>
> Legacy. Are we tied to legacy as well as to GNOME? And if (as is the 
> case
> here) they happen to conflict? Apparently legacy wins.

Yes, we are slightly tied to legacy, but less so in this part than for 
the rest part of Emacs.  Sure, we can use BACK for something else, but 
present a suggestion for a complete and visually consistent toolbar, 
questioning random icons here and there is not constructive.

>
> To be clear: _IF_ we are to be consistent in adherence to GNOME, then 
> we
> should 1) use BACK/FORWARD for Back/Forward (chronological moves), 2) 
> use
> something else (not BACK/FORWARD and not UNDO/REDO) for structural 
> moves,
> and 3) use TOP (not HOME) for Top. Hang legacy, for things like toolbar
> icons!

Again, present a complete suggestion.  You are assuming somebody else 
should figure out what this "something else" is.  That is not going to 
happen, there are far more important things to work on.

>
>> the international exit sign.
>
>     Make that icon, so we can see what it looks like.
>
> Attached (google for "exit"). Also attached: the information symbol 
> (google
> for "information"). Even countries that don't use international signs 
> use
> these two in airplanes, airports, and such, so I can't imagine many 
> people
> haven't seen them. Also attached: possibilities I mentioned for
> "Preferences" (Customize) and "New File".

These are visually inconsistent with the rest of the toolbar, except 
perhaps for new.gif.  I don't see any advantage over the Gnome 
versions.  However, you can try getting these in to Gnome.  But you 
probably have to modify them so they are visually consistent with other 
Gnome icons.


>
>> "Quit" is clearer (and more common) than "discard". At this level, the
>> distinction between leaving the buffer intact and killing it is not
>> important - and "discard" doesn't help with this distinction anyway.
>
>     It is very important.  It is a great difference between just 
> burying a
>     buffer and discarding it.
>
> Of course, but it is not a difference that is reflected in "discard" 
> any
> more than in "quit". If you really want to be a stickler about this, 
> use
> "delete". The point is that "discard" is as ambiguous as "quit", but 
> it is
> less familiar to many people.

I have not done any statistical analysis of how familiar people are 
with discard, but the Emacs manual uses it in several instances 
(discard input, lines, etc), and the meaning is never quit.  Of course 
the difference is reflected in the difference between discard and quit. 
  I'll let the native english speakers descide if discard is so strange 
that a change to delete is needed.

	Jan D.

Re: suggestions on toolbar icons

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>>     OPEN is what the action is, not FILE. Sometimes (without file
>> dialog or
>> the
>>     Motif dialog), you can actually open directories with open.  So
>> FILE
>>     does not apply.

Please, Jan, when replying to Outlook users, use the WYf command from
gnus on their article.  This is not readable.

>>     It is not FILE, it is NEW we are using.  And should be using, as
>> the
>>     action is NEW as in new buffer, not FILE.  Again, it is possible to
>>     make a new buffer without any file with this under the right
>> settings.
>>
>> Fine. How would I know which you use, without checking the code?
>> FILE and
>> NEW are _identical_ icons; they are both standard file icons.
>
> Why should you know?  The tooltip tells you what it does, that is all
> any user wants to know.

Disagree.  Tooltips are optional guides.  The user interface has to
make sense of its own without explanation, or we could just make
everything carry identical buttons.  Tooltips are nice for giving out
some rationale, so that the user then can say "ah right, that was the
logic behind it".  But they are an explanation, not a substitute for
reason.

>>     The previous version of Emacs used redo/undo, so we keep that.
>>
>> Legacy. Are we tied to legacy as well as to GNOME?

I have to agree here with Drew.  "legacy" here is an explanation why
something happens to be the way it is right now, not a reason why it
should be kept that way.

> Yes, we are slightly tied to legacy, but less so in this part than
> for the rest part of Emacs.

I don't see we are tied at all by legacy.  Emacs-21.4 had a working
toolbar just on a single platform, and then it did not use GNOME-2
icons.

There is absolutely no reason to invoke "legacy" here.  We have
significantly reordered the menus which is a much larger step than
using appropriate icons.

Drew's criticism was probably worded stronger than necessary, and so
you felt the need to get defensive.  There is no need either to be
ashamed of what we did previously, nor to cling to it without
necessity.

You have expressed your view that it is a good idea to go with the
flow of GNOME in general with regard to the icons, and I agree with
that.  Drew's suggestions in that context make sense, even when they
were worded in an unfortunate way.

It is not like I don't have a history of that affliction myself...

> Again, present a complete suggestion.  You are assuming somebody
> else should figure out what this "something else" is.  That is not
> going to happen, there are far more important things to work on.

Yes, I think that would be a good idea.  Obviously Drew has invested
some thoughts in it, and it would be nice if this lead to a coherent
proposal we could then implement.

And with a coherent proposal, it is also easier to explain to the
GNOME artists why and what new and changed icons would be desirable
and for what reason.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: suggestions on toolbar icons

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>>     OPEN is what the action is, not FILE. Sometimes (without file
>>> dialog or
>>> the
>>>     Motif dialog), you can actually open directories with open.  So
>>> FILE
>>>     does not apply.
>
> Please, Jan, when replying to Outlook users, use the WYf command from
> gnus on their article.  This is not readable.

Sorry, I am not a gnus user.  But I'll see what I can do in the future.

>
>>>     It is not FILE, it is NEW we are using.  And should be using, as
>>> the
>>>     action is NEW as in new buffer, not FILE.  Again, it is possible 
>>> to
>>>     make a new buffer without any file with this under the right
>>> settings.
>>>
>>> Fine. How would I know which you use, without checking the code?
>>> FILE and
>>> NEW are _identical_ icons; they are both standard file icons.
>>
>> Why should you know?  The tooltip tells you what it does, that is all
>> any user wants to know.
>
> Disagree.  Tooltips are optional guides.  The user interface has to
> make sense of its own without explanation, or we could just make
> everything carry identical buttons.  Tooltips are nice for giving out
> some rationale, so that the user then can say "ah right, that was the
> logic behind it".  But they are an explanation, not a substitute for
> reason.

I may have misunderstood the question, but I was answering to "Given 
the fact that FILE and NEW are identical icons, how can I know if Emacs 
uses FILE or NEW?"  If the icon doesn't make sense, the tooltip is the 
guide, if they do, they both make sense, without the user having to 
know if it is FILE or NEW internally.

>
>>>     The previous version of Emacs used redo/undo, so we keep that.
>>>
>>> Legacy. Are we tied to legacy as well as to GNOME?
>
> I have to agree here with Drew.  "legacy" here is an explanation why
> something happens to be the way it is right now, not a reason why it
> should be kept that way.
>
>> Yes, we are slightly tied to legacy, but less so in this part than
>> for the rest part of Emacs.
>
> I don't see we are tied at all by legacy.  Emacs-21.4 had a working
> toolbar just on a single platform, and then it did not use GNOME-2
> icons.

Legacy in this context means it worked like this before so let's do the 
same.  This applies to the case where no suitable stock icon where 
found.

> Drew's criticism was probably worded stronger than necessary, and so
> you felt the need to get defensive.  There is no need either to be
> ashamed of what we did previously, nor to cling to it without
> necessity.

I did not mean to come off as opposed to all change, it is just that 
changing even one icon is a bit of work (scaling it, converting to xpm 
and xbm, testing on true color, pseudo color and black and white 
display), and changing just a few breaks the visual consistenct that 
the Gnome stock icons have, regardless if they are good or bad.  
However, I think the inclusion of the older gthumb icons as has been 
suggested is a good idea, we should do that regardless what Gnome 
replies to Lennart Borgmans mail.

>> Again, present a complete suggestion.  You are assuming somebody
>> else should figure out what this "something else" is.  That is not
>> going to happen, there are far more important things to work on.
>
> Yes, I think that would be a good idea.  Obviously Drew has invested
> some thoughts in it, and it would be nice if this lead to a coherent
> proposal we could then implement.
>
> And with a coherent proposal, it is also easier to explain to the
> GNOME artists why and what new and changed icons would be desirable
> and for what reason.

I have found it generally hard to change the minds of those in charge 
of Gnome (there was even something about that on slashdot a couple of 
days ago, so it is perhaps not me being unlucky).  But Borgmans 
suggestion is an addition, not a change so I think it stands a fair 
chance of being accepted.

	Jan D.

Re: suggestions on toolbar icons

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

[...]

>> And with a coherent proposal, it is also easier to explain to the
>> GNOME artists why and what new and changed icons would be desirable
>> and for what reason.
>
> I have found it generally hard to change the minds of those in
> charge of Gnome (there was even something about that on slashdot a
> couple of days ago, so it is perhaps not me being unlucky).

Having survived as an Emacs developer should be an excellent
qualification for this sort of task.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: suggestions on toolbar icons

[Drew Adams]

    > use something else for structural moves,

    You are assuming somebody else should figure out what this
    "something else" is.

I made several concrete suggestions for this "something else", starting with
"->..." (left, right, and up versions) and including other Gnome icons. And
Lennart made a suggestion (arrow pointing to a page). I can only suggest.

    >> the international exit sign.
    >     Make that icon, so we can see what it looks like.
    > Attached.

    These are visually inconsistent with the rest of the toolbar

And?

Of _course_ a harmonious set of icons would be needed. I sent prototype
images to give you an idea of what I meant, because you asked for them and
you said you didn't understand my verbal description. I made it clear that
those images are just pulled from various Web pages (googling); I sent URLs
in my first message.

IOW, you said you didn't understand my description, you didn't follow the
URLs to see what I meant, you asked me to send an image to clarify, and then
you said that the images I sent don't fit what's already there now. Can you
say "mauvaise foi"?

Re: suggestions on toolbar icons

[Jan D.]

> IOW, you said you didn't understand my description, you didn't follow 
> the
> URLs to see what I meant, you asked me to send an image to clarify, 
> and then
> you said that the images I sent don't fit what's already there now. 
> Can you
> say "mauvaise foi"?

I wanted a .xpm and a .xbm to be inserted in to lisp/toolbar right away 
so I can see it in the Emacs toolbar in context.  Or a screen dump of 
the Emacs toolbar with the new icons in it.  Descriptions and icons not 
in context simply isn't the same.

	Jan D.

Re: suggestions on toolbar icons

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

[...]

>     The point of stock items is that themes may change them and
>     applications that uses stock items change appearence
>     automatically.
>
> I think that Emacs could do better than what is there now,

I agree with that assessment, but I think the best way to change this
is to tell the GNOME artists.

> but I do respect that general argument. I wasn't aware of this.
>
>     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.
>
> This is not about "any other platform". Aligning Emacs with GNOME is
> fine, in principle. Recognize, however, that it can also mean a
> straightjacket at times - Emacs will not be _better_ than whatever
> GNOME has already defined.

Then GNOME should become better.  There is no sense in splitting
efforts here.  If an icon is unclear in meaning, we should report it
to the GNOME artists instead of creating some half-baked inconsistent
icon ourselves.  They have the means to create stuff that matches
their style better than what we could come up with.  If they made
unfortunate choices at times, there is no reason not to tell them.

> Sorry, I'm not an artist or an image guru. I think my descriptions
> got the point across. It's a moot point anyway, if we are to adhere
> to the GNOME "standard".

Or the GNOME standard to its users' needs.  Really, there is no need
to be fatalistic about it.  Make a proposal and send it to the GNOME
lists.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: suggestions on toolbar icons

[Miles Bader]

On Thu, 17 Mar 2005 10:33:59 -0800, Drew Adams wrote:
> I said I wouldn't belabor this, but I did run on a bit. I'll not follow up -
> do whatever you like. Oommmm.

Man, you start out implying you don't want to start an argument and
yet fill your message up with this sort of crap.  You clearly don't
like Gnome -- and I certainly have my own long list of complaints
about it -- but please save the anti-Gnome rants for some other list.

David is exactly right, Emacs should try to follow _some_ standard for
icons, and if that standard is lacking, we should first try to change
the standard.  Since Gnome is more or less the "GNU GUI", and Emacs
has a GTK port, Gnome seems a reasonable choice for that standard.

Toolbar icons are a lot less useful for their intended audience (naive
users) if they vary wildly between applications, especially
applications that look superficially similar in other was.  Even your
aim is to make the icons "better" for these users, changing them only
in Emacs might have exactly the opposite effect.

-Miles
-- 
Do not taunt Happy Fun Ball.

RE: suggestions on toolbar icons

[Drew Adams]

    Man, you start out implying you don't want to start an argument and
    yet fill your message up with this sort of crap.  You clearly don't
    like Gnome -- and I certainly have my own long list of complaints
    about it -- but please save the anti-Gnome rants for some other list.

So I'm a Gnome-hater now? And a Microsoft pusher? Ad hominem ad nauseum.

For the record:

1. I have nothing against Gnome. I have never seen or used Gnome. I had
hardly heard of Gnome before Jan's email; I did not know that Emacs was
using Gnome icons; and I did not know that Gnome had a set of generic icons.

I stated explicitly that aligning Emacs with Gnome was fine, in principle. I
mentioned that I agreed with the idea of using generic icons that can change
appearance automatically - that's very good - I mentioned that I wasn't
aware of that possibility. I pointed out a few places where Gnome icons
_agreed_ with what I was suggesting (versus what is now in Emacs). I (and
Lennart) suggested using some Gnome icons that are not used now, and I
suggested using some of the Gnome icons differently.

2. I do use Windows now in my work, as well as GNU/Linux (remotely - xterm
only). I am not particularly a fan of Microsoft as a company, and I don't
think Microsoft UIs are always great - far from it. I think free software as
a movement is great, and Microsoft as a movement is not. But that does not
mean that everything GNU is the best there is, that there is no room for
improvement, or that inspiration for such improvement cannot come even from
the likes of Microsoft or other devils. It so happens that none of my
suggestions on icons were inspired by Microsoft products (to my knowledge),
but so what if they had been?

It is silly (counter-productive) to circle the wagons each time you think
someone has mentioned something happening outside the cult. "Burn the
heretic!" will eventually leave you with few of the faithful left to burn.

3. I don't even use the toolbar - I just happened to open a recent Emacs and
came across what I felt were not-the-most-helpful icons.


I sent along some ideas for improvement, with no particular expectation that
any one of them might be adopted. In several cases I gave alternative
suggestions - the suggestions were obviously intended as food for thought,
as possible minor improvements.

The response was, essentially: 1) Gnome doesn't allow/provide this, and 2)
where allowed/provided, it conflicts with the legacy Emacs icons. End of
story.

Re: suggestions on toolbar icons

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>     Man, you start out implying you don't want to start an argument
>     and yet fill your message up with this sort of crap.  You
>     clearly don't like Gnome -- and I certainly have my own long
>     list of complaints about it -- but please save the anti-Gnome
>     rants for some other list.
>
> So I'm a Gnome-hater now? And a Microsoft pusher? Ad hominem ad
> nauseum.
>
> For the record:
>
> 1. I have nothing against Gnome.

Then don't start rants with "Ommmmmmm" and similar pseudo-religious
ridicule in them.  And then complain when people take offense at what
obviously was intended and framed as offense.

I do agree with your current sentiment that we should return to
discussing this rationally, but you did not exactly set an example in
that respect.  So I don't think it is your call to act hurt.

Can we please leave off the fingerpointing and blame assignments?  It
buys us nothing, and it is not like we have nothing else to get done.

Thank you.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: suggestions on toolbar icons

[Richard Stallman]

    Your reply is, in
    essence, "GNOOOOMMME" (shades of Allen Ginsberg w/ "Oommmm"). If GNOME's
    choices are not always the best, we will nevertheless live with it.

The idea of making Emacs work with GTK is so that it will fit in with
GNOME.  Coherence with other GNOME applications is therefore very
desirable.