Version: (using KDE KDE 3.1.1) I guess this depends on whether the conception of juk is a simple jukebox or a music centre, but I'd like to see it able to rip cds and burn them too. (via plugins i guess).
What you want is KAudioCreator (which is already available) embedded in Juk, isn't it? I'm not sure whether it was planned by the maintainers, but anyways you should know that you can already do what you want.
I've had a bit of a look at doing CD ripping within Juk itself, but I've been a bit pushed for time recently. Ripping should be fairly straightforward, via the audiocd: kioslave. If burning ever gets integrated, it would probably be via a kpart / plugin type system, using the guts of another application.
Subject: Re: CD ripping / burning? Ripping is planned. Burning would be nice, but will be a lot more work. On both of these I have no interest in doing the work myself, but will reuse components from other places in KDE. My first thought on ripping is that it would be a fairly limited thing using the audiocd IO slave. Advanced ripping would be left to KAudioCreator. On the other hand, if (I don't think it already is...) KAudioCreator is made into a KPart, I could play around with this and see if it makes sense to embed that in JuK. Burning will again be a job for KParts. I haven't yet talked to any of the CD burning application maintainers about something like this because it's rather low priority for me at the moment. I'll probably wait to see if there's any movement towards including a CD burning application in KDE 3.2 and then possibly see about getting a KPart for burning. But again, this is something that's probably several months out. There are a lot more important things that need to be taken care of in the short-term future.
I'm marking this one as "assigned" with the goal of getting the ripping end of things done in time for 3.2. Once ripping is in place, I'll go ahead and close this one and play "wait and see" until one of the CD burning apps goes into KDE's main CVS.
I really don't need any rip or burn features in Juk. If you do, please make it not default and/or make it possible to unload it. Cheers, Jeroen
And burning with k3b ? Is k3b allow parameters to directly burn a audio/data cd passed in parameters ? My sister (a non informatician) has created a playlist "To burn" with all my songs that she like. But she don't know that what she expect (burn a cd) is quite more difficult for the moment (so it would be good to implement it, especialy if it's easy with k3b).
I don't like the idea of having N different ways of ripping a CD, M different ways of burning a CD, and K different ways of printing a cover/label. There are already very good solutions for each of these tasks available in KDE. I'd recommend a look at k3b in particular as it apparently makes a lot of its functionality available through libraries. Maybe ask the k3b developers to make them into proper kparts. Michael
Is juk a kpart itself? embeding juk into k3b would be super cool.
> embeding juk into k3b would be super cool. Embedding juk into k3b? Why? However, I don't think juk is a kpart
> > embeding juk into k3b would be super cool. > Embedding juk into k3b? Why? However, I don't think juk is a kpart Well, I think it would solve the cd burning issue... I wonder if there are facilities to transfer an application/kpart between containers. One would want to burn a playlist as a CD, and k3b just supports drag and drop (afik), and juk's most prominant feature is it's playlist. if juk supports different output plugins, it could be cool to have it output to k3b's input... and DCOP could be used for k3b to tell it to start recording... probably not a simple task... KDE has... 3 or more media players? kmplayer, noatun, juk, and I know I'm missing one...Kaboodle I'd so love to see them combined like kate is embeded in kwrite and kword?? (I've heard this, believing it only superficially because they seem so different)
Just an update that kio::audiocd has migrated to a plugin arch so in theory it shouldn't be too hard (easier then before) to utilize it.
I'd like to see the option to burn a playlist to CD as well. It's a pain to have to have k3b on the screen and drag and drop songs from juk into k3b to burn an audio cd. K3b is very nice, but I also think that KDE needs a more lightweight burning interface, rather like the nautilus-burn addon to Nautilus in Gnome. It presents just a new service type thing (burn:/) in the filemanager, and I'm sure it would be embeddable or callable from other applications... Just a thought...
> Burning would be nice, but will be a lot more work Well, you can do it the easy way. You can burn files to Audio CD using K3B command line. K3B will show a simple burn dialog and all the user needs to do is press the 'burn' button. You can add this feature by adding just one toolbutton, right next to the 'go to currently playing item' button in the status bar. That will keep Juk's main interface nice and clean as it is now. Why would we need to actually integrate K3B into Juk? That would only make the interface more complex. Just calling K3B's 'Burn Audio CD' dialog seems to be a much nicer solution to me.
> Why would we need to actually integrate K3B into Juk? That would only make the interface more complex. Just calling K3B's 'Burn Audio CD' dialog seems to be a much nicer solution to me. I agree. It's also the solution of other programs, as madman, and they work very well
Here is a suggestion about how to add CD ripping to the interface of Juk without complicating things. Maybe you like it: * Add one more item to the list of 'music sources' at the left of the main window. Besides the 'collection list' and the playlists, you will also have a 'Audio CD' icon. * When clicking on this icon, the audiocd:// KIO slave should inspect the CD and fetch track tags. Of course, this should happen 100% asynchronously, allowing Juk to continue playing other stuff. Next, Juk should use this information to display the contents of the Audio CD, exactly like it would display any other track listing. * Clicking the items in the playlist that has just appeared, or pressing the 'play' button does not play the track but show a dialog that allows the user to select tracks from the current playlist (that is, the Audio CD) and copy them to harddisk. After copying has been completed, Juk could generate a new playlist that contains all newly ripped tracks and add it to the collection.
CVS commit by mpyne: Add "export to K3b" support to JuK. * You can select songs from your playlist and export them to K3b. * You can export an entire playlist to K3b as well. * The feature is accessible from the appropriate context menus. * The feature won't be visible on the menu unless K3b is in your PATH. * K3b will be started if it's not already running. * If no project is open in K3b, JuK will prompt you to select either an audio CD project or a data CD project. Otherwise the songs are added to the current project. Watchers of bug 56465 will be interested in this commit. CD Ripping hasn't been started yet, so the bug will remain open. Also, K3b isn't "integrated" into JuK, JuK simply tells K3b where to find the files, and you still use K3b as normal to burn the CD. Still, this is very useful IMHO. CCMAIL:56465@bugs.kde.org A k3bexporter.cpp 1.1 [GPL (v2+)] A k3bexporter.h 1.1 [GPL (v2+)] A playlistexporter.h 1.1 [GPL (v2+)] M +1 -0 Makefile.am 1.61 M +6 -0 playlist.cpp 1.192 M +7 -0 playlistbox.cpp 1.89 M +1 -0 playlistbox.h 1.57 --- kdemultimedia/juk/Makefile.am #1.60:1.61 @@ -20,4 +20,5 @@ juk.cpp \ jukIface.skel \ + k3bexporter.cpp \ keydialog.cpp \ main.cpp \ --- kdemultimedia/juk/playlist.cpp #1.191:1.192 @@ -48,4 +48,5 @@ #include "juk.h" #include "tag.h" +#include "k3bexporter.h" #include "painteater.h" @@ -1530,4 +1531,9 @@ void Playlist::slotShowRMBMenu(QListView m_rmbMenu->insertItem( SmallIcon("folder_new"), i18n("Create Playlist From Selected Items"), this, SLOT(slotCreateGroup())); + + K3bExporter *exporter = new K3bExporter(this); + KAction *k3bAction = exporter->action(); + if(k3bAction) + k3bAction->plug(m_rmbMenu); } --- kdemultimedia/juk/playlistbox.h #1.56:1.57 @@ -145,4 +145,5 @@ private: QValueList<ViewMode *> m_viewModes; KSelectAction *m_viewModeAction; + KAction *m_k3bAction; bool m_hasSelection; bool m_doingMultiSelect; --- kdemultimedia/juk/playlistbox.cpp #1.88:1.89 @@ -37,4 +37,5 @@ #include "actioncollection.h" #include "cache.h" +#include "k3bexporter.h" using namespace ActionCollection; @@ -67,4 +68,7 @@ PlaylistBox::PlaylistBox(QWidget *parent m_contextMenu = new KPopupMenu(this); + K3bPlaylistExporter *exporter = new K3bPlaylistExporter(this); + m_k3bAction = exporter->action(); + action("file_new")->plug(m_contextMenu); action("renamePlaylist")->plug(m_contextMenu); @@ -75,4 +79,6 @@ PlaylistBox::PlaylistBox(QWidget *parent action("file_save")->plug(m_contextMenu); action("file_save_as")->plug(m_contextMenu); + if(m_k3bAction) + m_k3bAction->plug(m_contextMenu); m_contextMenu->insertSeparator(); @@ -521,4 +527,5 @@ void PlaylistBox::slotPlaylistChanged() action("reloadPlaylist")->setEnabled(allowReload); action("duplicatePlaylist")->setEnabled(!playlists.isEmpty()); + m_k3bAction->setEnabled(!playlists.isEmpty()); bool searchList =
See also bug 66545 . I personally think that calling k3b as above is just fine.
I just want to thank everyone for working on this wish, I recently ended up with a WinXP box on my desk at work. I decided I'd give Media Player a try, and I find the nicest thing about it is the ability to toss in a cd click the rip button and rip the cd to the library. Now I have about twenty cds ripped, and I can listen to them anytime and in any order I like. It really is a great feature, and I'm sure it'll make juk that much better.
Another possibility for CD CREATION would be the burn:/ ioslave that is out now. Once they get MP3 audio support in it (only ogg right now). But that way, all Juk has to do is 'copy' the files to that ioslave and provide a 'Burn' option. I would love to see a feature where you can add mountable 'devices' to Juk (where juk will perform the mount/unmount. That way, if my MP3 player is at /mnt/muvo - I can read and copy files from within Juk. The same sort of thing could be used for the burn:/ ioslave, I think. Makes things really simple for Juk.
Just removing burning from the summary since the K3B integration is now in place.
Scott, above you mentioned that you would like KAudioCreator to be a KPart. Elsewhere in this bug database plugins are mentioned. What would be the best way for the code to intigrate with Juk? I like Dik's comment from above. With a little modification something like this: * When a CD is inserted in the playlists dialog, you will have a 'Audio CD' icon. * When clicking on this icon, the audiocd:// KIO slave should inspect the CD and fetch track tags. Of course, this should happen 100% asynchronously, allowing Juk to continue playing other stuff. Next, Juk should use this information to display the contents of the Audio CD, exactly like it would display any other playlist. * Clicking the items in the playlist that has just appeared, or pressing the 'play' button does play the track through audiocd://file.wav Dragging file(s) to the Collection List will rip the files using the default audiocd:// encoder. A little bit of work needs to be done to the audiocd ioslaves, but this could be done internally today or as a plugin/kpart.
Is this still valid in juk 4.2.4?