KStyle/KIconEngine problem WAS Re: Bug in icon kcm?

[Albert Astals Cid]

A Dimecres 03 Desembre 2008, Olivier Goffart va escriure:
> Le mardi 2 décembre 2008, Albert Astals Cid a écrit :
> > A Dimarts 02 Desembre 2008, Albert Astals Cid va escriure:
> > > A Dimarts 02 Desembre 2008, Albert Astals Cid va escriure:
> > > > A Dilluns 01 Desembre 2008, Louai Al-Khanji va escriure:
> > > > > Hey,
> > > > >
> > > > > I'm currently not running trunk or I would test this myself. I
> > > > > believe there is a bug in the icon kcm, specifically line 372 in
> > > > > kdebase/runtime/kcontrol/icons/icons.cpp. The value member variable
> > > > > is of float type, but gets cast to int. Because the range for value
> > > > > is 0..1.0, this is effectively always 0 in the config file.
> > > > >
> > > > > Am I right? If so, could someone please correct this? I don't want
> > > > > to do it blindly.
> > > >
> > > > Done, thanks for reporting.
> > >
> > > The problem is that it does not work though, most of the painting is
> > > done in QCommonStyle by calling KIconEngine::pixmap that always sets
> > > KIconLoader::Desktop as group because it seems it can not know which
> > > it's parent is.
> > >
> > > One "solution" would be never calling QCommonStyle and making KStyle
> > > deal with it all the calls so it can do the correct calls, but that's
> > > completely an impoosible amount of work.
> > >
> > > Other hack would be having a type variable in KIconEngine that is set
> > > each time KStyle calls QCommonStyle so when QCommonStyle ends up
> > > calling KIconEngine::pixmap we know which type of element we are
> > > rendering. But that would not work with threads, although i'm not sure
> > > if one can use KStyle in threads
> > >
> > > The obviously simple solution is dropping this icon effects thing
> > > altogether :-/
> >
> > Maybe the only right solution is our friendly QtSw dudes doing a
> > QIconEngineV3 where the pixmap() call gets info about who is requesting
> > the pixmap.
> >
> > Does that be feasible for the QtSw dudes reading this?
>
> Can you describe what's the problem more precisely?
>
> I would say that this information should be passed in the KIcon construcor
> (which would pass it in turn to the KIconEngine)
> There could even be a KIcon::setGroup

No, it can not work this way. The KIcon is created as icon for a KAction that 
is shown both on the toolbar and the menu, on KDE 3 different effects could 
be applied for those.

So there are two options left:
 * Adding the QIconEngine::pixmap function that passes the widget that wants 
to use the pixmap
 * Killing/Reworking this functionality so we can hack it on top of KIcon as 
you suggested

Albert