make kdeui loadable by styles, kill/merge kdefx

Matthew Woehlke mw_triad at users.sourceforge.net
Tue Jul 3 02:33:39 BST 2007


David Faure wrote:
> On Saturday 30 June 2007, Matthew Woehlke wrote:
>> David Faure wrote:
>>> On Friday 29 June 2007, Matthew Woehlke wrote:
>>>> I know I've heard people talk about wanting to kill/merge kdefx, and I 
>>>> recently learned that the reason it exists as a separate library is (at 
>>>> least in part) due to some issues loading kdeui outside of a KApplication.
>>> ... and problems when unloading libraries.
>>> (not depending on kapp is something we have already fixed in kdelibs4).
>> Really? ;-)
> Yep.
> 
>> $ designer -style Plastik
>> Fatal error: you need to have a KComponentData object before
>> you do anything that requires it! Examples of this are config
>> objects, standard directories or translations.
>> Aborted
>>
>> What's going on here I think is the code tried to do KGlobal::config(), 
>> KConfigGroup() and readEntry(), and it choked at one of those steps. I 
>> don't think it's doing anything else as far as using objects in kdeui.
> [snip]
> Well, none of that has anything to do with KApplication itself.
> The application class isn't the problem.
> However if you get this error, it means you (well, not you, but
> the plastik style) should instanciate a KComponentData instance.

Ah, yes. Well, that's not as easy as it sounds, but after some 
KComponentData ctor hacking, thanks to Matthias Kretz, it seems to be 
working. So it looks like you're right that kdeui is usable... as long 
as you don't try to touch KGlobal (at least, I'm not seeing any 
crashes). Thanks for pointing me in the right direction!

Patch coming tomorrow (for review, obviously, as it is a BIC) as soon as 
I can get it assembled for presentation.

-- 
Matthew
/bin/sh -- still Bourne on Solaris (and still not POSIX compliant)





More information about the kde-core-devel mailing list