RFC: KSplash in KDE4

[Gary L. Greene, Jr.]

On Wednesday 28 February 2007 11:02, Lubos Lunak wrote:
>  Hello,
>
>  two things related to the splashscreen, related to each other:
> - I'd like to add a new splash implementation and would like to get
> feedback - slightly as a result of above, but not really, like to propose
> changing some things about the splash
>
>  There's branches/work/ksplashx in SVN. It's based on the ksplashx SUSE has
> been using since like 9.3 (I don't really remember). There's a README, but
> in short, add the subdir to kdebase, build it, the current splash theme is
> ported, "ksplashx Default --test" will show it.
>
>  Differences to current (KSplashML) implementation are:
> - doesn't link against Qt, uses only few sources from Qt (Qt3 actually, but
> there's no point in porting); as such it's up and running very quickly,
> unlike KSplashML, which links KDE libraries up to libkio, loading of which
> takes ages under realistic conditions during KDE startup
> - KSplashML has been unmaintained for quite some time
> - I also happen to personally think KSplashML is an overdesigned mess, but
> I guess that doesn't really count when I want to add another implementation
> using Xlib directly :)
> - themes are not C++ code but are created using a simple syntax file, with
> slightly limited capabilities (see below); I could even add a script to
> convert KSplashML's Default engine-based themes if wanted
>
>  In practice, most of KSplashML's features shouldn't really matter and the
> only real difference should be almost instant startup. I don't really
> insist on dumping KSplashML if somebody sees a reason for it to live, but
> then I don't see it myself.
>
>  All what KSplashX can do, basically, is just adding images to the splash
> window and overlaying animations. That may not seem much, but that happens
> to be what splashscreens do :). Some seemingly missing features include:
>
> - No text support. Can be still done by preparing images with texts
> rendered into it. There's no i18n support either, but if needed, could be
> done by having extra images per language. However, splashes usually tend to
> display two things, 1) things like "KDE" or "3.5", which are not translated
> and are part of the images, 2) things like "Initializing peripherals" or
> "Loading the window manager", which are rather uninteresting and a lie
> anyway.
>
>  Our startup sequence has changed quite a lot since the times this was done
> (and will most probably still change a bit for KDE4) and the messages no
> longer match, nor they make that much sense (I still remember the times
> when people complained about KWin starting way too long just because that
> message was shown while something else was hogging the system). I'd like to
> propose to just have, say, 8 or 10 checkpoints at some arbitrary points in
> the startup and just show progressbars or only icons or whatever depending
> on the theme for them (not necessarily always as much as 8 or 10).
>
> - No support for locolor. KSplashML first tries a locolor version of the
> splash for bpp == 8. Do we still need that? Should be simple to add if yes.
>
> - Obviously, since there's no C++ code, there's no way to add arbitrary
> things like icons jumping on the bottom edge of the screen, but do we
> really need that anyway?

While I understand that you are looking to speed things up with the initial 
startup of KDE, I've a few comments on your post...

There are a number of folks that would be mighty upset if we limit the splash 
screen implementation like this.... The folks that developed Moodin are a 
good example, as they require a fair amount of extra eyecandy in the splash 
system to pull off some of their effects in the splashes. Additionally, 
having images containing i18n strings makes the task of translation that much 
harder. If we go to this I will guarantee that there will pop up a 
replacement on kde-view to bring back many of the features of KSplashML.

Now that I've said that, here are a few constructive things to say on another 
approach. Lubas, you said that much of the slow down is caused by KSplashML 
pulling in kio, et el. Is there maybe a way to refactor this so it doesn't, 
while retaining the abilities it has now? If so, then the speed issues are 
dealt with, and the feature-set remains high.

-- 
Gary L. Greene, Jr.
Sent from: uriel
 08:34:00 up 7 days, 10:16,  6 users,  load average: 0.01, 0.03, 0.00
=========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
 See www.tolharadys.net and www.kde.org for more information
=========================================================================

Please avoid sending me Word or PowerPoint attachments.