[KDev4] Opening project with real ASync way

[dukju ahn]

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.

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

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

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