[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Icons and look proposal
M. Uli Kusterer
Re: GNUstep Icons and look proposal
Sat, 21 Aug 2004 17:16:58 +0200
MT-NewsWatcher/3.3b1 (PPC Mac OS X)
In article <address@hidden>,
Nicolas Roard <address@hidden> wrote:
> Well, yes -- if the application doesn't deal with documents, the
> item in the icon will probably be a tool, and no documents
> More exactly... if an application doesn't deal documents, it shouldn't
> documents (sounds obvious).
> Though, your example about an image converter is imho not good -- I
> 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,
> but IconKit could automatically create icons on the fly via
> different elements; then, the idea is for example to automatically
> a default "document icon" for an application, by compositing the
> 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
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
Does that clarify what I mean?
> More or less, this mechanism is for the developers that don't want/
> 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
> provide them directly to the system.
> Standard icons are not a fallback, they are expected to be used by the
> 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
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?
Re: GNUstep Icons and look proposal, M. Uli Kusterer, 2004/08/20
Re: GNUstep Icons and look proposal, Quentin Mathé, 2004/08/21
Message not available
- Re: GNUstep Icons and look proposal, (continued)