KDE Commit-Digest for 16th September 2007

In this week's KDE Commit-Digest: Continued work in Plasma, including a KMLDonkey data engine, a RSS data engine and news feed applet, and a Virtual Desktop switcher applet. More interface work for Amarok 2.0, with progress on alternate music service integration. Support for webseeding in KTorrent. Support for network access of colour palettes in KolourPaint. An Akonadi resource for the del.icio.us bookmarking service. CMake support for PyKDE4 applications. Wider logging support in KSystemLog. SVG caching optimises usage, resulting in speed gains in many applications. KTeaTime rewritten for KDE 4, KPlayer ported to KDE 4. New game based on "Deal or No Deal" arrives in playground/games. More code reorganisation in KDE SVN. KAider translation utility moves to kdereview.

Dot Categories: 

Comments

by david (not verified)

Wow, I'm really, _really_ impressed by the music support for koffice, it looks extremely good and I'm sure will be very usefull! Is this all written by just Marijn Kruisselbrink in just the summer of code? Impressive!

Do you know if there also will be a little program specialised in writing music like kformula is for formules?

I think KOffice is really going to rock when it's released!

by david (not verified)

Owh and I had another question, do you think musicxml can be added in the future to the odt standart like I think mathml is too?

Thanks,
David

by Martin (not verified)

First take your go 'n kill the Open XML standard

by Hank Miller (not verified)

One way to kill that standard is to make ODF useful enough that people use it. Open XML gets attention because a lot of people use Microsoft Office. The more people we can get using something else, the better chance we have of killing the idea of making Open XML a standard.

To that end, adding things like MusicXML to the standard makes ODF useful to people like musicians. (Particularly if we can get someone from Open Office to add support for it, but also getting support into the programs they use, Finaly for instance)

We can't move everyone to ODF at once, but move small groups over, and those small groups together have power to force the rest of the world.

by she (not verified)

Let others fight _against_ it and we fight _for_ improving the usability and feature set, so that there are *good* and solid alternatives available

by neurondev (not verified)

KDE 4.0 is going to be great. Guys, keep it up.

by Ask (not verified)

Glad that kplayer has been ported to KDE 4. That is the best front-end to Mplayer that handles video in general and videocds, audiocds and video dvds in particular flawlessly. The way it has been designed to work with discs is especially brilliant. Congrats to the developers

by richlv (not verified)

anybody knows how it compares to smplayer ? it also seems to be a very nice frontend (it worked when plain mplayer didn't for me...) and is moving to qt4.

by Alan Denton (not verified)

Thing is, why don't smplayer/kmplayer/kplayer developers collaborate together? Do they have different goals for their players or do they enjoy competing to see who can produce the best? As a bystander, it seems like needless duplication of effort but of course I could be wrong.

by jospoortvliet (not verified)

It's already getting better, the whole player engine is being abstracted away by Phonon. The simple players will really be the same, and I think these will disappear. Only the more complex ones will differentiate enough to survive. Give it some time...

by Richard Van Den Boom (not verified)

Do you know what's the status of Video Player, Codeine's KDE4 version?
That's really the one video/DVD player I want, since I finally switched to Amarok for my music.

by veton (not verified)

SMPlayer is by far the best, no?

It is based on QT4 and Mplayer.
Feature wise it is hard to beat!
Check : http://smplayer.sourceforge.net/en/linux/index.php

by Ian Monroe (not verified)

smplayer has lots of features I can see from the screenshot. It has like 25 buttons, too busy for my taste. Video Player will have like a button and two sliders by default. Anyways it appears they fill different niches in the video player ecosystem.

However I read that smplayer remembers settings for video files, this was always the killer feature for Codeine for me. So that is pretty awesome. :) Every video player should have this IMO.

by Leo S (not verified)

Absolutely, for 95% of my video watching needs, codeine is the absolute best choice out there. Only when I want to watch certain wmv files I use VLC, and only because xine can't decode them properly (lots of artifacts).

by MamiyaOtaru (not verified)

see this entry on Xine's bugtracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1795720&group_i...

certain videos work with ffmpeg (ffplay), mplayer (ffmpeg), mplayer (win32) and xine (win32, you can force it to use the dlls) but are broken in xine (ffmpeg). Really curious.

Anyway, my favourite frontend remains kaffeine 0.4.3. Just the buttons I need , simple keybindings, and I like having language settings right there, and a vertical volume slider makes me happy http://img64.imageshack.us/my.php?image=kaffeine7gu.png

by Richard Van Den Boom (not verified)

That's one thing I would like to have in Codeine / Video Player : the ability to select language for sound and subtitles through a right click option.
Very nice when the video is set full screen, you don't have to reduce it to access a menu entry.

by Richard Van Den Boom (not verified)

Exactly. Just one button, one or two sliders, starts almost instantly when I double click on a video file, remembers settings for each video file AND no system tray.
As far as I am concerned, I prefer xine support than mplayer, since I'm running Slackware and xine is provided with the Slack.
So yes, bring in Codeine / Video Player as it is, that's all I want.
I understood you had your hands full with Amarok, but do you think Video Player will be part of KDE 4.0 or do you plan to release it outside KDE?

by hmmm (not verified)

KPlayer has even more features, they are just less intrusive and not visible in the initial install, but are very easy to find and turn on.

KPlayer is more complete compared to SMPlayer and everything else. The multimedia library and the device handling are the killer features. Playlist handling is very nice as well.

by Stephan Sokolow (not verified)

Definitely too busy. I wrote my own "ideal video frontend" and it's just a PyGTK XEmbed socket in a frame (so MPlayer can't un-minimize against my wishes when it changes files) and some Python scripting to keep track of which anime episodes I've already watched.

It looks and acts just like the non-GTK mplayer binary... just a bit more intelligent. The TODO list is still fairly large but it's usable and you can pull the bzr repo at https://launchpad.net/animu-player/ if you're curious.

Oh, in case anyone is still reading, here are some of the ideas I had for future features:
- higher-resolution tracking of where I left off in a file which will facilitate...
- ...a mode which creates virtual channels on-the-fly using a heuristic guesser and allows channel surfing with IR remote support via PyLIRC (so I can comfortably browse anime from my bed
- A simple menu/dialog with HAL support so I can stick a DVD+R in the drive and resume where I left off with two clicks and no more. (Or two button-presses on the IR remote)
- etc. etc. etc.

Yeah... I'm *very* lazy.

by Ian Monroe (not verified)

Vir made it compile recently, but it crashes on startup. Amarok 2 is taking up my coding time currently.

by David (not verified)

I wonder if there will be a plasmoid for being able to reproduce a video in a small window and always in foreground. Sometimes I like to watch videos while browsing :)

by No one (not verified)

These multitask people.... ;-)

by André (not verified)

Why do you need a plasmoid for that? Any window in KDE can be made to stay above other windows, so you can already do what you want *now*.

by me (not verified)

...because plasmoids are the latest hype today. I think people would even implement start menus and mail servers as plasmoids these days...

by jospoortvliet (not verified)

well, work on a startmenu is going on, I dunno about mail servers - but I'm pretty sure you'll be able to contact them using aKonadi ;-)

by Aaron Seigo (not verified)

of course, it won't be complete until there is an irc client and a text editor. =P

by Sutoka (not verified)

Great text editor, could use a desktop though. ;)

by MamiyaOtaru (not verified)

Maybe someone can make an emacs plasmoid and get all that at once ;)

by André (not verified)

For that, we would just embed a KPart in a Plasmoid, no? :-)

by olahaye74 (not verified)

Would be so cool to have Kaffeine and Amarok in a single multimedia app.

I have a lot of Music titles stored as video clips, but not all. And I'd like to have playlists that mix video clips and mp3 files.

When friends are at home, I'm using a video projector to display video clips with kaffeine, and I'd be happy to have mp3 files played within video clips (displaying visual effects). But AFAIK, it's not possible for now (while it is using winamp on windows).

Each apps would benefit the other app great features. Multimedia desktops like MythTV and such are only regrouping multimedia applications and thus does not permit (AFAIK) the above.

Though that's only my personal feeling....

by Darryl Wheatley (not verified)

That's a cool idea - a "Media Konqueror" of sorts. But seeing as how the swiss army knife approach is being abandoned in KDE 4 (Konqueror->Dolphin as default file manager), such a program would probably only be an optional extra...

by aha (not verified)

You just described KPlayer precisely. Go try it, you'll like it.

by annma (not verified)

The commit digest does not mention that on Saturday the KDE-Edu team had a debug day (Polishing Day) and fixed several bugs. GUI also was improved following users feedback (KHangMan, Marble, KGeography and blinKen). Very often us developers know our application so well that we are not able to see it the way the user does.
Thanks to all people who participated. Special thanks to Albert "tsdgeos" who fixed a lot of code!
We now need to set up a Polishing Day for more KDE core components!

by Inge Wallin (not verified)

This is an important point. In fact, I think it's so important that you should write a separate article about it. Lots of pics of 'before' and 'after'. Kudos to the participants. Descriptions of the adorations of the masses. That sort of thing.

by Emil Sedgh (not verified)

Its really nice to hear from Akonadi
keep up the good work PIM dudes...

by am (not verified)

Woot! Great app, small, simple and to the point. Easy to forget when coding.... :)

by Stefan (not verified)

Without KTeaTime, my pizza would have burnt in the oven several times.

by Vincent de Phily (not verified)

These plasma data engines will definitely be usefull, but a question keeps nagging at me : aren't we reimplementing a read-only, kde-centric version of DBUS ? I have a vague feeling that plasma engines are more ressource-efficient, but that's the only advantage I can think of.

What's the advantages of plasma engines over DBUS and vice-versa ? When should we use one over the other ? Does it make sense to write "DBUS plasma engine" and "plasma DBUS service" bridges ?

by jospoortvliet (not verified)

dbus is a communication protocol. plasma data engines GENERATE the data, eg download & parse data from several weathersites and expose it to the plasmoids (that last part could be dbus, maybe it even is, I dunno).

by Richard Dale (not verified)

The plasmoids and data engines are all in the same process and so there is no need to use dbus. The data engines just emits a signal with a hash of names and their values, and a slot in the plasmoid picks that data up.

by Aaron Seigo (not verified)

the point of DataEngines is to provide a uniform API that is data-centric to a variety of sets of information. the implications of this are many, including the ability to write generic visualizations (meters, text displays, etc) that can be connected to any engine or the ability to easily access a wide variety of data from scripting languages. the other goal is to keep data presentation *simple* as opposed to complex custom data structures.

it's a very specific (to the use cases of plasma) model/view implementation. dbus is inter-process communication. the two have nothing to do with each other, other than the fact that some engines use dbus internally.

by Richard Van Den Boom (not verified)

... I would just want to suggest to KWord developpers to have a look at Lotus Word Pro. I don't think it's still developped by IBM but even the 2000 versions would do.
There are a lot of wonderful ideas in this soft, like a tab for chapters, tabs that you can reorganize by drag/drop (with automatic adjustments of indexes and tables of contents), automatic formatting, contextual attribute box. I've never find any word processor, free or not, to be as easy and powerful as this particular one. Since a lot of work is made on KOffice, I wonder if it's not the good moment to suggest to adapt some of these features.

Hear, hear! I absolutely agree with this. Lotus Word Pro is still the most elegant Word Processor I have every used, especially with its lovely modeless, "floating palette" interface. The only piece of software I miss from my Windows days. I hope that Open Office or KOffice can take a look at this and seriously begin implementing its features, especially the beautiful GUI.

you mean the Lotus that IBM just put up as a free download, for both windows and linux? :) http://symphony.lotus.com/software/lotus/symphony/home.jspa

by Richard Van Den Boom (not verified)

I've read that it was based on OpenOffice, so I don't expect to have Word Pro in it.
Well, I'm downloading it anyway, so I can see what it is.
I'd prefer an Open Source office suite, though.

by Thomas Zander (not verified)

I'll gladly borrow good ideas; but I don't have the sofware. Please spent some time explaining them. Maybe a long mail to the mailinglist? Or a couple of wishlist items on bugs.kde.org?

by Richard Van Den Boom (not verified)

OK, I'm going to send a mail to the mailing list.
I still have one version somewhere, I can probably install one to take some screenshots.

Hello Thomas,

I raised the issue with the Abi people quite some time ago. If you look at this report in their bugzilla, you will see many screenshots of the Word Pro interface and a great deal of information about how it all works:

http://bugzilla.abisource.com/show_bug.cgi?id=7283

I hope you will seriously consider this as most people who have used Word Pro have (anecdotally) reported it to be the most intuitive and elegant word processor that they have used. The same floating palette-tab system was used throughout the suite.

by Richard Van Den Boom (not verified)

I don't know if my mail went through to the Koffice mailing list, Gmail seems weird in the sense that I don't seem to get back the mails I sent to ML in general.
Here's a copy, sorry for double posting :

***

Hi,

first, thanks a lot for the wonderful work done on Koffice, I've been using it
quite often for years now and am really impressed by how far it has come.

Following a bit of a stupid post I made on the Dot, Thomas Zander suggested me
to post it on the Koffice mailing list, so here we go.

Lotus Word Pro is definitely the most confortable, powerful, well designed
word processor that I've used for the last ten years. It had (I use the
passed time because it seems to have been killed with Smartsuite by IBM) many
features I've never seen in any word processor and which I found using it
extremely useful.
Since Koffice is having a large overal right now, I though maybe it could be a
good idea to point out these features, if some of them could perchance be
implemented easily :

***
1/ Usage of styles :
Word Pro used styles for everything : paragraphs, characters, frames, tables
like many now, but also headers, footers, page layout. You could create a
style for every single object you can put in a document. And of course, you
could import and export styles. That made creating page layout almost as
powerful as a PAO software.

2/ A single, contextual, attribute box :
There was only one box displaying styles and attributes. The display was
context sensitive, meaning the displayed styles and attributes were dependent
on the selected object. Any change in the attribute box was reflected on the
selected object dynamically. This made formatting much quicker than having a
pop-up box, select your options then validate/apply. And it reduced quite a
lot the crowing of the interface. This is a bit what Scribus has now, but the
box was small, with many tabs, instead of these rows of options that I don't
find very practical in Scribus. There was a drop-down menu also allowing to
select what type of attributes you wanted to view, in case the selected
object allowed for various settings.

3/ Organize your docs in tabs
You could organize your documents in several divisions, each one appearing as
a tab. Each division could have a completely specific style of page layout,
numbering, styles. It was completely as a separate document, to the point
that you could import an external file as a division. The interest is that
page numbering, table of contents and indexes could be generated on the whole
document. You could reorganize tabs ( like chapters) by simply drag and
dropping, and page numbering was automatically reflected (though I think that
ToC and Index needed to be updated). This was really great to deal with large
documents with many chapters.
Note that this generalize basically the notion of Sheets in Spreadsheets.

4/ Quick format
There was an option that came a lot later to Word, which is quick formatting.
Basically, it allow you select part of the text, click on the icon, and then
every part of text that you select will be formatted the same way, until you
click again on quick formatting. Word Pro offered an added goodie, in the
sense that is allowed either to apply the actual formatting of the initially
selected text, or the style. The later made changes so much quicker.

5/ Research / replace styles
It was possible to look for occurence of a style and replace it with another.
Believe me, it was wonderful.

***

Well, that's all that comes to my mind, right now. I would need to work with
it again to remember other useful features. But the ones above are obviously
those I miss the most.
Please let me know if you want some screenshots or more explanations.

Again, thank you all for all your work.
Best regards,

Richard Van Den Boom

Richard,

I have also emailed Thomas directly with some specific detailed information relating to the "single, contextual, attribute box" which was the feature I most desire in a Linux word processor. He was very gracious in his reply and promised he would look into it.