Moved the edit_infos stuff from CKDevelop to DocViewMan

[Falk Brettschneider]

Hi JBB!

Hope you had nice holidays.

John Birch wrote:
> 
> Not exactly sure where you are wanting the KWriteDoc calls to be - internally
Internally for the TEditInfo stuff.

> Here's some of the things that are happening
> 
> void CKDevelop::slotEditUndo(){
>   m_docViewManager->currentEditView()->undo();
> }
> 
> and there's lots of examples like this one
> 
> 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.

> 
> Why? well there may not be a current edit view for one reason - unlikely in
> this particular call - but it's fatal currently. 
Undo() or Redo() actions should just be active when at least one edit
view exists, _only_. Then we are sure
m_docViewManager->currentEditView() always returns not equal 0L. If it
crashes, the app-framework action enabling/disabling mechanism is broken
and should be fixed there.

> Besides I dislike exposing a widget just so that something else can
> manipulate it (it's necessary sometimes, but not everywhere).
To my mind, CKDevelop is responsible for calling undo().

> jbb
Ciao,
F at lk

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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