Le 4 janv. 05, à 21:49, M. Uli Kusterer a écrit :
At 20:54 Uhr +0100 04.01.2005, Quentin Mathé wrote:
Come to think of it, I'm not even sure I can do the compositing
operation. I can do alpha by simply doing a copy of the icon with
the alpha applied and compositing that, but the actual compositing
is done by Icon Services on MacOS.
I didn't mean I couldn't composite. It's just that one of the addIcon
methods takes an NSCompositingOperation, and CompositeIconRef simply
slaps two IconRefs on top of each other, not offering any means to
decide whether they will be xOred or have a certain transparency or
whatever.
I can fake transparency, because IconRefs contain alpha channels, and
I could draw an IconRef into an NSImage, change its transparency and
then generate a new IconRef from that, but I'd have to do the entire
compositing using NSImages if I want to control the
NSCompositingOperation.
ok, I understand the problem.
GetIconRefVariant
Specifies a transformation for a given IconRef.
Transformation are state changes like "highlighted", "disabled" or a
label. The rest isn't really relevant (except PlotIconRefInContext, of
course, which is the only way to get my icon into an NSImage).
hmm :-/
Then we need to be able to use the GNUstep related IconKit compositor
in a Cocoa application, I don't think it is a problem because the
IKCompositor could be compiled with Cocoa.
What would IKCompositor be used for? In most cases, icon badges will
not do anything apart from being drawn opaque or slightly transparent
on top of their icon. Users are able to do that using IKIcon. I don't
think the users will care whether IKIcon uses IKCompositor or
IconServices internally. Is this feature really needed?
The compositor could be very useful for various NSImage
transformations, I wouldn't like to restrict it to icons related
operations. Well, the right solution would be probably to create a
powerful compositor outside of the IconKit, then the IconKit compositor
could be derived from it or not… I don't know… What do you think ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
