|
Plasma progress, with new Plasmoids: Browser, Notes, 3D Earth Model, Twitter, Desktop, and Tiger (scripting example), and the development of a mouse cursor data engine. Bug fixing spree in TagLib, K3b, and the Kopete Cryptography plugin. Support for encrypted storage devices in Solid, with better integration of device support in Amarok. Further integration of Plasma in Amarok. Work on making Konsole follow KDE settings more strictly. Much work on revamping Ark for KDE 4. Various functionality improvements in Umbrello. The start of a new version of the Smoke bindings access mechanism, Smoke2. Continued work in kdegames, with the import of KBlocks, a Tetris-like replacement for KSirtet. Rewrite of search-and-replace in Kate. Import of the Kubelka-Munk mixing algorithm, with a restoration of the MetaData framework in Krita. Work to enable networked document collaboration imported in KOffice. GetHotNewStuff experimentally reactivated in okular. A rewrite of the global shortcuts system added to KDE SVN. Pixmap Cache Summer of Code project merged into kdelibs, in time for KDE 4.0. KBoard, renamed Tagua, is removed from KDE SVN to continue in an external code repository.
|
Aaron J. Seigo provides an update on recent Plasma work:
|
|
(ensure sound is on to hear the voiceovers)
so plasma has beeing ripping along this week with the highlights, aside from the usual bug and API fixing, being:
libplasma:- scripted applets, currently JavaScript only
- configuration and package frameworks all plugged together for applets
- new generic status change indication widget for applets to use
- new layouting code that actually works!
- work on the three level zoom (full desktop, desktop groups and overview)
- reworking of applet background rendering underway
dataengines:- weather now supports NOAA as well as 5 day forecasts where available
- englishbreakfastnetwork (ok, it's new to me ;)
- bluetooth engine takes shape
- solid based engines continue to grow in capabilities
applets:- traditional desktop (aka show the contents of a folder on disk + hardware devices) for backwards compatibility
- digital clock
- Twitter
- 3D earth
- MacOS dashboard widgets (and hopefully Opera widgets soon)
I'm particularly stoked about the layouting code, as it'll make writing nicely formed applets that much easier, and the scripting.
I would like to say something briefly about the fact that we only have JavaScript right now. We had to start somewhere, and with QtScript we had a really good option. It's easy to create bindings to objects at runtime, it's very fast and someone, Richard J. Moore, stepped up with actual code. as Richard says, "An example of scripted applets is the Tiger applet. The script code is responsible for loading the SVG image, rendering it to the screen and even for loading the configuration dialog. Taken togther, this shows that the script facility can already meet requirements of simple applets: support for more complex applets written as scripts will be available soon".
It's helping to refine the API we are exporting to the script interpreter and proving out the loading and other necessary systems. Once that work is done we'll come back to examine the multi-language issue, which will include issues beyond simple language options and look at resource consumption, ease of sharing between systems and other complexities (e.g. in documentation). I think it's still a good chance we'll see Python and Ruby support, but for the immediate I'm happy with JavaScript as a language we can use to get the house in order first before inviting in more guest languages.
|
|
With the recent move of the code to kdelibs, Rivo Laks introduces his Summer of Code project, a general cache for optimising pixmap usage across KDE:
|
The icon cache is meant to make icon loading faster by putting all used icons into a common file. This eliminates both the problem of having to find the icon file from literally tens of directories, as well as letting the operating system do a better job of read-aheading the entire cache file into memory. Once all icons have been put into the cache and the cache is loaded into memory, icon loading doesn't need to access the disk at all.
Although it's a rather extreme case, KFind, which loads about 600 icons at startup (most of them mimetype icons), starts up in about 1 second when all icons are loaded from the cache. When the cache is disabled, it takes about 4 seconds (both cases are with hot disk caches). For the usual applications which only load a few tens or maybe a hundred icons the speedup won't of course be that big, but it still helps.
Faster icon loading isn't the only advantage of the icon cache however. As the Oxygen icon theme is fully in SVG format, we can use those SVG files directly to generate the pixmaps at run-time. As they're put into the cache, every pixmap has to be generated only once. SVG rendering is still too costly to be done every time an icon is used, but as the results are now cached, it becomes an interesting possibility. It means that users aren't restricted to specific icon sizes anymore, but can use whatever size they want.
Probably the most interesting use is the icon compositing. It allows to create necessary icons at runtime, using a few existing pieces.
<bad-example>
For example, most mimetype icons share a common background and have something mimetype-specific on top of that.
One of the problems with this is that when an application ships icon for it's own file format, it looks out of place with other icon themes. With icon compositing, it can ship only the mimetype-specific part and it would be automatically put onto whichever background the current icon theme provides.
</bad-example>
<better-example>
Also, different emblems can be drawn on top of other icons at runtime. ATM there's an image of folder with lock for locked folders, image of folder with a picture for folders containing images, etc. Using icon compositing all that could be generated once at runtime and then be put into cache.
</better-example>
The icon compositing will probably be delayed until KDE 4.1 but the rest of the icon cache (which was originally also supposed to go to 4.1) has now been merged into the trunk. The buildsystem changes which notify the cache when new icons are installed will be done in the next few days. Some of the internals are yet to be done, e.g. mmapping the cache files into memory, but the API itself should be solid now.
An interesting byproduct of the icon cache is pixmap cache. Also in kdelibs now and usable by all applications, it provides disk caching of pixmaps. The main target is apps which use SVGs to generate their images, e.g. lots of games and kde-edu apps. KMines has recently become the first application to take advantage of the pixmap cache.
Instead of rerendering the SVGs every time the application is started, they can put the generated pixmaps into cache and reload them at next startup, reducing the startup time. To find out more about the pixmap cache check the recently added TechBase tutorial.
|
|
Henrique Pinto discusses his recent work on updating Ark, the archiving utility, for KDE 4:
|
In the last few weeks, I've been working on a restructuring of Ark. Over the years, the codebase became quite messy, and that made some bugs very hard to fix, so a somewhat major revamp was really needed. The main goals were:- Making it easier to add support for different archive types
- Making the codebase more maintainable
- Improving the user interface
Support for different archive types is now handled by plugins. The plugins must implement a simple, synchronous interface - Ark itself will take care of running the code in a separate thread. The API for writing plugins isn't quite finished yet, though - I still have some doubts about some of the details.
The code for actually handling archives, plugins and related stuff was moved out of Ark's KPart into a new library, currently named libkerfuffle. There's really no special reason for that name. I'm very bad at naming things, so I just chose a random word starting with 'K' from the dictionary. Hopefully, the name is strange enough to motivate someone to suggest a better one :). The library is currently used only by the KPart and the plugins, but my idea is to write a small application using it in order to handle integration with the file manager.
The user interface has changed a little, as can be seen in the screenshot. I'm still not very happy with it, but I'll need some help in order to make something better, as I am completely out of ideas.
There's still quite a lot to be done, however. Currently, there are only plugins for ISO images, TAR and ZIP archives. I'm afraid I won't be able to write any more plugins before the feature freeze - mostly because the API for plugins is not ready yet, and there's still some very basic features, such as removing entries from an archive, that aren't implemented yet. File Manager integration also remains undone. Any help would be really appreciated.
|
|
Troy Unrau notes a schedule modification proposal regarding the Alpha vs. Beta release debate: "While not an SVN commit, it is important to note that the release schedule has apparently been pushed back by one month in order to allow the remaining required changes to the API to get into KDE 4 before the previously planned July 25th freeze (now August 25th)."
This is because a beta release of KDE 4.0 is more than just a change in terminology - a beta release also imposes an API and feature freeze, whilst another alpha release does not.
|
This week, I have finally implemented a few of the long-planned features for the map statistics of the Digest. Now, country values can be better appreciated with the Rainbow colour scheme, and the exact percentages can be viewed for the top committing regions.
Of course, those KDE developers who have never visited this page should immediately follow its instructions, so that the map becomes ever-more accurate! I've also fixed a rounding error which led to some countries being under-represented on the map. Our international contributions have never looked so strong!
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/optimise)