Actions: grouping vs. extensibility

[Rodney Dawes]

On Mon, 2007-07-16 at 12:23 +0200, Jakob Petsovits wrote:
> <jimmac> the major part of that all making sense is the generic type fallback
> 
> Hi list,
> 
> yesterday I started to tackle KDE's actions icons for icon naming spec 
> compliance, and I stumbled across a major bug in the spec, so to say, or at 
> least something that will make it impossible for us to comply while still 
> keeping the amount of shared icons in kdelibs that we intend to have.
> 
> The issue is the grouping of action icons by objects that the action operates 
> on, it conflicts with the concept of levels of specificity and in consequence 
> with sensible fallbacks. Sounds a bit theoretical, let's have an example
> (the most visible one for that matter):
> 
> The spec has a series of document-* icons, like document-new, document-open, 
> document-save, and others. The problem with this approach is that there is no 
> generic fallback if I want to create or open something other than a document, 
> say, a project which consists of multiple documents. The specification in its 
> current form just creates a new "namespace" for the most common items 
> address-book, application, contact, document and window (for the "new" 
> action), but if we want to put something else into kdelibs (bookmark-new, 
> project-new, tab-new) we'll break the spec. Which is bad.

How does foo-new break the spec exactly? The specific action is the more
specific part here.

> Therefore, I demand that the spec is changed as follows:

Demand is such a rude word. Suggestions, constructive criticism, etc...
are welcome, but demands are not.

> * 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?

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

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

> * Rename "system-run" to "run"

I don't see any specific benefit for this. For the icons you mentioned
this being useful for, I see the following as better suggestions:

>     run-build (compile the current selection, used in IDEs)

project-build

>     run-build-file (compile a single file, used in IDEs as well)

project-build-single

>     run-validation (check an XML file for compliance)

document-validate (useful for things other than XML)


> I think these few changes should solve this issue of extensibility and 
> fallbacks. There might be a few other icons that we'll propose, but this 
> specific problem is pretty much a thing of the past if these changes go in.
> 
> Please don't dismiss this request lightly. We are going to have a lot more 
> icons than the spec demands, and we are going to put a lot of them into 
> kdelibs in order to share them among applications. I don't want to introduce 
> non-compliant icons, but if there's no compliant way to do it then we'll 
> prioritize KDE's needs over specification compliance.
> 
> 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.
The spec is also not 1.0 material yet, and doesn't claim to be. But that
doesn't mean that we can change the spec so heavily, for one desktop or
the other. It is nearing 1.0, but is still not solid enough to be called
such.

I don't think the changes you are demanding here are totally necessary,
or that there is an extensibility issue. The spec was written with
extensibility at the forefront from the beginning, as it was always
meant to only include a base minimum set of icon names. As an example of
this, see the recent work that has gone on with the device names as an
extension to the spec.

-- dobey