At 1:51 Uhr +0100 19.02.2005, Quentin Mathé wrote:
Well this method was added in an effort to add
icon themes support in a very limited fashion, I
was against it because it was a hack without
possibility to really evolve then things
stopped to evolve because I wasn't the only ones
against this implementation, I proposed a real
icon themes support at IconKit level with a
model in the Camaleon line for interface themes
(with collaboration between IconKit and Camaelon
when wanted), hmm it's not implemented currently
but just drafted outside of this fact, then we
could use this call yes (I don't think it will
be removed in -gui, soon at least).
Well, okay, then we'll probably want to not use
that method and just do it ourselves somehow. I
guess you can decide better where you want to get
that image from?
In IKIconIdentifier.h :
extern IKIconIdentifier IKIconTrashFolder;
<-- we should have IKIconRecyclerFolder for
GNUstep too
extern IKIconIdentifier IKIconTrashFolderFull; <-- idem
// ...
You mean we should rename it to "Recycler"
instead of trash? Remember, these identifiers
are supposed to be names that can be used
cross-platform to get the right standard icons,
so we can't have a recycler *and* a trash.
but both identifiers could point on the
"Trash/Recycler" icon internally (with IconKit
code) in a way not bound to how the developer
strictly mapped the icon file to 1 identifier
IKIconTrashFolder or IKIconRecyclerFolder, no ?
No, let's call it recycler. NSWorkspace has a
"recycle" action, so the term is already
ingrained in OpenStep. I don't like synonyms too
much. They only confuse newcomers because they
don't know whether there's a difference or not.
The fact the compositor you coded can only
compose two IKIcon in on pass and not several,
has no support for IconKit custom property list
in your version; there is also the fact that the
compositor is tied to IconKit which is may be
not the right solution, even if initially for
the first release it's ok, we should probably
consider a CompositorKit for a next release.
I still don't know what this CompositorKit would
do and what it'd be used for in practice. As you
agreed in another posting, IKIcon can already
composite several icons simply by compositing
again and again. We already support several
standard positions for icons and arbitrary
positions, which isn't needed in cases besides
icons usually. We also support transparency and
copying modes.
What else would we want to do? I'm not trying to
talk you out of it, but rather I'm trying to
understand what you want to do here, so I can
offer the best design I can think of.
A compositor demo with a user oriented
interaction with our custom property list would
be nice I think.
Yeah, haven't implemented the plist stuff.
Should be easy now with the string -> icon
identifier and icon identifier -> string
functions. I may do that soon.
thanks, the ball is on my side now :-)
Have fun playing :-)
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
