Re: GNUstep Icons and look proposal

[M. Uli Kusterer]

In article <mailman.2197.1093099966.2011.discuss-gnustep@gnu.org>,
 Nicolas Roard <nicolas@roard.com> wrote:

> Well, yes -- if the application doesn't deal with documents, the 
> proeminent
> item in the icon will probably be a tool, and no documents 
> representation.
> More exactly... if an application doesn't deal documents, it shouldn't 
> display
> documents (sounds obvious).
> Though, your example about an image converter is imho not good -- I 
> think
> an icon for such a program could probably include some "images". Plus,
> "converting" images is imho editing :-)

 Yeah, that thought occurred to me as well. My rationale was that a 
converter might include a smaller version of the document to convert, 
(on MacOS X: like StuffIt Expander has it where there are two tiny 
document icons going through a funnel, as opposed to TextEdit, where the 
sheet of paper i bigger and more prominent, while programs like Safari, 
which don't really deal with documents, just have a huge tool (the 
compass) in their icon).

 Kind of like in gothic paintings, where more important persons were 
drawn larger than the less important ones.

> >  That last part is what I wanted clarified in the icon design
> > guidelines. Icons that are there as a fallback, and which ambitious and
> > quality-conscious developers will want to replace with their own,
> > customized versions, should be marked as such in the list of provided
> > default icons. They aren't right now.
> 
> Well, it's not exactly that -- the "standard" icons should be used, 
> period.
> 
>  but  IconKit could automatically create icons on the fly via 
> compositing
> different elements; then, the idea is for example to automatically 
> create
> a default "document icon" for an application, by compositing the 
> application's
> icon in the middle of a standard "document" element (eg a paper sheet).

 I guess we mean the same thing here. What I basically want is a list in 
the icon design guidelines containing all icons you can get out of 
IconKit. This would include both the "standard" icons and the ones 
IconKit will create for you if you don't provide them (and the latter 
should be in a separate list so developers know they are 'allowed' to 
provide their own versions for those, while they shouldn't use their own 
folder icons).

 Or if it's not in the guidelines, make sure the headers contain 
comments which icons are composited as needed and can be replaced, and 
which are intended to be used unmodified (i.e. are "standard" icons). 
otherwise people will be unsure about which icons they should replace 
for a better look-and-feel, and which ones they're expected to use 
without changing.

 Does that clarify what I mean?

> More or less, this mechanism is for the developers that don't want/ 
> can't
> easily create icons, so that most of the needed icons for an 
> application (like,
> its document icon, its plugin icon, etc) would be created
> automatically (and with standard elements), helping consistency.

 Yes, that will definitely come in very handy.

> But if, for theses icons the application developer want to do them, it 
> could
> provide them directly to the system.
> 
> Standard icons are not a fallback, they are expected to be used by the 
> programmer.
> But IconKit could automatically create icons, and  theses  are a 
> fallback for the
> programmer, as he could possibly provide its own.

 Maybe we should come up with some terminology to make sure everyone 
knows what others are talking about: There are "standard icons" (your 
term), which are the ones IconKit provides and which should always be 
used unmodified. Then there are "fallback icons", which are the ones 
IconKit provides if the developer doesn't provide its own, and which are 
usually composited based on generic icons and application icons.

 And when talking about all icons you can get out of IconKit, no matter 
whether they're standard or fallback, one would just talk about "IconKit 
icons".

 Oh, and then there'd be "override icons", which are icons provided by 
the developer to replace a fallback icon. I.e. if GNUMail provides an 
icon for its .mbox files, that's an override icon, while if GNUMail just 
lets IconKit generate an icon, that would be a fallback icon.

 Does that help for future conversations?

Cheers,
-- Uli
http://www.zathras.de