Actions: grouping vs. extensibility

[Evgeny Egorochkin]

Just an idea. How about naming the fallback icons like all-new or generic-new? 
This seems to resolve the most pressing issues.

-- Evgeny

On Tuesday 17 July 2007 00:46:58 Aaron J. Seigo wrote:
> > > * Add a "new" icon
> > >   "The icon for the create action."
> > >
> > > * Add a "close" icon
> > >   "The icon for the close action."
> >
> > What will the metaphor be? How will these icons relate to all formats?
>
> probably an "x" for close and page-with-star for new or something along
> those lines. essentially what we've been using for how many years now for
> something meaning 'close' and 'new'. it doesn't need to relate to all
> formats perfectly, since that's what the more specific icons are for, no?
>
> > > * Remove the "document-" prefix
> > >   from the open, open-recent, save and save-as actions
> >
> > You're misinterpreting the term document here, to mean "files formatted
> > for print that primarily contain text," which is incorrect. All of the
> > files a user can view/edit/play/etc... are documents.
>
> i think jakob answered this in his original email.
>
> > > * Add an "edit" icon
> > >   "The icon for the edit action."
> >
> > What exactly would this be? Why do we need it? All of the icons under
> > edit-* are for things that normally appear in the "Edit" menu of an app.
>
> i think jakob answered this in his original email.
>
> > > * Rename "system-run" to "run"
> >
> > I don't see any specific benefit for this. For the icons you mentioned
>
> this one is debatable, i agree.
>
> > > Could you help us to achieve both?
> >
> > The spec was never meant to be an absolute conglomerate of all icons for
> > all occasions in all desktops at all times. It is meant to be the base
> > minimum set of icons a desktop should require to maintain visual appeal.
>
> if you read Jakob's email carefully, you'll see that it makes it easier to
> provide such a minimum set by defining "new", "edit", etc... as base icons
> so that one doesn't get the dreaded ? icon in the case that there isn't a
> foo-new icon that is requested, but rather can get the generic new icon
> instead when calling new-foo.
>
> the downside to this is that it is rather late in the spec's history to do
> this and would require a number of changes to icon references. a bit of a
> pain for apps that are using the current spec and a raises a tough question
> about how to manage compatibility between old and new icon themes.
>
> personally, i think Jakob is quite right here, but i think it comes down to
> how widespread the current icon spec is in production use and how much pain
> it's going to bring to fix the spec. if it is too much for 1.0, this could
> perhaps be put on the bench for v2 of the spec. it would be nice to get
> this right sooner rather than later, though.
>
> > But that doesn't mean that we can change the spec so heavily, for one
> > desktop or the other.
>
> just keep in mind that the more a spec fails to meet the real needs of all
> potential users of it, the less useful the spec becomes.