AW: patch for runner_lock to use kxkb kpart

[Nhuh Put]

Hello

No idea where I got the impression, you unload the library, sorry about
that.

But besides that, KPluginFactory is completely in kdecore and creating some
kind of custom KLightPart with it, would be really easy.

 

            PutHuhn

 

  _____  

Von: kde-core-devel-bounces-+nhuh.put=web.de at kde.org
[mailto:kde-core-devel-bounces-+nhuh.put=web.de at kde.org] Im Auftrag von
Andriy Rysin
Gesendet: Sonntag, 7. Oktober 2007 03:29
An: kde-core-devel at kde.org
Betreff: Re: patch for runner_lock to use kxkb kpart

 

2007/10/6, Nhuh Put <nhuh.put at web.de>:

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.


actually that was my original patch, see above - I've used KPart for kxkb
component.
Though Oswald noted that libkpart pulls kio which is huge and that's
overkill for small component like kxkb.
Thus I just used QLibrary and couple lines of code. I would be nice to have
e.g. KLightPart but I am not sure it's reasonable to start talking about it
right now. 

 

And unload libraries only if you really now what you are doing! In most
times, it's a very bad idea. 

Where did you see library unloading?

Andriy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071008/bfa69aee/attachment.htm>