Issue 91

This Week...

Furious last-minute application of polish across the board in preparation for the tagging of KDE 4.0 Final next week. Work towards threading GDB operations support in KDevelop. Support for media players employing the MPRIS standard in the Plasma "Now Playing" data engine, with the import of a Flickr Plasmoid. A style manager, support for Karbon gradients and lots of colourspace work in Krita. Various improvements in the Eigen2 math vector library. Continued progress in the KBugBuster rewrite. Revived support for .tar, .tar.gz, and .tar.bz2 files in Ark. More work on KCabinet, a library to support the MS Cabinet format. A printing framework in Okteta. System Settings moves from a custom view to Dolphin's KCategorizedView. Finishing touches in the Oxygen widget style and colour schemes. Work from the "newssl" branch is moved back into kdelibs. Various unfinished features hidden in Konsole for KDE 4.0. The Trolltech Phonon backends are moved from kdebase to kdereview for KDE 4.0. The unmaintained "regexpeditor" moves from kdeutils to playground/utils.

Kåre Särs introduces Glimpse, a new scanning application for KDE 4:

Glimpse is a basic image scanning application for KDE 4. Glimpse uses the new libksane library from extragear, instead of the old libkscan. Glimpse provides the file saving features while the scan dialog and scan options are handled by libksane.

I have been missing a good Open Source scanning application that would be easy to understand (Kooka and XSane don't feel right to me). I first planned to modify libkscan, but I could not figure out the code, so I made my own :)

Glimpse is actually a byproduct while libksane is the main target. For Glimpse, I want to provide easy saving of the scanned images, both providing a save dialog for every scanned image and a possibility to autosave the images in a specific directory.

My goal with libksane is to provide easy access to the most-needed scan parameters, while still giving the possibility to use the advanced (and not so common options) of the SANE backends.

libksane is usable, but can still be tweaked. Things that hopefully make libksane interesting are that it supports 16-bit colors (6 bytes/pixel) and that the UI is (in my opinion) a bit better than that of libkscan. With libksane you can also reach almost all options available from the backends (this is not possible with libkscan).

Things left to do:

Doxygen documentation is needed :)

The parameters don't yet have tooltips to explain what they are for.

The names of the scan options come from the SANE library, so the translation is a problem not yet solved.

The parameters are now grouped with a dropdown box into basic, advanced and 'All options'. This could be regrouped with a tabbed interface.

The things listed above are mainly short-term goals. I also want to improve the usability of the application - at the moment, using the libksane dialog without a mouse is not very easy, which could be improved.

I also hope that others will want to use libksane for scanning support in their projects.

As an aside, the name of the application (Glimpse) is found in over 20 milion web pages (Google) and there even is a glimpse.com. It might be that we need another name!

Before everyone starts to spread their opinion about KDE 4.0, let me spread some reminders:

KDE 4.0 is not KDE4 but only the first (4.0.0 even non-bugfix) release in a years-long KDE 4 series to come.

KDE 4.0 is known to have missing parts or temporary implementations (eg. printing, PIM, Plasma).

Most changes happened under the surface and cannot be discovered in a "30 minutes usage" review anyway.

User interfaces being unchanged in 4.0 compared to 3.5 may be still changed/improved during KDE 4 life time.

KDE 4.0 will not be the fastest KDE 4 release - like for KDE 2 most speed optimizations will happen later during KDE 4.

Most applications (many are not even fully ported yet) will take only advantage of new features which the new Qt/KDE libraries offer later.

Don't measure portability success (eg. MS Windows) by current availability of application releases, they will come.

KDE 4.0 is only expected to be used by early adopters, not every KDE 3.5 user (and IMHO KDE 4.0 shouldn't be pushed onto other user types like planned for Kubuntu ShipIt (which by the way is said to have only 6 months support for its packages)).

KDE 4.1 development will not require the same amount of time as the big technology jump of KDE 4.0: expect KDE 4.1 later this year.

Last, again: KDE 4.0 is not KDE 4.

I know it's traditional at this time of year to have a retrospective of the acheivements of the previous 12 months, but with the imminent release of KDE 4.0 (due to be tagged on the 4th of January), i've found it difficult to get contributions from developers who are furiously applying as much polish as possible in what is now the final lap of a several year development marathon. These last-minute changes explain the small amount of work on features this week in KDE SVN, and also the reduced number of selected commits in this Digest - such commits generally don't make interesting reading!

Still, although 2007 was not the most outwardly-visible year for the KDE project (with the last major release in November 2005), from an insider's point of view, it was certainly the most significant in the history of the project, with the foundation for around 5 years of future releases being quietly built (well, I like to make a little noise in this publication). And surely with KDE 4, 2008 stands to be yet more important.

Major highlights for me are the improved organisation and non-programming aspects of the project - features such as the "Road to KDE 4" by Troy Unrau, the emergence of Oxygen as a team which consistently rivals professional, commercial graphics designers, and the often thankless, invisible work of people like Sebastian Kügler, Wade Olson and countless others like them - are all things which I remember about KDE distinctly in 2007. And just as Time Magazine sometimes labels whole groups of people as their "Person of the Year", the KDE Commit-Digest Person of the Year would go to the KDE contributors who's work is not always immediately visible, but almost always vital - translators, documentation, and so many more.

Massive thanks to all who donated over the past week to the "lets-get-dannya-a-new-laptop" fund. Though I said I had no expectations, I confess that I had a small target that I would at least like to have reached (like, say, $200) - and the donations not only reached that target, but exceeded it several times over. Waking up each morning to more donations really put a smile on my face.

So I will now be getting a new laptop, if not in time for the KDE 4.0 release on January 11th, at least in time for the KDE 4 Launch Party in Mountain View, California, where I should (just about!) be able to find someone to install the newly-released onto it. Despite the cautionary note of Stephan above, i'm really excited - not only for what KDE 4 currently is, but for what is possible and what it will become.

Multimedia

Michael Pyne committed changes in /trunk/KDE/kdemultimedia/juk:

Fix Krazy issues with localization. No new strings, but many more strings have context added where requested by the translators and recommended by Krazy in situations where the right translation would be unclear.

Only major code change is in tagrenameroptions.cpp which I don't like in the version either now or before. Now it is more verbose but less of a hack.

Educational

Torsten Rahn committed changes in /trunk/KDE/kdeedu/marble:

* Fix coordinate system
(North is + and South is - , West is - and East is + in the internal radian based coordinate system now)
* More usage of centerCoordinates(lon, lat);
* Speed-ups in flat projection code
* code cleanup, better naming

- Rework how we manage memory, since sourceUnused hook is neither available nor makes sense. Rather, do it based on interpreter detaches
- Let the DebugDocument manage its document and view. It also manages the content construction, and does it more locally, instead of torturing katepart with zillions of line ops.
- Also, always use katepart for viewer, not the default editor
- Lay the foundation for persistent breakpoints. Doesn't seem to work yet,though

Tested with Audacious 1.4.4. The only bit that doesn't work is the track number - Audacious doesn't export the track number via the GetMetadata() method of the /Player object, and it's difficult to deal with the /TrackList object at the same time due to the silly MPRIS convention of giving different interfaces the same name...

Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src:

Add a slot which sends a profile change command to the active session. This can be used to change any setting of the active session, using the same property=value semi-colon separated list format used by the konsoleprofile tool.

This is experimental API and not guaranteed to be present in future KDE 4 releases.

Some changes. There is some pair of blue and yellow that actually mixes in to green. Yay! Like in reality (thank you boud to point this out), there are some blues (like prussian) and yellows which are not "tied" to mix into green (you'll obtain a "grayish mud").

So the color space is here, probably it needs a bit of valgrinding, but hey... it's completed!

Roughly sketched to please the current needs. But something similar should be added to kdelibs, at least also khtml and kate do something along these lines. Perfect would be some kind of merger with Flake, so all data types could be added to paged documents.

- eigen2 now fully enforces constness! found a way to achieve that with minimal code duplication. There now are only two (2) const_cast remaining in the whole source code.
- eigen2 now fully allows copying a row-vector into a column-vector.

Optimization

Educational

Jason Harris committed changes in /trunk/KDE/kdeedu/kstars/kstars:

Applying patch to improve rendering time for stars by a factor of twenty. Stars are now drawn as pixmaps, rather than calling drawEllipse() for each star. The star pixmaps are stored in a static QHash in StarObject. The hash contains images for all spectral types, and all sizes. This is how stars were rendered in 3,5, so this is a regression fix.

The star pixmaps are regenerated when the user selects a new color saturation level for stars (this is effected by modifying the width of the QPen used to draw the colored rim of the circle), and when the user chooses a color scheme that uses solid red, black or white star images (without a colored rim).

Also, stars are now rendered slightly larger on-screen, closer to what was done in 3.5.

Multimedia

make all playlist animations run off the same timer, eliminates the bad jerkiness in some cases. Also fix a potential gargantuan memmory leak as none of the timer or QGraphicsIremAnimation items were previously deleted, ever....

Other

Graphics

KDE Base

Will Stephenson committed changes in /trunk/KDE/kdebase/workspace/systemsettings:

Port System Settings to Interview using a copy of Dolphin's KCategorizedView. This improves item layouting now and will allow more appropriate sorts, as well as alternate views (KControl emulation mode anyone?).

This replaces the attractive desaturate effect for search misses with the standard behaviour that only hits are shown by the proxy model. This is arguably less attractive but more familiar and accessible.

The KCategor* classes are COPIED from Dolphin but will be synced and removed when they move to kdelibs in 4.1.

TODO: figure out why KCategorizedSortFilterProxyModel doesn't emit layoutChanged() when the model is filtered - this prevents us updating the number of search hits at present.
TODO: get ereslibre to remove the omnipresent rubberband from KCategorizedView
TODO: add weights to the categories and sort the model according to them
TODO: add a custom KCategoryDrawer to draw the category icon in the view

Right. We reuse the interpreter for different pages in the same part, hence detach happens pretty rarely. Accordingly, re-add the clearInterpreter hook from KJSProxy. For now it's only used for a sanity check. One could also kill the old documents on it. I am not sure which is right --- killing them can be annoying since all the tabs disappear; if one doesn't kill them, stuff leaks ifthe debugger is on.

Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src:

Disable tabbed navigation inside the Konsole part itself. This is something which I would like to add after KDE 4.0, but it does not work well enough to be used at the moment and causes problems for applications such as Yakuake and KDevelop which provide their own tabs.

Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/desktop/CMakeLists.txt:

The 'Quick Access' feature is not in good enough shape at this point to include in the release, so I am removing the menu entry to launch it. It can still be accessed via the --background-mode startup argument.

Multimedia

* added a TODO
*video settings widgets correctly initializes its sliders to current value
* start of a KPart. Its listed in Konqueror in the Embedded tab, but Konqueror never actually loaded it when I tried to test.

a) Found more trouble with master control selection.
b) Remove debug output.
c) Disable unfinished code (e.g. shortcuts for Enums)
d) Remove PenelApplet target in the CMakeLists.txt (it does not work with Plasma anyhow).
e) Reenable gloabl shortcuts (somebody put - for whatever reeaon - a separator in the menu instead of the action for the shortcut dialog).

Networking Tools

You have no idea how hard it was to reduce the number of "add" icons from two to one. I nearly died in the process :-S
The difficult part, of course, was to find the answer to the everlasting question "What does each icon mean?"

And these are my findings:

* If you add anything to a list (or something else that is some kind of collection of items), you use list-add.
* If you remove something from that list (or collection) without destroying the removed object itself (because it's only a reference to something outside), you use list-remove.
* If you delete something from that list (or collection) and the item that you deleted had its home in the list and is therefore destroyed on removing, then you use edit-delete.

Remove David Johnson from the copyright list as there isn't a single line of code left from his original skeleton, and the copyright only requires the copyright to be maintained when substantial parts are copied - which is no longer the case

Sorry for that, but I've got two good reasons:
1. It looks vastly inconsistent with user-identity, and
2. From a gender mainstreaming point of view, removing it is probably not more offending than having a male icon as "default" and the female one as suffixed alternative.

This was the last icon naming showstopper bug (breaking interoperability with other icons that begin with network-*), which means that KDE apps won't break when working with other naming spec compliant themes, and Oxygen
doesn't break apps that solely rely on the naming spec.

If we're lucky, both of those should look pretty ok :D

There's more stuff that needs to be fixed (good times ahead!), but now I shouldn't be remembered as "the guy who broke the icons".

We'll leave them this way for KDE 4, it seems to be the more correct approach - the spec is unclear in this regard, and Tango/gnome-icon-theme have them the other way round, but every other real-life application seems to think ascending is A-Z, which means A top, Z bottom, which means ascending == downwards and descending == upwards.

Utilities

Other

Benoît Jacob committed changes in /branches/work/eigen2:

part 2 of the reorganization.

Benefits/changes:
1) Eigen2 co-installable with Eigen1 without conflict, without affecting programs including either.
2) #include<Eigen/Core> without the .h without conflict with the Core/ directory
3) Uniformize coding style of the CMakeLists.