|
KSplashX, a potential replacement for the KSplashML engine is imported into KDE SVN. Continued progress in the Solid and NetworkManager integration. More refinement, including better keyboard shortcuts, in Konsole. New keyboard layouts in KTouch. Icon and undo support in Step, the educational physics simulation package. KBounce becomes the latest game to move to a scalable interface and graphics. More work in KSquares, Konquest, KSpaceDuel and KReversi. KSudoku starts to be ported to KDE 4. Initial support for input fields and other form elements in okular. A co-ordinate grid and Wikipedia entries for cities comes to Marble. Further improvements, including the addition of Tree View functionality to the Dolphin file manager. New features in Mailody. Initial video support in Amarok, with heavy interface redevelopment underway for version 2.0. Last stages of an interface overhaul for the next version of KTorrent are completed. Proxy support added to the KDE Windows installation utility. Strigi is moved from playground to the kdesupport module.
|
Luboš Luňák requests comment on his proposal to replace KSplashML (the KDE splash engine) with a more lightweight implementation, KSplashX:
|
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 needed.
- 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?
So, comments, objections, flames?
p.s. The "Simple" and "None" splashscreens are definitely going to stay, of course :)
|
|
Jos van den Oever provides a brief update on Strigi:
|
Here's the Strigi status. Strigi has moved into a more prominent location in KDE SVN: kdesupport/strigi.
It will be a requirement for kdelibs soon and installation instructions are available on TechBase.
This is a prelude to adding a new KFileMetaInfo implementation which relies on Strigi. The first implementation will pull data from the file itself. Later it will be extended to get information from Strigi's index and from NEPOMUK's 'triple' store.
That's really all for now...
|
|
Josef Spillner talks about the GGZ Gaming Zone framework and how it relates to the KDE games arena:
|
The GGZ Gaming Zone (or GGZ for short) is a cross-platform multiplayer environment focusing on casual online games, but providing development tools and infrastructure for other game types as well. Most of the client-side development focuses on Java, SDL/Pygame, Gtk+/GNOME and - now with renewed focus - KDE. By importing some of our KDE-specific libraries into KDE SVN and adding on top of them, we hope to get a more robust and pervasive gaming infrastructure for KDE 4.0.
GGZ development for KDE is not new, those with a sense of real nostalgia will have heard of it already. What is new is the inclusion into KDE and the technical maturity of the framework. With just a few lines of code, game developers will be able to access great functionality such as game server events, chatting, statistics, savegames and tournaments. What still needs to be done at this point is a few common dialogs.
The first game (KReversi) compiles nicely with GGZ support already, and playing in general works, but some protocol optimizations will follow. Future work includes improvements of the protocol code generator so that all hand-written network code can disappear and we can toggle between efficient binary communication and developer-friendly XML communication as we like.
What is important to know (not comprehensible from the image) is that the "core client" to the left (the one players use to meet and chat) is still the old KDE 3 version and needs a rewrite, which might or might not happen in time for KDE 4.0.
p.s. Some people will kill me because I promised to work on knewstuff2 first and leave the game stuff for afterwards. I just cannot resist :)
|
|
As an aside, Josef asks about the Commit-Digest extended statistics graphics, and if there is a way to contribute to the data collection effort. And i'm happy that he asked! KDE SVN account holders can add their data to the aggregated statistics by following the instructions at http://commit-digest.org/data/. Thanks!
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
