[KDev4] going back to blocking project open.

Matt Rogers mattr at kde.org
Wed May 30 04:59:36 UTC 2007


On Tuesday 29 May 2007 11:03, 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
>
> 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..
>

No apologies necessary. This is exactly why I encourage people to try these 
things out before we just dismiss them (although I am hypocritical in using 
my own advice). We learn what we can from our mistakes and move on from 
there. :)
-- 
Matt




More information about the KDevelop-devel mailing list