dangle_wtf wrote:these devices require entries to be placed in their internal database so that they can be actually played by the device. There's a little more involved than a simple 'cp'.

yes, i understand these devices should be treated differently from plain storage devices. this only means that internals of the operation of dragging playlist items to the embedded file browser should depend on a type of a current destination location. so, if the location is a hard disk directory or a usb stick, then the operation is similar to drag-and-dropping, say, from Amarok to a stand-alone file browser. if it's an optical disc, then similar to "burn to CD" action. if an ipod, then exactly the same thing as Amarok does during a transfer of tracks to the media manager.

dangle_wtf wrote:Are you aware that you can drag track *from* amarok to various other kde applications?

oh yeah, this is a good point, but i think this feature is a workaround to the problems under discussion, rather than a good solution. i suppose you'd agree that Amarok is best used when maximized on the desktop. besides, i don't like the idea of opening several applications to do things which can be easily done within just one, do you? however, i'll have to stick to this option unless Amarok becomes a music manager or i find a better substitute for Amarok. it's about usability, you know ... the name of the forum section

You should really look at Amarok 2 before continuing with this, cause that's where our development focus is. And in Amarok 2 so many things have changed that we can hardly remember how the details of 1.0 work.

E.g. in 2.0 collections are a much more versatile and powerful design as in 1.x. They can also be used for abstracting media devices.

Amarok 2 seems to be very promising. the problem's that i couldn't find a comprehensive and properly updated list of its new features. can anybody please post a link to such a page if it exists? i guess it will save the Amarok developers from wasting their time on the guys like me trying to reinvent the wheel it would also help with truly new and good ideas to be heard and implemented in Amarok 2.0. i don't want Amarok to suffer the fate of Windows Vista or KDE4 so, just a link, please?

I don't think a comprehensive list exists anywhere. Perhaps now would be a good time to start drawing one up. I can tell you this though, Amarok 2 is an altogether different beast than Amarok 1.4.

The code base has been radically redesigned/written as Mark hinted at with:

E.g. in 2.0 collections are a much more versatile and powerful design as in 1.x. They can also be used for abstracting media devices.E.g. in 2.0 collections are a much more versatile and powerful design as in 1.x. They can also be used for abstracting media devices.

However, I like your idea. Being able to move subsets of your collection(s) around would be a fantastic feature. One use case is if you have 100gb of music, but only a 30gb iPod/1gb USB stick.

I wonder how nepomuk would fit into this idea.. it is escaping me right now, but I am sure there is an application for it somewhere in here.

i'm glad to hear i'm not the only user who wants Amarok to be able to manipulate audio files by itself. as far as i understand, you are using the new version and still can't move the files around. hopefully, this is just because not everything has yet been implemented.
i've been wondering if i could make a list of the new features from what is available at amarok.kde.org, and came to the conclusion that the provided information is more about where Amarok 2 is rather than about where it goes. i bet the developers though bear in their minds the final feature set, but unfortunately i'm not a mind-reader yet
as for Nepomuk and semantic desktop in general, i think their development will pass through a relative stagnation until the industry come up with adequate standards for metadata formats. unlike other types of files, audio metadata formats are pretty much standardized and allow grouping of the underlying data by meaningful criteria. that's why we can enjoy the opportunities offered by music collections/libraries, although the potential is not fully realized, i guess.

Ramblurr wrote:I don't think a comprehensive list exists anywhere. Perhaps now would be a good time to start drawing one up. I can tell you this though, Amarok 2 is an altogether different beast than Amarok 1.4.

The code base has been radically redesigned/written as Mark hinted at with:

E.g. in 2.0 collections are a much more versatile and powerful design as in 1.x. They can also be used for abstracting media devices.E.g. in 2.0 collections are a much more versatile and powerful design as in 1.x. They can also be used for abstracting media devices.

However, I like your idea. Being able to move subsets of your collection(s) around would be a fantastic feature. One use case is if you have 100gb of music, but only a 30gb iPod/1gb USB stick.

I wonder how nepomuk would fit into this idea.. it is escaping me right now, but I am sure there is an application for it somewhere in here.

Of course the ipod / usb stick example is already covered.  As for copying to another part of the file system, I'm not against the idea, however it seems rare that you'd want to make a copy of your music to anything other than an external device.  In those cases couldn't you just drag files from your collection to Konqueror?  On a completely unrelated note it seems that just because you can place all your music in one folder doesn't mean there's any reason you should.  Amarok can organize the files for you, and I especially like having the album cover on the folder.  There's no reason you can't have your music organized on your filesystem and your amarok collection.

you seem to be self-contradicting. why do you need your music to be organized in a file hierarchy? to have the album cover on the folder? do you realize that storing your audio files this way just leads to the "rare" [just quoting, no mocking] necessity of moving the files around within the structure? with a single folder there's no reason to move them inside the folder, you bet.
so, the ability to manipulate audio files inside your file system is for the good of individuals like you who, for some reasons, love to keep the files in an hierarchy. suit yourself. i wouldn't want to deprive you of this

As Ramblurr already said  Nepomuk may be the solution here.

When Amarok is storing the metadata in nepomuk you could use the nepomuk kio slave to build virtual folders of it. For the moment it does only Support virtual folders like "All Songs from Artist X,  or all song from a given genre" but not nested folders.  But I think Sebastian (main dev of Nepomuk) is planing something like that. So you could have your Music in Amarok. But could at any time open Dolphin and say "I want all my music see as Artist/Album/ and there the songs" on an other day you could say "I want it as Genre/Artist - Album".  Or even "I want a folder with all Songs rated higher than 3". 

That is not yet possible. (some of them is already ) But I am working on it for the Amarok side,  at some work has already done on the Nepomuk site from the Nepomuk devs.

So I think that is perfect solution for your problem.  Put all your files in one folder if you like too but create virtual folders on the data in any way you could think of. 

There a screenshot about what already is possible (but stuff in playground, so not released):

http://arch.der-winti.de/kde/folderviewnepomuk.png

DanielW

thank you, Daniel, for your input. no doubt, a working semantic desktop will save us all but it's our future with an unknown deadline. besides, i chose not to return to KDE4 until the next release of Kubuntu.
the virtual, and hence easily configurable, organization of data is a nice thing to play with. Amarok already incorporates some of this stuff, but as far as i understood, results of your work will make Amarok much more efficient and flexible at doing the job. so, good luck to you
do you have a dedicated blog or something? it would be nice to talk about all this in a more proper place, as the subject has little to do with the original question of the thread.