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

List:       kdevelop-devel
Subject:    Re: A final word and what to do now (was: A final word (was:Re:
From:       Matthias Hoelzer-Kluepfel <mhk () caldera ! de>
Date:       2001-08-10 8:28:26
[Download RAW message or body]

On Thu, 9 Aug 2001, F@lk Brettschneider wrote:

> > So as you and Falk as well as jowenn and Christoph know best about
> > Kate, KWrite and QextMDI, I would like you to do that now, so we can have a
> > first working version of that part by September/October. I hope that your
> > timeframe fits this, but I would like it to be ready by then. Technically,
> > please not that it should be exchangable by the user to use either of those
> > two concepts, either QextMDI or split-views like it's working now.
> Technically, QextMDI's tasks are application core functionality and
> cannot be moved to a plugin. I learned that during the time when QextMDI
> was in the HEAD branch. Note that the whole GUI is handled by QextMDI:
> The mainwindow is a QextMdiMainFrm, the tool-views are embedded in
> KDockWidgets under control of that single QextMdiMainFrm instance. And
> it's clear all docu and source views are QextMdiChildViews. Only if all
> those 3 conditions are fulfiled it's possible to switch the 3 MDI
> visualization modes.

Yes, I guess QextMDI needs to be part of the core classes. I
think it should not be part of the lib/interfaces classes,
however, so the current interface for parts should not change
too much. But I really can't see how QextMDI could be a
plugin. I tried to abstract out the view management once, but
I didn't manage to do it, so I dropped the idea soon...

> If you want to have splitter views, a solution will be possible. It
> could be implemented as another MDI visualization mode in QextMDI.

I guess that would make anyone happy :)

> If you think about making QextMDI a part plugin, it would mean to have
> the main window object with all the menu and toolbar children objects
> physically in the part library plugged in and dynamically loaded by user
> choice. That doesn't make sense to me.

Agreed. And where would be the value? If we want to have new
interface models, I guess the right place would be to add them
to QextMDI (KextMDI, hopefully :), so other applications would
profit as well.


Bye,
Matthias.



-
to unsubscribe from this list send an email to kdevelop-devel-request@kdevelop.org \
with the following body: unsubscribe »your-email-address«


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