[KDev4] Opening project with real ASync way

[Andreas Pakulat]

On 28.05.07 13:10:43, dukju ahn wrote:
> 2007/5/28, Andreas Pakulat <apaku at gmx.de>:
> > On 28.05.07 08:55:09, dukju ahn wrote:
> > > 2007/5/28, Andreas Pakulat <apaku at gmx.de>:
> > > > On 28.05.07 02:22:59, dukju ahn wrote:
> > > > Thats not good, IMHO the
> > > > projectmanager view should be populated with items as soon as the
> > > > manager plugin created them.
> > >
> > > But why we should let the user see project contents even when
> > > the project is not fully parsed? It only confuses user anyway.
> >
> > No, seeing the project populate tells the user that kdevelop actually
> > reads it currently. While doing nothing for half a minute (ui-wise)
> > tells the user it silently failed, which is bad. IMHO.
> 
> Then I'll add some temporary item at project manager view.
> When parsing is about to start, temporary item such as
> "parsing /path/to/file" will occur. When completed, remove that item.

Sounds ok to me.

> Using progress bar (which is already used) is other solution. The problem
> is that we can't know the whole size of items unless we finished
> to parse them.

Right.

> I'm against the statusbar because user can open multiples of project
> at one time. The bottom statusbar has no enough space to accomodate
> all that progresses.

There is no statusbar and AFAIK thats by purpose.

> > > > btw, are the qstandarditems created in the
> > > > non-gui thread and then transferred into the gui thread to be used in
> > > > the GUI or are they created inside the GUI thread?
> > >
> > > The top ProjectItem is created in GUI, and his children are created
> > > in separate thread. ImportJob takes ProjectItem as its argument.
> >
> > So will connections done during creation of the items work after the
> > thread has died? I mean if the items are created in a separate thread
> > then  the connections are all queuedconnections by default (the manager
> > plugin lives in the gui thread) and this (AFAIK) doesn't change if the
> > thread dies.
> 
> I can't understand the meaning of connection. Does the "connection" means
> signal-slot connection or child-parent hierachy?

signal-slot connection.

> If former, items are not QObject, so there is no queuedconnection.

Yes, but the item is not all that gets created. Behind the scenes the
managers parse() function might do a whole lot more (for example the
qmake manager will add qfilesystemwatchers to get notified of changes to
the project file to reload)

> In any case, the importjob and its thread is deleted by deleteLater()
> and the project managerview worked normaly.

Because I don't think one of the managers creates any connections during
parse(), but the QMake Manager will do that at some point.

> > > > What about
> > > > concurrency? the parse() function of the manager isn't needed to be
> > > > threadsafe and in fact I doubt it is at the moment. For example at some
> > > > point I'll need to access at least the projects kconfig object in qmake
> > > > manager.
> > >
> > > Aah, real big problem. But see KSharedConfig section at KConfig
> > > techbase tutorial below.--
> >
> > KSharedConfig makes sure you never get more than 1 KConfig object in
> > your application because it adds implicit sharing of the objects (like
> > QString class). And IIRC the shared classes of Qt are not thread-safe
> > due to this mechanism.
> 
> Yes, kde-devel says that its not thread-safe.

As we'll have probably other things that will run in separate threads
and need access to the project configuration I think we need to make
access to that threadsafe. I'm not sure how to do that though at the
moment, at least not in a central place like Project and I'd like to not
have to state that each usage of Project::configuration() needs to be
secured by a read lock...

> > > Or I think we should force parse() to be thread-safe if it is necessary.
> > > I can't imagine any other way than using thread to make async.
> >
> > Its easy to do it different: use fetchMore/canFetchMore to let the model
> > do the parsing when the project tree is traversed. So in fetchMore the
> > model would ask the projectmanger to parse the parent item and the
> > manager can check wether it already parsed this one or not (by setting a
> > flag or similar, or we can do this in the ProjectBaseItem as wel).
> 
> But that means "parse when clicked" approach, which was suggested
> by me and disagreed by other people. All of you said that project tree
> should be fully parsed at project opening time.
> Anyway if we can follow this, we don't need thread and problem
> would be much simipler.

I didn't say we should go that route, I just wanted to state that its
easy to do it without a thread ;)

Andreas

-- 
Try to relax and enjoy the crisis.
		-- Ashleigh Brilliant