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

Olivier Goffart ogoffart at kde.org
Tue Dec 2 23:26:34 GMT 2008


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081203/0dcbe1b9/attachment.sig>


More information about the kde-core-devel mailing list