unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jan D." <jan.h.d@swipnet.se>
Subject: Re: suggestions on toolbar icons
Date: Fri, 18 Mar 2005 06:52:40 +0100	[thread overview]
Message-ID: <f1c06beec02e7e5a569a567c29a68fac@swipnet.se> (raw)
In-Reply-To: <MEEKKIABFKKDFJMPIOEBEECLCKAA.drew.adams@oracle.com>


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

  reply	other threads:[~2005-03-18  5:52 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.
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. [this message]
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=f1c06beec02e7e5a569a567c29a68fac@swipnet.se \
    --to=jan.h.d@swipnet.se \
    /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).