Moved the edit_infos stuff from CKDevelop to DocViewMan
Christian Couder
christian.couder at fr.alcove.com
Mon Mar 19 12:47:12 UTC 2001
John Birch wrote:
>
> On Mon, 19 Mar 2001 19:38, Falk Brettschneider wrote:
> > Falk Brettschneider wrote:
> > > Might as well just add an currentViewUndo() to m_docViewManager and then
> > >
> > > > connect appropriately. Then all these forwarding methods just disappear
> > > > from ckdevelop and you don't have to expose the internal widget
> > > > (kwritedoc?) to the outside.
> > >
> > > Hmm...hmm...the DocViewMan was actually thought as helper class for
> > > CKDevelop, as MDI manager so to speak.
> > > Now you propose to move functionality of the application framework to
> > > that class - I'm not that happy with it, this is more than DocViewMan
> > > should be. My feeling is DocViewMan has the task to compute the current
> > > views and documents but not much more. Slots connected to Mainframe
> > > window actions should belong to the framework class.
> >
> > Maybe we can create an EditorManager which is owned by CKDevelop, uses the
> > DocViewMan and where we can move the CEditWidget-concerned slots of
> > CKDevelop to. This may easy that huge CKDevelop class. What do you think?
>
> It'll be nice to remove code from ckdevelop - if the widget could deal with
> all the edit stuff I guess that'll be a good idea. It'll then sort of follow
> the kdevelop3.0 style (abeit very loosely :-).
I mostly agree (see my previous mail), but I think the DocViewMan should
be cleaned first.
And will we have the time to do all this before the freeze ?
> Bags I don't do this, hehe.
I probably won't have time to do it either.
Bye,
Christian.
-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«
More information about the KDevelop-devel
mailing list