|
Much work in Amarok, with the implementation of a CoverFlow-esque OpenGL album art visualisation, codenamed "CoverBling", and Service Framework and Plasmification efforts. Sample OpenGL-based applets added to Plasma, with Plasmoids to watch for changes to files, for browsing files, and to monitor network interfaces. General progress in the 2d projection and KML in Marble, OpenPrinting, and KOrganizer Theming Summer of Code projects. KWallet support in KRDC. KMines essentially rewritten with a QGraphicsView base, with support for multiple background SVG themes in KGoldRunner. More manipulation and view work in Kreative3d. Implementation of Kubelka-Munk paint mixing research in Krita. Internet integration in Kaider, with a WebQuery view and example script to use Google Translate. okular becomes usable as a print preview component. KTrace, a "strace" interface for KDE 4 added to playground/sysadmin. Beginnings of support for ComunIP, a Brazilian IM protocol in Kopete. More progress in the porting of Digikam and KTorrent to KDE 4. The start of a rewrite of the Oxygen widget style. KBFX, an alternate K menu, moves to kdereview.
|
Mark Kretschmann introduces the work in Amarok this week, implementing a CoverFlow-esque OpenGL album art visualisation, "CoverBling":
|
Everyone loves iCandy! Our loyal Amarok users are no exception to this rule, so we're trying to make Amarok 2.0 especially pretty. Since the day Apple released a new version of iTunes with the CoverFlow feature, users have been asking us to implement a similar feature in Amarok. Being a bit of a graphics nerd, I had been toying with the idea for some time. Two weeks ago I decided to give it a try, and although I hadn't been coding graphics stuff for a few years, the initial results were encouraging enough to sparkle my motivation.
Starting with a simple textured rectangle zooming around, I've quickly added reflection effects, proper perspective projection and the ability to show multiple cover images and move them in interesting ways. We're using multisampling (full screen anti-aliasing) by default, which creates a very pleasant image quality without jaggies.
Yesterday I implemented object selection, which means that we can detect over which image the mouse cursor hovers, and react accordingly. Then I had a brainstorming session with Seb Ruiz about the design and mechanisms of CoverBling (that's the working title I have chosen for this feature). We definitely do not want to simply copy CoverFlow, as I think that would be really lame, and potentially also trademark infringing. Instead we want to come up with something cool (or ideally even cooler) on our own. So far we've had some interesting ideas, and I've started to implement one of Seb's ideas, and we'll see how that pans out. If you have some good ideas, we'll be very happy to hear them.
In other Amarok-related news, we have been considering moving to Plasma for the context view (the big display in the middle) in Amarok. This move was initiated by Leo Franchi, who is working on the context view as his SoC project. Leo started an experimental branch in SVN for the Plasmification, and I'm extremely looking forward to see the results. On the downside, the move to Plasma means that we have to trash most of the existing code for the context view; almost a complete rewrite is required. On the positive side though there are the great possibilities that Plasma offers us: Ability to include scriptable Plasmoids, fancy SVG rendering, and theming. Also we don't have to reinvent the wheel (or "invent a bike", as we like to say), but we can combine our efforts with the Plasma dudes. The move is technically not without problems though; libplasma requires a few modifications to be useful for Amarok. Leo has prepared a patch for libplasma, and we would be happy to get this patch in. At this point I'm calling out to Aaron: Please contact us, we've been trying to get hold of you ;)
To sum it up, I think there are some very exciting times ahead for Amarok 2.0. And the best thing for me is that the OpenGL hacking has really brought back my motivation to hack on new features. In the end it's all about motivation, isn't it? :)
|
|
Boudewijn Rempt provides an update on recent happenings in Krita:
|
Emanuele Tamponi's recent work is really utterly impressively cool - here we have someone who goes through all academic papers, reads and digests them and produces unique software that's simply the first generally-available anywhere.
Emanuele's current work, on mixing colors using the Kubelka-Munk research into the reflectivity of pigments will make painting so much more natural and easy.
On the other hand, Sven Langkamp is working on selections, which is less glamorous, but when suddenly everything everything starts working the way users feel it should, it is a hugely important advancement. When software changes from "it works, but it also kind of naggingly sucks" to "oops, I've done the job I fired up Krita, too", that last oops isn't often conscious - but it does make a huge difference to the experience of the user.
On the less pleasant side of things, we've had a kerfuffle this week about our metadata implementations, but that's been resolved and we've found a way forward. Krita will rock, metadata-wise in the end. Cyrille Berger, one of our most prolific and versatile coders, has decided that he didn't want to saddle me with the task of implementing metadata - including EXIF and XMP support - and has already restored the code. He is going to continue working on it - but he will only discuss his work with people who know something about the subject. Sometimes, a developer needs some peace to develop great software.
Personally, I think Cyrille is very qualified to work in this area, and since he has said that he had already mutually fruitful and conclusive discussions with the Strigi and NEPOMUK people I completely trust him with this task.
Recently, Krita was reviewed in Linux Journal. This article gave a highly-positive review of Krita, especially in light of his quibbles, namely with the text tool and LDR-to-HDR bracketing, both problems which are solved in trunk - thanks to Thomas Zander and Cyrille Berger, respectively.
|
|
Richard J. Moore proposes to remove KJSEmbed from kdelibs:
|
After discussions at akademy, I'd like to propose the removal of KJSEmbed from kdelibs prior to the KDE 4.0 release. The functionality of KJSEmbed is basically duplicated by QtScript, and it seems pointless for us to maintain KJSEmbed when we have a solution provided by Trolltech that can do the job just as well. In order to do this, we need to do a couple of things:- Remove KJSEmbed and the KJSEmbed support from Kross.
This can certainly be done by the 25 July deadline. - Add support for QtScript to Kross (I've looked at the KJSEmbed plugin and writing a QtScript equivalent should be pretty simple).
This can probably be done by the 25 July deadline.
- Include some plugins in kdelibs that extend QtScript in order to replace the functionality it is missing.
This is harder to do by the 25 July deadline but could be omitted (or released separately if necessary).
I've already implemented the basics of the plugins, so that scripts will be able to create dialogs etc. using UI files, though I think the API I currently offer to scripts needs a little more thought.
I covered the details behind the reasoning for these changes in my Akademy presentation.
|
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
![[*]](/images/standard/bugfixes)