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

Albert Astals Cid tsdgeos at yahoo.es
Wed Dec 3 11:02:39 GMT 2008


--- El mié, 3/12/08, Olivier Goffart <ogoffart at kde.org> escribió:

> De: Olivier Goffart <ogoffart at kde.org>
> Asunto: Re: KStyle/KIconEngine problem WAS Re: Bug in icon kcm?
> Para: kde-core-devel at kde.org
> Fecha: miércoles, 3 diciembre, 2008 12:26
> 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?

In KDE you have the option to set effects by "icon type", for example you can set that toolbar icons are monochrome, etc. This effect is applied by KIconLoader depending on the group you pass to it.

The problem is that the code that renders the toolbar icon, is at QCommonStyle, which calls the pixmap() function in QIconEngineV2 that has signature

pixmap ( const QSize & size, QIcon::Mode mode, QIcon::State state )

so, KIconEngine can not know if the pixmap is being requested for the toolbar or not.

> 
> 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

Hmmm, that could work, i'll have a look at it before or in the weekend, thanks for the suggestion.

Albert



      




More information about the kde-core-devel mailing list