[kde-artists] Actions: grouping vs. extensibility

[James Richard Tyrer]

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.
> 
> 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
>     ...
> 
I do see your point, but I think that the way that they are currently
arranged -- by classes according to what type of application they apply
to -- is also valid.  Either way is a valid application of set theory.
So, although (at least) theoretically, your suggestion is more correct
-- with a modifier following the object -- I see little to gain here; 
this isn't nearly as important as names that have the levels of 
specificity in the wrong order which does make it impossible to add more 
names.
> 
> * 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 miss the point here.  I don't think that "run" is a good base node for 
Compile, and "run" is one of the possible "system" actions.
> 
-- 
JRT