I forgot to mention above, and again, that the audiocd:/ slave doesn\'t work with all engines. If it doesn\'t work with everything that the player offers, than it just doesn\'t work. If you implemented you own way of listening to CDs, then it would work with whatever engine is being used.

sleepkreep wrote:

Yes, I did. Add listening to HAL and automation can be an option, which is always good. And just for the sake of having integration. Integration is always good. Amarok should be a one-app-for-all when it comes to music. Why have one app for ripping and one app for listening? It\'s pointless and annoying. Like I said, integrating a CD ripper isn\'t THAT important to me, I just think it would extremely convenient. If you want to go through the trouble of teaching how to rip CDs with this app and then listen to them with that app to your wife or teenage son, be my guest. But that\'s one battle I would prefer not to fight. Back to the audiocd:/ slave though.

...so you offer no reasons other then integration for the sake of integration and then say you don\'t want to fight that fight, but instead fight the point that I already said was a valid one. Err, whatever.

Here\'s the facts:

1) The audiocd:/ slave will never change because it does everything it was meant to do. It was never and never will be for listening to CDs.

This isn\'t true, while it probably will not change from a UI point-of-view, its possible that KIO might someday grow up to support multimedia. They are planning a brand-spanking-new multimedia system for KDE in 4.0... hopefully playing CDs will part of it.

2) Since the audiocd:/ slave will never (and has no reason to) change, we need to work around it ourselves.

3) It\'s just proper that a music player play CDs properly. The current way means that it will never change. So lets change it.

4) The audiocd:/ slave is confusing to non-technical users that just want it to work.

But even if KIO supports audio CDs beautifully, that doesn\'t mean that amarok will. We still have the problem of engine selection. Not all engines that are supported by Amarok support KIO. This makes it difficult to use because you have to switch engines if you are using xine, mas, etc.

so you offer no reasons other then integration for the sake of integration and then say you don\'t
want to fight that fight, but instead fight the point that I already said was a valid one. Err,
whatever.

You\'re right, I should explain myself better. There are three types of computer users in the world. The first is by far the majority. The first doesn\'t understand how the software in front of them works and doesn\'t want to. They just want it to work. For them, everything needs to be spelled out. This is the group that you will never hear from on forums like these and in bug/wishlist reports. The second is the same as the first but wants to learn more. The third is everyone that is going to post on this site. They understand how to make things work for them and how the OS works. I strongly believe that all developers should develop for the first kind. Since all developers fit into the third kind it\'s hard for them to understand how the first can even exist. That\'s one thing you have to hand to Mac and MS. They do their best to appeal to the first kind. With the new appeal project in KDE, KDE is going to start moving in the direction to support the first type of user as of 4.0 . This is only smart to get KDE/Linux to grow to its potential user base. I am simply asking you to appeal to the simple minded users that just want the software to work. These people need to be able to know, "If I want to work with anything dealing with music, I need to start Amarok." This is why I preach \'One app-for-all.\' When software in linux has reached this level, we will start to see more and more people switching and doing it comfortably.

Well, it is the type 1 user that we keep in mind (heh, sounds like we\'re talking about diabetes). I just don\'t see how integration is good... more features mean more clutter mean more confusing. Obviously some features can make things less confusing, but I don\'t see how amaroK taking on a task its never preformed before will do so.

As far as what engines support what, clearly the type 1 user won\'t mind not be able to use MAS to play audio CDs and will use whatever works.

sleepkreep wrote:

.... And just for the sake of having integration. Integration is always good. Amarok should be a one-app-for-all when it comes to music. Why have one app for ripping and one app for listening? It\'s pointless and annoying. Like I said, integrating a CD ripper isn\'t THAT important to me, I just think it would extremely convenient. If you want to go through the trouble of teaching how to rip CDs with this app and then listen to them with that app to your wife or teenage son, be my guest. But that\'s one battle I would prefer not to fight.

No no no. The Unix philosophy is "small apps that do one thing well," and this paradigm is what makes it such a joy to work with. Duplicating functionality in all your different apps sucks for lots of reasons.

This is why KDE is so awesome -- the Kpart framework lets you make lots of small apps that do one thing well, and pipe them together graphically. So the ideal solution to this sort of problem is to have the ripper application -- eg kaudiocreator -- provide a kpart that amaroK can embed where appropriate.

So the ideal solution to this sort of problem is
to have the ripper application -- eg kaudiocreator -- provide a kpart that amaroK can embed where
appropriate.

OK, you convinced me. Just as long as it\'s accesable through amarok with an easy to understand interface. To the user, kaudiocreator should appear to be an extension of Amarok, much like K3b is now.

As far as what engines support what, clearly the type 1 user won\'t mind not be able to use MAS to
play audio CDs and will use whatever works.

I have to admit, you\'re right there. Arts is default and since arts uses xine, it will play almost anything. I\'ve heard rumors that KDE 4.0 will not use arts (thank God). Apparently they\'re wanting to replace it with a smaller, simplier engine that supports multi-user systems better. So let me ask you this. If nothing is done with regards to audiocds with the release of KDE 4.0, will you consider creating your own way of listening to CDs, instead of relying on audiocd:/ ?

So the ideal solution to this sort of problem is
to have the ripper application -- eg kaudiocreator -- provide a kpart that amaroK can embed where
appropriate.

OK, you convinced me. Just as long as it\'s accesable through amarok with an easy to understand interface. To the user, kaudiocreator should appear to be an extension of Amarok, much like K3b is now.

As far as what engines support what, clearly the type 1 user won\'t mind not be able to use MAS to
play audio CDs and will use whatever works.

I have to admit, you\'re right there. Arts is default and since arts uses xine, it will play almost anything. I\'ve heard rumors that KDE 4.0 will not use arts (thank God). Apparently they\'re wanting to replace it with a smaller, simplier engine that supports multi-user systems better. So let me ask you this. If nothing is done with regards to audiocds with the release of KDE 4.0, will you consider creating your own way of listening to CDs, instead of relying on audiocd:/ ?

Um, aRTs doesn\'t use xine.

And it isn\'t the default either, unless you have a **** distro that didn\'t distribute anything else.

To my understanding, arts can be compiled with xine support. It\'s been this way since 3.2 . My arts engine can play WMAs and other $MS formats. Is this just part of arts or is it using xine?

I thought arts was the default engine for Amarok. If it\'s xine then why do you even have the Play Audio CD option? Xine isn\'t KIO aware.

Hi,

I just wanted to give a hint to a (maybe) KDE/Engine/OS independant solution to CDDA: libcdio is a portable lib to access many features of whatever-is-inside your CD/DVD-drive. It\'s also used by vcdimager, xine and xboxmediacenter.
Maybe it\'s worth a try?!

animefan

Gstreamer has the highest engine priority I believe, it will be the default if its installed. And it does support KIO.

xine doesn\'t have a monolopy on WMA support, if aRTs has xine support it would be news to me.

I thought aRts was able to use the win32codecs, which xine also happens to use.

In fact, so does mplayer, so its not a xine thing. They just all happen to use the same libraries, iirc.

I know it\'s not a xine thing. I use mplayer and xine both. In fact, mplayer came out with using the win32 codecs first. I just know for a fact that there is a xine-arts plugin that came around the time of 3.0 KDE. And I know for a fact that xine is the default multimedia engine as of 3.1 http://www.kde.org/info/requirements/3.2.php
\"The KDE multimedia system is switching to XINE for basic video support as of KDE 3.1.\" Granted this is for video, but I assumed that arts uses it as well.