[Fwd: KDockMainWindow should get new parents!]

Falk Brettschneider gigafalk at yahoo.com
Fri Jun 16 20:33:12 UTC 2000


Falk Brettschneider wrote:

> Given that kparts depends on kdeui and not the other way round,
> you realise that this means moving the kdockwidget class to libkparts ?

Ooops! Can someone make kdeui depend on kpart? ;-)

> Fine with me, just pointing out.
> On Fri, Jun 16, 2000 at 01:04:57PM +0200, Falk Brettschneider wrote:
> > The pro's are:
> > - a STRONG wish from KDevelop (to simplify class inheritances very much,
> > using KPart and the Dockwidgets)
> > - bringing KDockMainWindow more up-to-date, more KDE2-like
> > - KPart::MainWindow doesn't seem to be a big overhead
> Nor is the rest of kparts, fortunately.
> > - noone within kdelibs is using KDockMainWindow
> Who is using it, btw ?

KDEStudio, KDevelop2, KDbg1.2,kxicq

> > - the sources keep compatible
> Not 100% I guess. The GUI isn't created the same way... (createGUI(Part*))

Hmm...must have a look at it...

> This is once again the inheritance problem (like the old KWMModuleApplication
> or so).

Could you explain what that inheritance problem had been and how it was solved?

> We tried to avoid that by making kpart very modular and flexible,
> but if you want to provide part embedding in a kdockmainwindow without
> making it inherit KParts::MainWindow, it would mean reimplementing
> what KParts::MainWindow does (part activation) :(. Not a good solution.

So the best solution would be to inherit KDockMainWindow from
KParts::MainWindow, right?
What do you think about adding a new additional class KPartDockMainWindow in
parallel to KDockMainWindow?

F at lk

Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.

More information about the KDevelop-devel mailing list