Moved the edit_infos stuff from CKDevelop to DocViewMan

[Christian Couder]

Falk Brettschneider wrote:
> 
> 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.

Hi,

I had a closer look at the DocViewNode struct and, while we are at it,
I'd like to ask if we could also just drop the DocViewNode struct and
only have a "QList<QObject> m_documentList;" member in the DocViewMan
class.

The DocViewNode struct is defined like this :

  typedef struct
  {
    QObject*                pDoc;	
    int                     docId;          // make search faster
    int                     docType;        
    QList<QWidget>          existingViews;
  } DocViewNode;

--> the pDoc could be replaced by the pointers in the document list
--> the docId doesn't seem to make search faster (we should use some
maps if we want faster searches)
--> the docType could be found dynamically from the document pointer
--> the existing Views could be found dynamically from the document too


John Birch wrote:
> 
> 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.

I agree, I will try not to expose KWriteDoc calls outside the
DocViewMan.

> 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.

Yes it might be a good idea. But as you know the problem is broader than
this. CKDevelop is bloated and there should perhaps be a
CKDevelopDelegate class. The DocViewMan could inherit from this class,
and there could be other manager (for example a project manager)
inheriting from this class too.

> 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).

I agree.

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

I prefer :

void CKDevelop::slotEditUndo(){
  m_docViewManager->currentViewUndo();
}

like you suggested above, because I don't like creating opaque types
when they are not really needed.
This way, if we decide to split the ckdevelop class (and its slots and
signals), it will be even easier.

Now, if you agree, I will remove both the TEditInfo struct and the
DocViewNode struct.
I will start removing the TEditInfo first.

Regards,
Christian.

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