A final word and what to do now (was: A final word (was:Re: What's up and what's hot))

[Matthias Hoelzer-Kluepfel]

On Thu, 9 Aug 2001, F at 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 at kdevelop.org with the following body:
unsubscribe »your-email-address«