[KDev4] going back to blocking project open.

[Andreas Pakulat]

On 29.05.07 12:03:50, dukju ahn wrote:
> Although it was me that proposed to make project openning ASync,
> I didn't forcast many possible complexities when we use thread.
> Now I carefully suggest that we go back to the original blocking mode
> 
> 1.
> The QObject cannot be created in the context of project parsing thread.
> Reason is that according to Qt-Doc,
> "You must ensure that all objects created in a thread are deleted before
> you delete the QThread"
> 
> To workaround this, we can choose to hold the thread during the entire
> period of time when the project is loaded. But I'm not sure that's a
> right approach

Or you can move the objects to the main gui thread. You'd have to give
the QThread::currentThread as parameter when creating the import
project.

> 2.
> I doubt the benefit of live GUI when the project is not loaded.
> Especially, when the user is loading the first project, there is nothing
> for the user to compose a file. In many case, the user will just wait the
> completion of parsing, even though he has a live GUI.

Well, the current gui is kind of awkward (although that may very well be
the case because I don't have a kuiserver atm), I select "open project"
and nothing seems to happen.

> 3.
> I found the reason of slow project loading -- the KIO::pixmapForUrl() which
> is called to provide argument to setIcon(), which
> is called whenever the item are created. If we don't setIcon() at project
> parsing and rather setIcon() at the time of directory expansion, the
> time is reduced.

Well, hopefully we have a icon cache after GSoC for KDE then
pixmapForUrl should be quite a bit faster on the 2nd usage (unless the
time is spent finding the right mimetype and not loading the icon).

> The measure result is for loading full kdelibs source using custom make manager,
> when icons are set
> kdevelop: Project Loading 124695 Milisecs are elapsed
> but when icons are not set.
> kdevelop: Project Loading 6451 Milisecs are elapsed
> 
> 4.
> The KConfig cannot be used in thread.

That one needs to be fixed anyway.

So conclusion from me is: if 1. can be fixed and an intermediate item is
created while the parsing is done (loading project <Projectname>) we
should still have a threaded project loading. Basically because a user
might open up 4 not-that-small projects at the same time (or at least
shortly after each other). As I said 4. has to be sorted out anyway.

Andreas

-- 
You single-handedly fought your way into this hopeless mess.