[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KWrite and KParts
From:       Alexei Dets <dets () services ! ru>
Date:       2000-05-12 5:30:09
[Download RAW message or body]

Hi!
David Faure wrote:
> 
> On Thu, May 11, 2000 at 12:31:57AM +0400, Alexei Dets wrote:
> > As I notice KWrite is a KPart now.
> > I don't need KWrite as a whole thing, I need slightly stripped down
> > version.
> > And I need to inherit it because I'm pretty sure that I'll need to
> > change KWrite_Doc and I can't simply inherit from KWrite_Doc because it
> > is a friend class but its child will not be.
> > So, I must inherit KWrite, KWrite_Doc and KWrite_View - they are all
> > "friends" :-(
> > I can say that my KWrite will not be KWrite from kdelibs, why I need
> > this strange and useless in my case KPart thing?
> > So, the question is: what is the fastest way to get rid of this bloat
> > and convert KWrite back to plain QWidget?
> 
> Why ? A part is nothing else than a widget and some actions
> that go with it. You probably want the actions too.
> No bloat here.

I didn't find any good docs about XML GUI on developer.kde.org :-(
Or this is totaly different thing and I mess something?
If you say that it is no bloat, ok, I believe you.
But I don't know how to use this as a normal widget, for example, how
can I create the child window? I can't pass pointer to KPart to QWidget
constructor :-(

> (I agree that a design where all classes are friend is not a good
> design, though).

Yes, it is bad. In this way I can't simply inherit from classes in
kdelibs, I must create my own slightly modified copy :-(

> Beware that the API of libkwrite will most probably change before the
> final 2.0. For now it's in kdelibs only to make the part available...

Oh, I thought that KDE2 API is basically stable now :-( But may be this
is better - KWrite class API is better now (compared to KDE1 version).

	WBW, Alexei

[prev in list] [next in list] [prev in thread] [next in thread]