[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    FEATURE: Startup sequence reorder
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-04-14 13:53:56
Message-ID: 200604141553.56282.l.lunak () suse ! cz
[Download RAW message or body]


> The requirements for a new feature to get in KDE3.5.x are:

> - it needs to be already in trunk - we already have lot of code that went
> only into KDE3.5.x and not trunk, no need to make this even worse

 check

> - it needs to be complete and ready - don't ask "I plan to develop this
> feature for 3.5.x, will it get in?"

 check

> - it needs to be well-tested - create a branch or a patch and have it tested 
> by other people, or even make independent public releases (kde-apps.org, in
> some distribution packages, whatever)

 check (SUSE Linux 10.1 beta testing)

> - it needs to respect other freezes - if no new i18n messages are allowed, 
> no feature changing those is allowed either

 check

> - it needs to be committed no later than a month before the next release is 
> tagged (right now there's no date for 3.5.3, but presumably all releases 
> will be announced at least a month in advance)

 uhm ... check?

> - it must be mentioned in the changelog of the release (marked with "New:")

 pending

> - commit log must include "approved by ..." and don't forget the FEATURE:
> tag where applicable

 pending

> - last and the most important: It must be posted to the mailing list for the 
> SVN module (kde-core-devel for those without) and must be approved by the
> module's maintainer (TWG for those without) 

 check + pending (well, unless approving it myself counts ;) )

 
 Details about the new order can be found in detail in 
http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/ksmserver/README . 
In a nutshell, the plan is to have kdesktop+kicker ready as soon as possible 
and consider that to be "KDE is up and running" (which it kind of is). As 
much as possible of the stuff is done as late as possible. There possibly may 
be a problem caused by something launched that late, but we haven't found any 
case of this. If necessary, such component can be simply moved to a sooner 
kcminit/autostart phase.

 The kdebase_splash is another patch that's done separately because it makes a 
visible change (well, assuming being faster is not considered a visible 
change). This startup reorder really makes the startup slightly faster (not 
sure why, probably because the startup is parallelized sooner), but the 
biggest change is in the perceived speed - kind of like why people think MS 
Windows starts faster than it does. This patch changes splashscreen to go 
away as soon as kicker+kdesktop are ready and shows only busy cursor up to 
the point till which splash is shown now - this way KDE is "usable" soon but 
the user can still see something is going on. This change may however make 
progress in some splashscreens look a bit weird.

 To sum it up:
 Cons: Faster startup, both real and especially perceived.
 Pros: Startup may be really borken if people try without matching kdelibs and 
kdebase (hello Debian), something may potentially start a bit too late.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

["kdelibs.patch.gz" (application/x-gzip)]
["kdebase.patch.gz" (application/x-gzip)]
["kdebase_splash.patch.gz" (application/x-gzip)]

[prev in list] [next in list] [prev in thread] [next in thread]