[KDev4] Opening project with real ASync way

[Matt Rogers]

On Monday 28 May 2007 07:55, dukju ahn wrote:
> 2007/5/28, Andreas Pakulat <apaku at gmx.de>:
> > On 28.05.07 02:22:59, dukju ahn wrote:
> > > 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.
> >
> > So you're saying that until the whole project is parsed the
> > projectmanagerview shows nothing?
>
> Yes.
>

That's worse than blocking the GUI, IMO

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

Then we need to provide a progress indicator so that the user knows we're 
still working on parsing her project.

> > 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.
>
> > 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.--
>
> It thus provides a way to reference the same configuration object from
> multiple places in your application without the extra overhead of
> separate objects or concerns about syncronizing writes to disk even if
> the configuration object is updated from multiple code paths.
>
> 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.
>
> 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.
>

In general, as long as we're only reading from it, we might be able to get 
away with it. But it's better just to do proper locking in the first place.

> > Sorry I didn't think about this yesterday, but it was a bit late here.
>
> I didn't think about that too. Don't need to be sorry :)
>
> > > 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().
>
> > > 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.
> >
> > Why is that not natural design? Currently I see a signal and a slot
> > added for 1 call, which can be done directly anyway. Signal/Slot should
> > be used if you want to notify multiple objects of something or if you
> > expect to connect multiple signals to a slot, or both - IMHO.
>
> Well ok. You are right. I'll change it.
>
-- 
Matt