Good idea, but you should maybe divide between audio and video players.

amaroK, JuK (and Noatun really, too) are specialized in audio playback, while the others are tailored to do video, or both.

A poll might be more fair than the current system, which makes it very difficult to replace applications in KDE which happen to sit there for quite some time, but without much progress really. I'm especially thinking here about the possibility of amaroK replacing Noatun for KDE 4.

I've heard this comment several times. Now I'll ask why? Just because of a pretty interface? They have a big problem. They are implementing very special features, when basic features provided by _any_ other player are not in, and the features that are in are only half-finished.

For example... Where's the equalizer? Nobody needs any FX except that, but every cheap player has one.

Then there are several useability problems: nonstandard colors and widgets (of course, nonskinnable, so you have no other choice than dark blue and those tiny fonts), mixed-up radio stations and files,radio lists that have to be fetched every time you start the app, and a simple playlist needs MDI!

I agree, FX are silly, but they came free with arts. One of the FX on my computer is a equalizer, granted its a pretty cumbersome looking ones. I personally never use equalizers.

Overall, amaroK widgets are more standard then usual, certainly more standard then XMMS (even by GTK standards). One of the things I like about it. WinAmp 5 looks beautiful though.

The playlist is my favorite part. In XMMS I have to open up the Open Directory dialog box all the time, have to expand it to see all the directories etc. I use a high resolution so the space saving features of XMMS's play list are of no benefit, though I imagine Amarok's playlist could be made smaller (why its MDI). Amarok interface is very intuitive and make a lot more sense if you have a properly organized MP3 collection then the JuK-style audio players. From what I've seen from screen shots, the one in CVS looks a lot prettier.

Personally, I'm not a big fan of skinning, I just want something that works (I pretty much stuck to the default with XMMS). And I happen to like amaroK's look, though I could see how someone could disagree. It seems like a lot of players sacrifice good usability at the altar of skinning (a word that thankfully has lost much of its buzz). I'd rather they concentrate on making a good default. Audio players traditionally have radical designs, I don't think there anything fundamental wrong with that.

And anyways, we're comparing with Noatun not Kaboodle. Kaboodle's purpose is to be a KPart and for simple "I want to play a file" purposes.

- KPlayer to play video files
- amaroK to play audio files
- pure xine to play DVDs
- KMPlayer for embedded video in Konqueror
- Kaffeine to freeze Konqueror
- Noatun and Kaboodle to take up disk space

At least for me, the old Unix saw of 'one tool for one job' ist still in place.

I blame slashdot. It never used to have this concept of "off-topic", conversations could vary freely where people wanted them too. Then the "off-topic" idea was invented there, and now every joker thinks that they have a perfect right to tell others what they can and can't talk about.

Personally I don't care if people want to discuss fine art or the music of the Beatles here, if that's what they want to talk about then you've got no business imposing your fascist nonsense, so sod off, please.

Heh, I see you love amaroK features :)) I'd say it is a work in progress.
I use both apps (noatun and amarok), depending on my needs, and sometimes on my mood. I like noatun mainly because I need low cpu (XFree) consumption, on a laptop that can't make 10,000fps :) The looks are great too with the KJofol plugins, since I hate small guis (like that of xmms).

I think both apps have their good points. Amarok's new plugins that are coming in are great too, but I'd agree to say noatun is a little bit more mature right now.

Amarok is really promising but not 100% there yet. My own pet hate is that you can't play files directly from the file/stream browser as well as from the playlist, you have to drag them into the playlist first. The streaming buffering needs some work too, or maybe just an option to make the stream buffer bigger.

That said, my ideal media player would be a combination of JuK and Amarok. I'd like to see JuK support Amarok's new player-independent visualisation plugin system, the streaming support and the aRts audio effects. Video would be cool, I don't see why JuK couldn't do this very well too. What I envisage would be a tab/button bar down the left hand side of the JuK window with buttons for 'Playlist', 'Visualizations' and 'Video' and for the playlist to be swapped out for these when you click on the buttons/tabs.

That would make it the best media player on any platform, at least for me. Guess I'd better submit a wishlist bug and/or find some time to get coding...

If you want a really basic player, you can use mpg123 or oggplay. We are talking about KDE 4, dude

> excuse me, but there're much better kjofol GUIS for noatun than that crap GUI of amaroK

Ok. So amarok has a nice and convenient UI. Others do not.

> False. Amarok doesn't have half the functions noatun implements. Never heard of a plugin-based system?

Yes, but I don't see lots of plugins around. and amaroK is in development, is including other (and better than arts) stream systems.

> You're just biased by its looks. Which I, by the way don't like, and others don't either. I can't say I hate the application, but it's still not able to replace juK, noatun, and even less kaboodle

Juk is totally another kind of program, since is a tag based player. Here we are talking about filesystem based players, and I really can't understand how amarok couldn't be loved by every kde-user. Ok, we may leave noatun, but the default should be amarok, and kaboodle should be removed at all.
And about CPU usage, amarok is fast and clean, I don't see any problem at all.

JuK is a decently useful app... but very resource hungry. It especially grinds and grinds and grinds when first loading, seemingly scanning all MP3's yet again... I certainly wouldn't want to see it as a default for anything.

First off, I'll get this out of the way: As much as I love KDE, none of KDE's media players are really up to snuff IMO. I mainly use XMMS for audio, and while I don't watch much video, usually I use either (plain) Xine or GMPlayer.

Of KDE's current audio apps, JuK is the most tolerable. In fact, I'd like to see Noatun chucked in favour of JuK. KMPlayer would be a good for video, as it's a MPlayer frontend, except that its controls are horrible.

Hmm...having emerged both apps, I find that I like Kaffeine, especially as it's a Xine frontend. I now use it instead of Xine and, when I can, MPlayer. Nice visualisation too. Tho I've not tried it with a DVD yet, as I've not re-set up DVD support after recently switching distros.

AmaroK, on the other hand, I just...don't care for. Also, the media control applet doesn't support it yet (only Noatun, JuK, and XMMS).

"Proper engineering criteria" is such a vague thing when it comes to programming. The perfect "abstract" design doesn't exist, only implementations can be seriously evaluated, and programmers have the last word.

> "Proper engineering criteria" is such a vague thing when it comes to
> programming.

It isn't about programing. Engineering criteria are applied to the design of application itself -- then the programing is just the means of implementing the application design. This is the way that engineering criteria are applied to programing -- indirectly.

I see stuff that was programed more than once and designed never.

This stuff still doesn't work and IMHO never will have a chance of working well until it is designed at least once.

This is not necessarily how voluntary work works. You just can't force people to do stuff the way you want it if they think their approach is more interesting, fun and/or satisfying then yours. This may seem irrational to you, but you are seriously wasting your time when you think you can change that.

But it doesn't explain why they need to denegrate engineering to rationalize about the way that they do things.

As I suppose that you know, engineering is anything but abstract. It is not about some "perfect" design. The engineering method is about optimizing a design to meet critera. This is usually done by making the best compromise between conflicting paramaters.

Again, why does somebody need to falsely characterize engineering to justify their flawed methodology? And, why the attitude: "programmers have the last word". As an engineer, I always knew that the users have the last word.

Well, I believe any competent programmer is always optimizing his design, not just typing away lines of code without taking some time to think about the general architecture. What I'm saying here is that it not possible to strictly separate coding and designing, specially when you dont have a strict well defined list of requirements to start with. If you start writing an application knowing exactly what you want, the classic engineering method might work, unfortunately that's generally not the case.

However, it might help to make a distinction between programmer and coder.

The original posting stated that the *coder* should decide.

OTOH, you consider a "programmer" as a person that does both the design and the codding. If that is the case, then why should someone that is only a coder make engineering decisions?

I think that you are still discounting the importance of engineering (the design). I consider myself a "programmer" I can do both designing and codding. What I am asserting (as a "programmer") is that the design (the engineering) is at least as important as the actual codding -- IMHO, the engineering is more important.

In a large project, there is a place for people that only do design work, and they should participate in making decisions.

Not really. This simply isn't how OSS works. It will take almost anything from people willing to commit time and energy to getting stuff done -- no matter how inexperienced -- and it will take almost nothing from people that just want to air their lofty ideas -- no matter how qualified.

This can be brought up over and over again (and well, has been) but it's simply part of the system -- and I don't mean just OSS -- any volunteer organization. You can pretty much either (a) dig in and start working, (b) stand on the sidelines cheering or (c) take your toys and go home.

Your comments are absurd, incredible, the height of arrogance and probably circular reasoning.

You are assuming that engineering isn't work, that it doesn't take time and energy to do design work and that somehow it is just a bunch of lofty ideas. And then using these false assumptions to support your unsupportable preconceptions.

You just don't get it! The truth is that engineering and design is what is important in a large project -- more important than the actual coding. Take the Control Center for example. Do you think that coding will fix that? The last two changes (that I am aware of) made by "developers" have only made things worse. Are you saying that Jamethiel Knorth's work has no value?

And I guess that it will be until the "arrogant developers" understand.

Why to I bring this up again and again. Because I have problems with OSS programs and I look at the code, or sometimes just what it does. I often have this reaction: This can't possibly work, what was the person that did this thinking of. I am afraid that the answer is that they weren't thinking; they didn't design it; they just coded it. Even well written code that does the wrong thing, or tries to do something that is not possible, is virtually useless! And unpremeditated code is rarely well written.

> You can pretty much either (a) dig in and start working,

Again, your presumption is that engineering and design is not work. It *is* work and it probably requires more ability than coding. I know from experience that the design is more work and more important than the actual coding. I can only guess that those that think otherwise simply are not doing the design work.

> (b) stand on the sidelines cheering or (c) take your toys and go home.

That is insulting. I don't know for sure exactly where this fallacious idea starts, but I think that it starts with people thinking that because they have learned a programing language that they know how to write a computer program. I can write English but I don't think that I can write a novel. Would you try to build a bridge without having an engineer design it? How is software different.

If you have some evidence to indicate that engineering and design is not important in software development, please present it. It is useless to just keep saying that it isn't with no supporting evidence.

By continuing to denigrate engineering and design, you are only showing your own ignorance. Unbelievable!

> You are assuming that engineering isn't work, that it doesn't take time and
> energy to do design work and that somehow it is just a bunch of lofty ideas.

No, in fact it has real value, but it has to be converted into something tangible. That doesn't happen just by talking about engineering and software design -- it needs people to do the legwork of converting those designs into software. OSS is built from people that are willing to do both parts.

> And I guess that it will be until the "arrogant developers" understand.

You're standing in the bazaar and complaining that it's not a cathedral. Design in OSS software happens in a fundamentally different way than it does in a traditional software company (I work in such a company, by the way.). Design in an OSS environment is evolutionary, not static -- a lot of things are produced in parallel. Many of them suck and are eventually replaced. Some evolve into something reasonable.

> Again, your presumption is that engineering and design is not work. It *is*
> work and it probably requires more ability than coding.

You're also making the similarly arrogant assumption that none of the people involved in OSS "coding" are also "software engineers" -- which is simply false. Even by your standards many in the OSS community are qualified and experienced software engineers. Many of KDE's core developers studied computer science or software engineering and many of us have experience in traditional computer software design roles. Guess what -- we still produce code. ;-) I call your ideas lofty not because they're wrong, but because they're not independently useful in OSS -- at least not in a direct way.

> I don't know for sure exactly where this fallacious idea starts, but I think
> that it starts with people thinking that because they have learned a
> programing language that they know how to write a computer program.

No, not really. Again -- it's an evolutionary approach -- this time turned around to contributors. People learn when they're involved in OSS. The see the real results of bad and good design decisions. You've observed that this often produces poorly design projects -- of course it does! (Conversly it also produces a lot of well designed stuff.) But while it's producing poorly designed software it's producing better software engineers whose next output will be better. When you let this run over the course of several years you develop a core of people that tend to be on average much better than what you find in the commercial world. It's parallel, evolutionary convergence towards better software and better software engineers -- a "bazaar".

But you can't skip the gruntwork and nobody's ever going to take your word for your experience. There are of course people in any large OSS project that are often consulted for design advice -- or more often designs are proposed and responded to from a variety of folks. But the respect that one earns as a software designer in the OSS world is based on the community knowledge of their designs and the quality of them as seen in their code. OSS doesn't ask to see your resume -- it asks to see your code. The proof is in the puding...

Yes, I think of a programmer as someone who designs and implements. What I dont believe is that is possible to have designing and coding as two totally separated phases of building a program. I don't think the classic plan and implement way of doing things work well with software (note that im not saying that there should be no design at all, which would be ridiculous).

I will quote Paul Graham in "On Lisp"

"It may be difficult to say why the old method fails, but that it does fail, anyone can see. When is software delivered on time? Experienced programmers know that no matter how carefully you plan a program, when you write it the plans will turn out to be imperfect in some way. Sometimes the plans will be hopelessly wrong. Yet few of the victims of the plan-and-implement method question its basic soundness. Instead they blame human failings: if only the plans had been made with more foresight, all this trouble could have been avoided. Since even the very best programmers run into problems when they turn to implementation, perhaps it's too much to hope that people will ever have that much foresight."

At the risk of sounding tedious, I said that the *application* should be designed before it was implemented. The implementation is a program. I would agree with you that you can not totally design a program before you start to implement it. But this does not mean that the application should not be designed first.

There can be considerable discussion of just how much design work should be done on a program before the coding is started. The fact that some things may need to be redesigned after the coding has started does not mean that it shouldn't be designed.

However, again at the risk of sounding tedious, what I was talking about was not the degree of pre-coding design that would be optimum for a program. I am talking about (apparently) totally unpremeditated coding. And, the denigration of all engineering and design as an apparent rationalization for this.

The issue, clearly stated, is the assertion that the *coder* should make the engineering and design decisions for the *application*. Nobody has stated any logical reason that this should be the case.

> At the risk of sounding tedious, I said that the *application* should be designed before it was implemented.

Well you're always using these general words design and engineering without ever saying what you mean with them. You said (https://mail.kde.org/pipermail/kde-quality/2004-April/000466.html) that it isn't about designing the implementation (UML diagrams). You wouldn't even suggest a method how-to do it. You don't even say what method exists and then you except people to understand you?

I suspect that the following small list will help you to get by with all the "arrogant" and "insulting" KDE developers:

- Don't say that the current way is wrong. It's always bad to start a discussion with this because it puts the other person in a defensive position.
- Don't tell people what they should do. It's there FREE TIME!
- Make suggestions giving concrete examples. When the suggestions aren't welcomed provide use-cases and real user experiences.
- Don't get upset when the other person doesn't share your opinion, doesn't give an answer or just a short answer. It's there FREE TIME! You should try it later again with more data supporting your opinion.
- DO THINGS! Offer your help designing an application. Make concrete proposals how do things better. Talking isn't worth anything in a open source project.

I think KFoulEggs is a lot of fun. I wrote a clone of it in highschool for Windows. http://monroe.nu/mandala
So its a clone of a clone. And I wouldn't be surprised if its a clone of a clone of a clone (if Andreas Diekmann got the idea for KFoulEggs from xpuyopuyo for instance).