[KDev4] Opening project with real ASync way

[dukju ahn]

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.

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

> > > 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?
If former, items are not QObject, so there is no queuedconnection.
In any case, the importjob and its thread is deleted by deleteLater()
and the project managerview worked normaly.

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

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