[KDev4] Opening project with real ASync way

[Andreas Pakulat]

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.

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

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

> But I'm not sure whether this means thread-safe.
> Rather than KConfig, we usually don't modify any member variable
> in parse(). So its thread-safe.

Well, we should use proper locking to access stuff from various threads,
no matter wether we read or write.

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

> > > Unfortunately, Core::self() returns _I_ProjectController, not ProjectController.
> >
> > Right, thats why Core has projectControllerInternal().
> 
> No. Core doesn't have projectControllerInernal. Rather it has
> uiControllerInternal(), docCtrlInternal(), and pluginCtrlInternal().

Then add it please :)

Andreas

-- 
Never look up when dragons fly overhead.