[KDev4] Opening project with real ASync way

[dukju ahn]

2007/5/27, Andreas Pakulat <apaku at gmx.de>:
> On 27.05.07 08:36:43, dukju ahn wrote:
> > 2. Project parsing became much faster because the setIcon() in each
> > ProjectBaseItem isn't invoked for full recursive file/dirs. Rather, we
> > just setIcon() only for toplevel items. Icon for Children items are set up
> > when the user expands treeview.
> > I've found that setIcon() is very time-consuming operation.
>
> Are you making sure to call setIcon only once already? I mean after the
> initial expansion its not needed to call setIcon again.

Yes in new implementation with fetchMore() and canFetchMore()

> > Index: projecttreeview.cpp
> > ===================================================================
> > --- projecttreeview.cpp       (revision 668449)
> > +++ projecttreeview.cpp       (working copy)
> > @@ -54,6 +54,7 @@
> >
> >      connect( this, SIGNAL( customContextMenuRequested( QPoint ) ), this, SLOT( popupContextMenu( QPoint ) ) );
> >      connect( this, SIGNAL( activated( QModelIndex ) ), this, SLOT( slotActivated( QModelIndex ) ) );
> > +    connect( this, SIGNAL( expanded(const QModelIndex&) ), this, SLOT( slotExpanded( const QModelIndex& ) ) );
> >  }
>
> I'm not sure at the moment how the projectmodel itself works, but
> eventually we can avoid having to change the view and do it in the
> model. There are virtuals that can be implemented when a node is
> expanded, in particular fetchMore().

Yes. fetchMore() worked very well.

> If I see this correctly this is a depth-first approach right? I think a
> width-first (or whatever you call that in english, where you first run
> over all items at the current level before you decend into the next) is
> better, else a user opens the projectmanagers first item and the items
> are not all there yet.

During the process of parsing, there should be no GUI changing
because QWidgets are not thread-safe. Only when every parsing is
completed, the user can see items. So Don't worry about the empty
items of first parent.

> > -void ImportProjectJob::startNextJob(ProjectFolderItem *dom)
> > +void ImportProjectJob::processList()
> >  {
>
> Hmm, is this method still needed?

I was unsure about this method. I'll remove it

> > +    connect( project, SIGNAL(importingFinished(IProject*)), this, SLOT(projectImportingFinished(IProject*)) );
>
> I guess I'm missing something but why can't the project private do the
> stuff in that slot directly instead of adding this indirection, a signal
> and a friend declaration? All that the project private class needs is
> asking Core::self() for the projectcontrollerinternal and execute a
> that slot with the project.
> Then I think the project private class also
> doesn't need a Project* but can live with a plain IProject*.

Unfortunately, Core::self() returns _I_ProjectController, not ProjectController.
If we follow your idea, this projectImportingFinished() slot should be
added into IProjectController also.
Also, It is not natural design to invoke ProjectController's method
inside each Project.