going back to blocking project open.

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

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.

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.

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.

I'm very sorry, I should have anticipated these problems..

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel