AW: patch for runner_lock to use kxkb kpart

[Nhuh Put]

Von: Andriy Rysin
Gesendet: Samstag, 6. Oktober 2007 20:34
An: kde-core-devel at kde.org
Betreff: Re: patch for runner_lock to use kxkb kpart

> 2007/10/2, Oswald Buddenhagen <ossi at kde.org>:
> On Mon, Oct 01, 2007 at 07:16:34PM -0400, Andriy Rysin wrote:
> > 2007/9/30, Oswald Buddenhagen <ossi at kde.org>:
> > > would it be possible to use a plain libloader and QXEmbed (well, the 
> > > qt4 equivalent) to make it more lightweight? or maybe we can introduce
a
> > > KBasicPart as a general solution?
> >
> > I'll take a look to see if that's reasonable to do it with QXEmbed, 
> >
> forget that part. qxembed is actually for embedding windows from
> external processes, which isn't the case here. :}
> ideally, it would just provide a qwidget to plug into the normal layout.
> another point: i'd also like it to provide a qmenu to plug in. 
>
> Ok, would you consider something more like the attached version?
>
> It's a bit raw but pretty lightwieght - no additional libraries (no kpart,
no kio), loads only kdeinit_kxkb (which most probably is > already in the
memory), and uses simple C method to create component. 
> There are 4 modes one can create kxkb component in (enum in
kxkb_component.h file).
> I also wrote little macro to wrap up the library loading and function
reference process but I think this can be done much nicer.

Please try to used the KPluginFactory system. It is very flexible and has
already support for stuff like objects with a different QWidget and QObject
parent. It makes also easier for other developers to use without figuring
out the loading interface of the day.
You would also loose stuff like the library version check.
And unload libraries only if you really now what you are doing! In most
times, it's a very bad idea.

>
> Please let me know if you think this is the way you wanna go and we can
discuss separate QMenu and nicer component interface.
>
> Thanks,
> Andriy