Le 15 févr. 05, à 01:20, M. Uli Kusterer a écrit :
At 23:23 Uhr +0100 14.02.2005, Quentin Mathé wrote:
We may also want to use that other call GNUstep has for getting
standard images instead of imageNamed:.
Which other calls ?
I've seen some GNUstep code use some new NSImage call for getting
standard images from the system ... +standardImageNamed: or something
named like that. I think that one would be more correct, but the
GNUstep sources I have here don't contain it yet.
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).
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 ?
// Icon needs to be scaled/moved before compositing?
if( pos.origin.x != 0 || pos.origin.y != 0
|| pos.size.width != mySize.width || pos.size.height !=
mySize.height
Š
if( (pos & IKBadgePositionFlagTop) == IKBadgePositionFlagTop )
// Move to top?
box.origin.y += fullSize.height -box.size.height;
if( (pos & IKBadgePositionFlagRight) == IKBadgePositionFlagRight
) // Move to right?
box.origin.x += fullSize.width -box.size.width;
What is the reason of the question marks here ?
These are simply comments that describe what the "if" does. The
question marks don't mean that I'm unsure what it does. It's simply
how I define comments for "if"s.
ok
Š otherwise everything looks ok for me from an architectural
perspective. We need to solve the compositor problem now and to do
the merge with the version in Étoilé cvs, and on my side to refactor
IKProvider related classes.
Could you elaborate what you mean by "the compositor problem"?
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.
Would be nice too to merge our various demo examples in one example
compiling on both GNUstep and Mac OS X, and which demonstrates
compositing operations (with optional property list), badges and
providers mechanism (this last part of the demo would be invisible
under Mac OS X probably ).
Yes, that could be handy. However, I thought my example pretty much
did everything you can do with IconKit... Adding a better GUI is a
good idea, are there any other features we're still missing (besides
the part of asking the provider for the correct icon images)?
A compositor demo with a user oriented interaction with our custom
property list would be nice I think.
thanks, the ball is on my side now :-)
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
