Change in KActionCollection::setComponentData
Michael Jansen
kde at michael-jansen.biz
Thu Mar 27 08:43:15 GMT 2008
Am Donnerstag 27 März 2008 08:42:46 schrieb Andras Mantia:
> On Thursday 27 March 2008, Michael Jansen wrote:
> > It basically disallows anyone from running kde4.0 apps against a 4.1
> > kdelibs debug build.
> >
> > See my second email clarifying the change. I think we can live with
> > that.
>
> Just to make 100% clear for me: KDE 4.0 apps will run *correctly* (as
> with KDE4.0) with a 4.1 release build, but will fail with a debug build,
> right?
>
> Andras
Yes. Konqueror and Kate are the only two applications affected from that
change ( until now ).
Versions < 4.1 from those applications will fail when run against a kdelibs
debug build from a 4.1 release ( or current trunk ). But they will work
correctly agains a kdelibs release build. I have added a ASSERT. The code
falls back to the old behavior in a release build.
I thought i had made that clear.
If that means they run correctly is up for discussion. They will probably get
problems when the global shortcuts code is fixed regarding components
handling.The code currently doesn't handle multi component applications ( as
in kparts ). It assumes that all shortcuts will be registered and handled
under KGlobal::mainComponent() or another component provided to
KGlobalAccel::overrideMainComponent.
And it's not really only a global shortcuts problem. If someday someone
decides to implement gestures for KActions ( some code is there currently ) he
will probably very pleased with the changes we are about to make.
Those changes ensure that each and every action is identifiable by a unique id
consisting of it's component name and it's objectName ( the string provided to
KActionCollection::addAction ). It's currently not possible to have a
persistent id for actions.
Mike
--
Michael Jansen
Available for contract work ( Development / Configuration Management )
http://www.michael-jansen.biz
More information about the kde-core-devel
mailing list