Actions: grouping vs. extensibility

[Jakob Petsovits]

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

We have similar issues with the close, save and open actions.

The major logic error in the current approach is that icon names should be 
sorted by their "base object". This approach works very well in all other 
categories, but actions doesn't contain a set of item icons, it contains a 
set of action icons, and thus the icons should be grouped by their actual 
action, and only contain the specific object as an additional level of 
specificity. The objects (document, window, etc.) should at maximum occur in 
icon names that we know for sure will not apply to any other possible object.

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


* Add a "new" icon
  "The icon for the create action."
  
  Consequences for existing icons in the spec:
    address-book-new -> new-address-book
    appointment-new -> new-appointment
    contact-new -> new-contact
    document-new -> new-document
    folder-new -> new-folder
    window-new -> new-window

  Opens up opportunities for:
     new-mail
     new-tab
     new-bookmark
     new-podcast (for audio players)
     new-class (for integrated development environments)
     new-document-drawing (and new-document-*)
     new-menu-entry
     ...


* Add a "close" icon
  "The icon for the close action."

  Consequences for existing icons in the spec:
    dialog-close and window-close -> remove,
      those two can really be the same icon

  Opens up opportunities for:
    close-document
    close-tab
    close-project


* Remove the "document-" prefix
  from the open, open-recent, save and save-as actions

  Opens up opportunities for:
    *-project instead of document-*-project which is ugly
    using the save action also for "Apply" actions in settings dialogs


* Add an "edit" icon
  "The icon for the edit action."

  Opens up opportunities for:
    edit-appointment
    edit-contact
    edit-todo
    edit-bookmark
    edit-format-cell
    edit-preferences
    edit-statusmessage-away
    edit-track-pianoroll
    ...


* Rename "system-run" to "run"

  Opens up opportunities for:
    run-build (compile the current selection, used in IDEs)
    run-build-file (compile a single file, used in IDEs as well)
    run-validation (check an XML file for compliance)
    ...


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?

Thanks,
  Jakob