In this week's KDE-CVS-Digest:
amaroK adds graphic sonograms.
KolourPaint can be used as an icon editor.
KPilot PIM integration improves.
KMail folder code is refactored.
KWord adds import of text boxes from OOWriter.
And the last bugfixes before release.
Dot Categories:
Comments
KDE - the only desktop where a woman leads the commit statistics. ;-)
it's cool.. :)
A very good translator/writer...
You don't know women who code, or?
Eva is a coder as well.
Anne-Marie Mahfouf created and maintains a couple of applications of KDE Edu.
In fact she is the module maintainer.
But how is it possible; 54 lines changed in 308 commits...?
It wasn't really a mistake. Eva created a whole bunch of directories under kdenonbeta/kdedebian/livecd/gui/home/.kde/*.
There is a way to do it all in one shot, without triggering emails to the kde-cvs list for each one. But it happened one by one, thus the large numbers.
derek
I see that more languages have hit 100% than the last time I looked a couple of weeks ago.
See i18n.kde.org/stats...
actually more than 3 teams reached 100% since in that stat is included
koffice HEAD (while translation is going on in koffice1.3 branch) and kdeextragears that are not released with KDE 3.2
Here is a screenshot for the curious: http://members.aon.at/mfranz/sonograph.png (12kB)
OMG. That's it. You can now dump Noatun (for which I never cared for, no offence) and Kaboodle (something I never understood why it was there) and standardize on AmaroK for you non-jukebox music player. Please.
...actually, can it deal with video, too, like Winamp?
This is really neat. I will now be able to dump XMMS and go with a fully KDE-saavy music player.
No I've never cared for them, or used them. I think some clean up is probably necessary. I managed to try out Juk recently, and I liked it. There are some things to improve, which I think people know about anyway. With these made and maybe some nice Karamba extensions so you can do things without viewing the whole app I'm seriously going to enjoy it. I've heard some accusations that it looks like iTunes and people will get confused - rubbish!
Personally I don't like combined video/audio/music applications (think Windows Media Player). They are just too cluttered and are not too good at one and not too good at the other, although Juk can be a means to organise all of your video stuff and play it through another media player. Kaffeine maybe.
Actually I would prefer a streaming server style (like mentioned in http://dot.kde.org/1074190748/), but maybe mplayer's streaming server might/would do also, mplayer at least would support much more video formats and is quite nicely embeddable to the kde with kmplayer/mplayerplug-in. :-)
> mplayer at least would support much more video formats and is quite nicely
> embeddable to the kde with kmplayer/mplayerplug-in
Just what is it that I don't understand?
You are comparing: "mplayer" to what.
You should be comparing it to XINE which is what N/K use as a backend.
Which video formats does mplayer support which XINE doesn't.
N/K play QuickTime movies with sound OK on my system.
Note: what doesn't work is the KDE Embedded Media Player. But that is a bug issue.
You should also consider that mplayer is video card dependent where XINE is not. This is one of the reasons that KDE chose XINE over mplayer.
--
JRT
JuK, amaroK, Kplayer - that's my personal KDE music/video suite.
I second that motion!
i personally like amarok and kaffeine, although kplayer and juk are also quite capable.
noatun sux.
> can it deal with video, too, like Winamp?
No. I'ts a music player.
Does anybody else have a problem with the default amarok visualization (in 0.83) taking up like 80% of the CPU? I've got a 2GHz machine, and whenever the Amarok window is visible, things start getting jerky.
Never seen that. The cvs version uses around 0.3% on my computer (2.4GHz).
He means cvs, and the distort widget is default. It takes up 100% on my Athlon 1800XP.
I think it's likely we'll set the default to one of the others for the next release. It's only cvs that has distort as the default.
IMHO I would like to see all those tiny (specific use) apps to be merged, for example why should user know a thing about different document/image (actually any file format that can be just viewed without any interaction) formats, thus I would like to see kpdf, kdvi, kghostview, kfaxview and kview to be combined as a general purpose "viewer" for KDE.
That kind of combining might also be used on other type of filetype handlings, like merging all separate text editors together, like kate, kedit, khexedit and kwrite to become a text editor that might have different modes to be accessed via similar method as konqueror toolbar changes for task in hand (or vertical tabs on the sidebar to choose how to highlight the text?).
Bigger change that I would love to see would include merging of apps that actually perform similar tasks, like kooka that might include support for inporting images from any source, like scanner, digital camera, web camera, gd and similar inputs, with gocr of course. :-)
> I would like to see kpdf, kdvi, kghostview, kfaxview and kview to be combined as a general purpose "viewer" for KDE.
Already done, it's called "Konqueror".
Hmm... Maybe I have talked about this with you already?!? :-D
Anyways, I would like to see those progs to be eliminated and to use a "kview symbolic link" to konqueror then.
What way I should configure my system that konqueror would show only wanted toolbars with items I would like (as a clean view window)?
Being able to use konqi to view all those types (ps, pdf, dvi, the fax format, images, ...) doesn't make the plugins' GUIs consistent, unfortunately.
Now if all of them offered the same features (e.g. preview bar on the left for multipage documents, selection of pages, mouse wheel zoom) in a consistent way...
That would be very great thing to have as it's just silly to have exactly same functionality, but just differently showed to the user, kde should embrace HIGs on that too.
Yes, that is true.
No, I think that he has a point.
Since some (or all) of these "applications" are built with a front end and a KPart. It should be possible to make a single KViewer front end for these various parts so that they could be used without opening Konqueror.
--
JRT
You're not the only one who feels that way. I think we'll see a lot of that happen in KDE 4.0 - unifying things, throwing out old and obsolete apps. You can't really do it for a 3.x for compatibility reasons, just like you can't change the default GUI theme with every point release. But I expect some major clean-ups for the next big release.
> IMHO I would like to see all those tiny (specific use) apps to be merged, for > example why should user know a thing about different document/image (actually > any file format that can be just viewed without any interaction) formats,
> thus I would like to see kpdf, kdvi, kghostview, kfaxview and kview to be
> combined as a general purpose "viewer" for KDE.
It's not only "why should the user know", but also where should a feature request be dropped? Should the request be sent to all (in my case) kde digital
picture viewers? If yes and all the involved apps are registered in
kezilla the same feature request must be entered multiple times which is to my
opinion polluting the bug database.
Combining the application, if possible, would be a good thing indeed.
No source for Crystal icons?
http://osnews.com/story.php?news_id=5693
it gets sorted out one way or the other and 3.2 gets released regardless of what that ends up meaning. the icons exist in CVS, so there's no reason to hold up the release. and it isn't like someone is holding them hostage, they're just in a rather unfortunate state at the moment. fortunately there are more people of late paying attention to the icons, so i'm sure it'll get sorted out eventually to everyone's satisfaction.
at least Eugenia managed to get a few more pieces of FUD in about KDE and it's level of support from third parties. =/
Doesn't really help that any post directly doubting OSNews.com's journalistic integrity and/or objectivity in the matter gets either deleted or instantly moderated down [at OSNews].
ISSUE SOLVED! http://www.osnews.com/comment.php?news_id=5693&offset=60&rows=64#188798
Congratulation Julian :-)
http://opensource.org/OSA/awards.php
Bye
Thorsten
I don't understand why people want to remove noatun.
noatun is for me a very good sound player. It is not perfect but it can be enhanced.
noatun good points :
- playlist style changeable (Dub, Hayes,...),
- real[1] changeable GUI (xmms skin, kjofol skin, KDE style,...),
- Visualization plugin,
- Other plugins (key, Alarm clock, infrared control,...),
- Remote control via dcop,
- Certainly code well organised regarding the pluggueable facilities,
- Benefit of arts effects that are chainable[2]
- Well integrated in KDE (native interface),
- ...
noatun bad points :
- No juk style playlist (who make the plugin ?)
- Some playlist can't have stream url (hayes,...) (Can playlist plugins support .desktop files of type Link ?),
- Only arts background sound system (I suppose that it can be change without much break : gstreamer ?),
- Video system which one is the best ? I don't know if noatun use xine or a internal one ?
You can complete the list if you want :)
[1] Not a hack as in xmms with kjofol skin plugin.
[2] In xmms only one sound plugin can be used at the same time
So why not enhance noatun or change bad part of it ?
kaffeine is great for video but I hate it for playing sound as I hate using xine for playing sound ;)
amarok is great but I don't like very much its look & feel : not a native gui (new widgets, new buttons, new color in the list,...) and amarok is still beta (some options doesn't work).
xmms was good but it is gtk application and it doesn't interract well with KDE application. It has a strange feel which doesn't respect as the Window Manager was configured (don't show window content when moving,...). It is gtk 1 application and now gtk 2 is here. A gtk 2 version will exist but not completely finish yet.
kplayer, kmplayer, kxine,... very great program for video playing but not for sound.
juk is very good but doesn't support stream and has some strange behaviour sometimes. Moreover it is not a good program if you want to play only one sound (kaboodle is here for that).
Here is my opinion. I wait for yours ;)
Having the ability to use plugins is NOT an if there are no good plugins to use! IMHO all the Noatun playlists suck. Almost all the GUIs suck. The visualization plugins are laughable compared to, say, Winamp's. ARts sucks. Basically every part of Noatun sucks, except maybe for the Keyz plugin and the system tray interface. I say take those and dump the rest.
This is the way it should work. Instead of having one mediocre audio/video player, KDE should have:
1. A video player that doesn't play plain audio files. The default GUI should be extremely simple, hiding advanced features like playlists and video processing tools in the menus. This player should also integrate with Konqueror to play movie trailers on websites and stuff.
2. An audio jukebox/library application that has plugins and doesn't play videos.
3. A simple *sound recorder/editor*, like Sound Recorder for Windows, but with a few more editing features.
4. In the future, when GStreamer matures, a video editor.
All these apps should use GStreamer (and maybe JACK) instead of aRts. If KDE had this stuff XMMS might finally be on its last legs, aRts could go back to being a synthesizer instead of an audio framework, and some of the development effort now focused on MPlayer/Xine might go to the much cooler GStreamer project.
KMplayer already does the first bit of what you want -- integrate with konqueror to play movies on websites. It also has a very simple interface (I'm not sure if it has playlists -- and frankly, I don't see why a video app should).
As for audio amaroK looks to be coming along really nicely -- I personally wouldn't mind if it played videos too, though there's no real need. A nice interface that looks similar to amaroK's would be cool in a video app, though -- besides unifying things, it would look quite slick.
I also agree that arts needs to be dumped as sound server, unless it can truly be fixed -- but I think it would be better to simply switch to a better system, like JACK or one of the other sound servers. What would be even nicer is if freedesktop.org could choose one, and GNOME and KDE could both use it. That way, there would be a truly "standard" platform to write audio apps on for linux.
freedesktop has already chosen gstreamer
http://gstreamer.freedesktop.org/
Well, "chosen" is too strong a word:
From http://freedesktop.org/Software/Home:
--------------------------------------------------------------
Software hosted on/related to freedesktop.org
Some software has made its way here to live. None of this is
"endorsed" by anyone or implied to be standard software,
remember that freedesktop.org is a collaboration forum,
so anyone is encouraged to host stuff here if it's on-topic.
--------------------------------------------------------------
But still, a unified multimedia framework would be nice.
GStreamer is only in Gnomes's freedesktops CVS, that shouldnt mean freedesktop will try to establish it as the default framework in KDE, but you are right by saying that at some point they will.
Freedesktop is kind of a failed experiment, because it smells like glib is going to be used as a foundation instead of something modern (its in dbus too even though it doesnt link, but has code pasted in). By choosing glib freedesktop has already revealed that it was only pretending to be desktop neutral. So the correct name for it is really gnome-feedesktop now.
And the fact that lots of old school C- boneheads hang around there doesnt really make it very attractive to a modern KDE developer I could imagine.
At the moment there is not much there that would make Gnome's freedesktop attractive (code-wise). DBus is slow and unsafe (programmed in C), the HAL is only sysfs parser, keithp graphics work is far away from being an XFree86 replacement, though the most promising part of it.
Freedesktop.org is no GNOME invention or spin-off.
Glib has not really be chosen. And DBUS has no dependencies (if a few lines are pasted from Glib it does not hurt). Of course there is an API for Glib on top of it, but a Qt API is also provided.
Using a unified messaging system is something that can really be useful for KDE. Wheter it is developped in C, or C++ is not really the problem, having more developpers (and users) involved in the project would actually help to make it safer, fix bugs and improve performance.
And for your information, the DBUS developpers have chosen to make it close to the current DCOP implementation in order to simplify its integration into KDE, so really this is not a GNOME-specific technology.
> Glib has not really be chosen.
not officially, right.
>Using a unified messaging system is something that can really be useful for
>KDE. Wheter it is developped in C, or C++ is not really the problem,
actually it is a problem. KDE shines, because it breaks with an old unix legacy to write everything in C. legacy-C applications are a serious security risk and hard to maintain. Just look how many times CUPS is in the security news.
There is absolutely no need to write a new piece of software like bdus in C. Since you have to provide a glib wrapper anyway it should better be done in stdc++ or something similar.
Well, dbus is mostly a protocol and data marshalling convention.
You are free to do a C++ implementation and I am sure freedesktop.org will host it as well.
true. maybe I will :)
but Gnome's freedesktop wont like it.
GNOME doesn't "own" freedesktop.org.
> By choosing glib freedesktop has already revealed that it was only pretending to be desktop neutral.
Erm, Freedesktop never "chose" glib. It just happens to be an implementation detail of some things, like gstreamer. Freedesktop has a commit policy that pretty much allows anything. Yes, if you want to write something in Qt, you can probably add it to freedesktop cvs.
> that shouldnt mean freedesktop will try to establish it as the default framework in KDE, but you are right by saying that at some point they will.
Well, KDE should consider it's various alternatives, because there is a lot of things besides gstreamer, but, I don't see much of a problem in terms of dependencies switching between arts, which already uses glib, to using gstreamer, which also uses glib.
Uh, I don't see why using GStreamer would be a bad thing, as long as it doesn't have cumbersome or obsolete dependencies. Because many high-visibility Gnome developpers often display an astounding lack of understanding of good software design, doesn't mean that being one suddenly turns all of them into incompetent codepissers. If GStreamer is well designed and not clogged up with ill-thought design goofs and other gnomenesses, I can see absolutely no reason not to use it. I mean, gee, didn't KDE become the leading desktop by always picking the best technologies regardless of politic issues? What remains to be seen is whether GStreamer cuts it as a technology. Note, I have no idea as to whether it does, so please fill free to fill me in, either way. Otherwise, refusing to use it just because it's a Gnome thing, even given Gnome's poor track record, is not a very clever attitude.
If gstreamer is better than arts, I don't see why it would be a bad thing for KDE to use it. For me, arts never ever ever worked so I would welcome any replacement.
> Freedesktop is kind of a failed experiment
That's bullshit. Freedesktop is actually a very successful experiment, with established successful important standards that allow (more or less) slick interoperatility between desktops without preventing any of them to innovate. We already have common drag'n drop, independant window manager, common .desktop description and application menu compatilility. I am looking forward for the next advances (shared mimetype database).
> By choosing glib freedesktop has already revealed that it was only pretending to be desktop neutral
That's bullshit again. At some point, when you write code (do you write code by the way ?), you have to manipulate lists, dictionaries and strings for the very basic minimum. You can use glib, you can use the C++ stl or you can use Qt or you can write your own buggy non-optimised version. But you have to use one and this is no way related to choosing one desktop. The author of DBUS choose glib for obvious reasons: he is familiar with it and he codes in C. Using Qt would have been stupid (why use a GUI toolkit for a non-gui stuff). He could have chosen tinyQ but that's not as official as Qt so it might not be as stable or maintained. What should he have done in your opinion, using its own buggy version of glib ? The only difference would be that you did not know that he used glib. What a huge benefit.
> And the fact that lots of old school C- boneheads hang around there doesnt
> really make it very attractive to a modern KDE developer I could imagine.
The same goes for them. The fact that young OO-fan hang around does not make it attractive for old-school C coders neither.
However, what makes freedesktop attrative to both groups despite their differences is that they cooperate to provide the user with the best and consistent applications ever.
> DBus is slow and unsafe (programmed in C),
Is this supposed to be "it is programmed in C so it is slow and unsafe" ? While I certainly don't love C for many things (especially gui programming), there are some very good and safe programs written with it.
For DBUS, there are problems with it (although I am not familiar enough) but the concept of having a common communication protocol between gnome and kde apps is very exciting. I hope there is not technical difficulties that can not be overcome with a distant adoption of DBUS for kde.
> If gstreamer is better than arts, I don't see why it would be a bad thing
> for KDE to use it. For me, arts never ever ever worked so I would welcome
> any replacement.
Yes. I like JACK personally.
> That's bullshit. Freedesktop is actually a very successful experiment
Politically, in the long run I question it.
Isn't glibc part of every major Linux distribution? Why not use it?
> Politically, in the long run I question it.
A lot of exchanges are only detail dicussions, not disagreement on the major concepts.
IMHO its a pretty cool idea, because it gets people of all relevant parties to start exchanging thoughts very early on, even before some desktop specific or related implementation sets some kind of hard to accept standard.
> Isn't glibc part of every major Linux distribution? Why not use it?
I assure you, glibc is certainly used :)
This is the C standard library.
However, it does not include containers like the C++ standard lib, that's why C developers use glib.