Moved the edit_infos stuff from CKDevelop to DocViewMan

[John Birch]

On Mon, 19 Mar 2001 05:50, Falk Brettschneider wrote:
> Christian Couder wrote:
> > Hi everyone,
>
> Hi!
>
> > I just commited some big changes to the ckdevelop files and docviewman
> > files.
> > I think the edit_infos list should be merged with the m_docsAndViews
> > list.
> > Currently I just moved the edit_infos stuff in the DocViewMan class to
> > make the merge easier and to clean a little the ckdevelop files.
>
> Nice idea to put the edit_infos stuff into the DocViewMan. :-)
>
> But I think it could be dropped, totally:
>
> struct TEditInfo {
>   /**  the id in the menu-buffer*/
>   int id;  ---> docId
>   QString filename; ---> ask KWriteDoc::fileName()
>   QCString text; ---> ask KWriteDoc::text()
>   bool modified; ---> ask KWriteDoc::isModified()
>   int cursor_line; ---> should be requested from KWriteDoc
>   int cursor_col; ---> should be requested from KWriteDoc
>   QDateTime last_modified; ---> should be requested from KWriteDoc
> };
> All information in the struct belongs to KWriteDoc since it's specific
> for edit widgets.
> We should always directly ask the KWriteDoc. Eventually, we should add
> new get methods. Otherwise we must always take care for the
> synchronization of the data in the KWriteDoc and the TEditInfo which is
> hard to do and seems to be overhead.
>
> Also: if we added this to the struct DocViewNode, we would make it too
> special for edit widgets. But it also manages Browser documents and
> their views as well.
>
> Christian, what do you think about replacing TEditInfo by direct
> KWriteDoc calls? Thanks the fact that you've moved the whole stuff to
> DocViewMan, it should be easy to get it done...

Not exactly sure where you are wanting the KWriteDoc calls to be - internally 
in DockViewManager would be fine but exposing the KwriteDoc externally 
usually isn't a good idea.

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.

Why? well there may not be a current edit view for one reason - unlikely in 
this particular call - but it's fatal currently. Also if you substitute a 
kpart later then that widget might not exist, so that makes it harder to 
change.

Besides I dislike exposing a widget just so that something else can 
manipulate it (it's necessary sometimes, but not everywhere).

alternatively, something like
  m_docViewManager->undo(someViewHandle);
might be a valid option, where someViewHandle is an opaque type.

jbb

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