Thursday, December 18. 2008Amarok 2 playlist searching
First of all, just to get the terminology straight. In this post, I define a filter as something that limits what you actually see in a view, and a search as something that selects items in the view without affecting other elements.
Amarok 1 style playlist filtering. Since Amarok 2.0.0 was released, one of the frequently mentioned Most Missed Features (MMF) is the Amarok 1.4.x style playlist filtering. The filtering in Amarok 1.4.x is indeed very powerful, but it also suffers from a number of usability problems and is actually sort of a weirdly placed feature as the collection is where advanced filtering is meant to take place as it will always haver more powerful mechanisms for advanced filtering. That said, we are very aware that there needs to be a simple way of locating content in large playlists and perhaps even limit the playback of tracks to a subset of what is in the playlist in a non destructive way. Inspired by the progressive searching in apps like Firefox (and indeed many of the KDE 4 applications) we decided to try this out instead. So, hidden away in a small cabin in the very dark woods, far away from streetlights and traffic, I decided to have a go at this. Amarok 2 style playlist searching.  This morning I committed the initial version of a rather advanced playlist search feature. At its very core, it is just a progressive, as you type, search. This means that as you type, the first track that match the current search term will be selected (and the playlist scrolls to it). Next and previous buttons then allows you to jump around in the tracks matching the search (These really need to get some keyboard shortcuts... Working on that one). The search edit gives immediate feedback on whether there are any matches or not, in the same way that, for instance, the KDE 4 version of Konsole does. By turning the search edit a different color and disabling the next and previous buttons. Now by itself, this is useful, but not super powerful, but this playlist search has a few additional tricks up its sleeve. It is possible to specify which fields should be matched against when typing a query. This is changed by clicking off the fields in a small drop down menu. Currently it is possible to search any combination of track name, album name, artist name, genre name, composer name or year, and I have a few more ideas for properties to search that i am going to add.  It is also possible to "lock" the track progression to only play tracks that matches the current search term. This is toggled using the same small drop down menu. It provides a very convenient way of just playing a particular artist from your all time favorites playlist or any number of similar use cases.  Currently this only works when using "standard" or "random track" playback modes however, and I am still pondering whether it actually makes sense for any of the other progressions modes, such as "random album". All the options from this drop down menu are of course stored in the config so the options are persistent across sessions. We are aware that some people will still miss the old style filtering and that this is not the same thing. We do believe however that a search makes more sense in the playlist than a filter, and that this satisfies many, although not all, of the use cases that the old filter did. Going forward, it might also be possible to add other features to the search, such as selecting all matching tracks, or exporting matches to a new playlist, if there are use cases that support these additions. One thing I am still pondering is if the filter bar should be visible at all times, making the feature very easily discoverable, or if it should only appear when the search keyboard shortcut is activated.... As mentioned, I committed this code this morning, and baring any major issues turning up, it will be appearing in Amarok 2.0.1 which should be released shortly after new year if all goes well. If you cannot wait that long, it should be appearing in the nightly builds shortly, and failing that, there is always building straight from svn!  Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Nice (and missing !) feature, thanks Nikolaj !
It works perfectly, even with random and forward backward through the playlist. Some thoughts : - There is a lot of search box in amarok right now, one for the playlist, one for the collection, one for the services (in fact nearly one for each service), and one for the file browser. Wouldn't it be possible to group them in one powerful search box, which change is behaviour depending of the last user event or the current tab configuration ? - The icon for the configuration is not clickable, maybe it should be. - This box should be hidden, and only visible when the mouse is over the playlist or when the search keyborad is activated, with a little animation when it show's up. - When the "play only match" is activated, maybe the other items in the list should be grayed, or unavailable or hidden ? That's all, thank's again for this great features !
"- The icon for the configuration is not clickable, maybe it should be."
My initial idea was to have it bring up the small menu, but that did not work quite as expected (the menu is brought up but clicking on the attached arrow). But yeah, the unclickable action needs to either go away or do something useful "- This box should be hidden, and only visible when the mouse is over the playlist or when the search keyborad is activated, with a little animation when it show's up." Still gathering input! "- This box should be hidden, and only visible when the mouse is over the playlist or when the search keyborad is activated, with a little animation when it show's up." I dont think I want to hide anything as that would effectively make it a filter (also, currently the user can easilly override this lock by manually selecting a track). Somehow marking matches, perhaps, although this could potentially become very slow if done progressively as you type...
Hi.
Nice to see this functionality back. Unfortunately for me, I used the filter in amarok 1.4 only to remove tracks from play-list, or to get a smaller list of tracks to read through in order to queue them. I guess I'll have to wait some more.
Excellent! This is comstructive feedback!
You are describing some very concrete use cases that you had for the filter. With a little tweaking, the new search should be able to cover both of these nicely. The first one should be covered if there was an easy way to select all matches or non matches (select all non matches -> remove) The second one I actually think will be covered as soon as the queuing functionality is back as it should be quite natural to search tracks and then hitting an "enqueue" shortcut for the matches that you want to add to the queue!
Hi, as kollum said, I personnaly use the "search" bar in amarok as a filter, in order to reduce the list of tracks to an album (or sometimes a combinaison of albums using the AND statement, or the OR one). I belive that it's more usefull than highlighting search results. I hope that such a powerfull bar (that makes me love amarok 1) will appear in the version 2 (or maybe something more interesting).
Thanks for your work, amarok rocks!
I use the search/filter kind of the same way: I have a playlist of all my music rated as 'good' or better (>2.5), but sometimes I don't want to listen to a certain artist that day so I use the search/filter in Amarok 1.4 to show me all the songs by that artist and I can remove them from my playlist, without having to adjust the dynamic playlist itself.
As I've said in #amarok (Kaboon) this morning, thank you.
The function seems to be working pretty much flawless so far. Sure, I could think of at least one extra option(*), but I couldn't care less at the moment. I like the way it is already. *: Do bring back an actual filter by taking out the results that don't match the criteria. Please don't get me wrong, it's alright the way it is now. But I just think this would come in handy when having a large playlist and you want to have the playlist only displaying the matched songs. That way, using a less accurate search term, it might help you find a song sooner because you don't need to jump around in the playlist by using the buttons (or hotkeys  ) but you'll see the results on the partial match.Anyway, it'd be strictly optional to me. But I realize usability is an issue. Hotkeys would be nice too, like you've stated yourself. Keep up the good work and thanks again! 
Would it be possible to add a check-box named "Hide other tracks" in the drop down menu? The action performed by this option is quite self-explanatory.
In this way you could have both searching and filtering functionalities in a simple (and IMHO quite intuitive) way. I don't know if there are some backend problems related to hiding tracks, though.
I think the filter checkbox is a very good idea. No matter how much developers think that using a filter in the playlist is improper usage of the playlist, some people like to be able to do it. It fits the way they like to use the software. Adding this option seems like a fairly benign change to me and would satisfy a large number of people. I know that the developers want to avoid a filter at any cost, but considering how many people seem to want it I think making it available, but not the default, is worthwhile. There may be other ways to do what they want to do, but these are often more complicated and require more work to do the same thing. The big disadvantage of your new search technique relative to the filter is this: the songs that you are searching for are not placed close together. The search could find songs scattered all over the playlist. There is no way to look at the playlist and see all of the songs you are looking for right next to each other. You could clear the playlist, filter the collection browser, and then move the songs to a new playlist, but this requires far more work and many more button presses to accomplish the same task, a task that amarok 1.4 made extremely simple.
For me, I don't have that many songs so I really prefer to keep them all in the playlist most of the time, use the filter to reduce it to a certain set of songs that fit my mood, selecting one from that set, and then letting the randomizer move through all of my songs (I usually clear the filter right away). Making new playlists for the way I do things is a big hassle, and this search doesn't cut it because I want to be able to see the entire selection of songs right next to each other so I can pick one. I don't necessarily know what specific song I want, I just know it fits a certain criteria. I want to be able to see them all as a group, and not have to jump around through the playlist looking at individual songs. And once I select the song, I don't want the playlist limited to just that selection, I immediately clear the filter field so it can randomly jump through all of my songs. Making a playlist with just the songs I am looking for won't allow that. Of course I could clear the playlist, use the filter to narrow the collection browser down to a single song, drop that song in the playlist, start it, than drop all of the rest of the songs, but that is a very complicated and time-consuming solution to what used to be a very quick and simply problem (type into the filter, double click, clear filter). You could have an option to clear all the non-selected tracks, but then I would just have to add them again in a moment which is a hassle. Filtering really is the most efficient way to use Amarok the way I like to use it. I guess I could completely change the way I work with my music, which appear to be what you are suggesting when you say you don't intend the playlist to be the main way of interacting with our music, but why make people do that when the solution (a single checkbox) is available and won't bother anyone who doesn't want to use it? You may not think people should be using the playlist to interact with their music, but it seems a lot of people like to use it that way. With the description of how the playlist will work, I really prefer to work with it rather than the4 collection browser. The one and only thing preventing me from doing that is a lack of a filter. This search simply does not do what I need it to do. I know you could say that you don't want too many checkboxes, but you are suggesting adding a bunch of other functions (like "clear selected") just to avoid adding a single other function (the filter). I have a specific use-case that I think can only be satisfied with filtering. Imagine I want to find all the albums that have a particular word in it (for instance a movie title). But due to the album names and artists being different there is no easy way to put them next to each other in a playlist. Movie soundtracks can have upwards of twenty different tracks, more if there is more than one CD in the soundtrack, meaning using the arrow buttons would require as many button presses to move between different albums. You could make a new playlist, but that is requiring a lot of work just to see the albums. You could come up with a round-about way to select them using playlists or queues or something, but just allowing you to filter it would be a simple and very effective solution. You could make it so the arrows jump between albums instead of tracks but this would make the search system much more confusing (how will people know when the search will move between albums and when it will move between tracks), and it still doesn't allow you to see the albums next to each other without clear all the rest of the playlist (something someone may not want to do). In the end you are intentionally eliminating a feature from 1.4 in order to make it more difficult for people to use the program the way they want to use it and the way they feel comfortable using it in order to force them to use it the way you think they should be using it even if that makes it much more difficult for them. I can understand the problems with the playlist right now, it is a WIP. I can understand other things that are being brought back over time, or things that are not going to be done (other SQL backends) because it is too difficult. But I do not understand forcing people to completely change their workflow by intentionally leaving out a feature that was extensively used in 1.4 simply because you think they should be using the program differently than they like to use it. I know this is your program, but other people can have other ideas about the best way to use it. I know you can't be expected to completely rework the program to suit every whim, but this is a relatively tiny change in the layout of the UI that will lead to huge functionality improvement for people using the program in a certain way, a way you may not like but they do.
This new play list is a piece of crap. Seriously. I mean it.
Ok, now it possible to find a track. What a great enhancement! But all modern media players can do much much more!!! How about sorting tracks by, lets say, rating. Oh wait, I can't see a rating for individual item in play list. Why the hell all other players allow users such functionality. Perhaps their developers miss something. Or maybe you miss something ... Great number of people wrote you many times. Move play list next to the collection browser. It is soooo inconvenient to drag traks (many people find natural dragging their tracks from collection to play list) over that stupid container for different widgets at the center of Amarok. I really don't want to offend anyone. I don't have anything against Amarok developers. But new play list and layout of different elements of player (I still mean play list and container for widgets) make Amarok 2 real piece of crap. I'm sorry. P.S. have you tried to look at Songbird?
"This new play list is a piece of crap. Seriously. I mean it."
"I really don't want to offend anyone." Absolutely astonishing.
Not all of our original plans for the new playlist made it into 2.0.0. Mainly because the playlists code base took a while longer to reach maturity than originally thought. That does not, however, mean that these plans have been scrapped. I would argue that the new playlist will eventually become much more configurable than the old one.
Have a look at this blog entry which describes the ideas with nice hand drawn sketches: http://amarok.kde.org/blog/archives/810-The-Old-style-Playlist-Is-Dead,-Long-Live-The-Old-style-Playlist.html
For me, Amarok 2 is not an option as long as the fantastic media device support of 1.4 isn't implemented. You can configure how data is copied to your media player, which is a fantastic feature I really need. But getting back to the playlist, I would sort my playlist of 'good' and better music randomly (CTRL-H) or by rating for example, and queue a whole bunch for my media player and transfer it (with the correct paths). Which was a USB device, btw, and it doesn't do MTP, like Amarok 2 wants.
 So, not only the filter is handy (quickly remove something you're not in the mood for), but the sorting 'on the spot' in 1.4 was incredibly useful as well, to adjust the playlist just the way you feel like at that very moment. So unless all this functionality comes back (especially the great media device possibilities of 1.4), I need to hold off of Amarok 2.
Okay. So you say searching is a better fit than filtering. What I don't get is why. Isn't just filtering it infinitely simpler and more discoverable than having to add special buttons and menus -- next match, previous match, play only matches, select all matches, who knows what else is next -- to separately facilitate every single use case which filtering satisfies inherently by its design? I just don't get the reasoning here. Why is this better?
Because of usability issues. Do you have any idea how many reports we got, like this: "Fuck it, my playlist is empty!!!!11"
Guess what, the user had some word in the filter and forgot about it. Happened all the time.
Doesn't stop kmail from having the filter (haven't tried kmail in KDE 4.2 yet, just 4.1.3, don't know if it has the same filter as 'old' kmail). Perhaps if it would be more prominent (lightly colored or something else, I'm not an interface guy
), people would notice it more quickly. But I use it all the time, in Amarok 1.4 and kmail and it's a tremendously handy, though small, feature.Just hope Amarok 2's search/filter thingy will give us the same power, even if it is in a different manner.
But we do have filtering and very powerful filters at that, in the collections!
Yes, but like I said in an earlier reply, I'm talking about 'on the fly' filtering, like when you have your playlist ready, but just want to remove 1 or 2 artists from it, for example, but do not want to adjust your bias stuff on the left. I do that a lot. Like with my media player (here I go again): I have my playlist, but don't feel like listening to artist A today, or live recordings or something, so I filter on it from my playlist and remove those songs. Clear the filter and send the playlist to the media player. Works really fast and really well that way.
Sounds like I'm the only one using it that way. Oh, I'm innovative!
hmmm, i heard some people dont know how to install software on linux, maybe we should get rid of that feature too?
Without commenting on the relative merits of "filtering" vs "searching", that's really a very poor argument. Especially when something as simple as a box text indicating there's no match for the entered filter would have done the trick (an empty playlist would have been a perfect place to put that...).
Anyway... please, don't dumb down the interface just to appease users who haven't used the interface for more than 5 minutes.
"Especially when something as simple as a box text indicating there's no match for the entered filter would have done the trick"
This seems like a sensible suggestion to me
I will have a go, but I think others are better equipped to describe this stuff from a design/usability standpoint.
First of all, you have very powerful filtering in the collection browser. Admittedly, some of the filter options that were available in 1.4.x has not made it into 2.0.0, but these will appear over time. So having filtering in the playlist as well is really providing the same functionality in 2 places. Also, and I think this is one of the main reasons some people dislike the direction of Amarok 2, Amarok was never intended to be a "playlist based" player in the sense that the playlist is where you interact with your music collection at large. For finding specific content (using filtering), editing tags and so on, there is the collection browser. There are many other players that rely on the playlist for all of these things, but we believe that by using the collections instead we can provide something more powerful. The playlist in Amarok 2 (and actually also in Amarok 1, as the app would slow to a crawl if you added too many tracks, something that is fortunately solved in Amarok 2) is meant as a much more transient thing. Of course you can save and restore playlist, move stuff around and all that, but its not meant to be "permanent" in the sense that the collections are. This is in contrast to the usage pattern of the versions of Winamp I was using many years ago, Xmms and many other apps. Which is why, I am guessing, that many users take this usage pattern with them to Amarok. These are sort of broad scope design ideas that people can agree or disagree with. There are also a few very down to earth reasons. One of the most common support requests we get with Amarok 1.4.x is that people are adding stuff to their playlists and nothing happens. This is of course because they have an active filter in the playlist that does not match an, or only some of the tracks they are trying to add. While this is easily explained to the users, it does highlight what I think is a big usability issue. It is to my mind incredibly counter intuitive that you can add stuff to the playlist and have it not show up. Especially since the playlist is something that in many cases will change quite frequently. With dynamic playlists, this gets even more "interesting". As for filtering being more discoverable, I think people are by now very used to progressive searching from web browsers. For finding a specific track I would say it is slightly superior to filtering as, if you don't know the exact name of the tracks, you will still have to manually look through a number of results where with searching you can use the next shortcut (once I get that set up) to scan the returned results.
(By "discoverable" I wasn't referring to the searching vs. filtering itself, rather things like "how do I find the next matching track" or "how do I play only these tracks" or whatever, because with filtering they happen automatically without having to discover them.)
But yeah, I guess if you were getting lots of "I filtered the playlist and forgot about it! HELP ME!", it's a defensible decision. I didn't know that this was the original reason behind the switch and you didn't mention it, only a vague reference to "usability" (which this seemed to be going exactly counter to), so it was pretty baffling at first. Thanks for clearing it up.
Well, there are all sorts of reasons why this is happening, and while replacing filtering with sorting is one way to fix the problem, it's kind of like using a chainsaw to pull weeds.
The playlist search in 1.4 recieved all key presses from everywhere in amarok. This led to all sorts of filters being applied because users hit the wrong key by mistake, and did not have any visual feedback that there was a filter applied. Now, presented with this problem, there were a few ways to take a solution. 1) Don't make the playlist search filter the focusproxy for the entire application (pretty simple.. though if I recall, this was originally done because it "increased usability".. isn't it funny how the "u" word is used to justify any controversial decision? 2) Provide visual feedback when a filter is applied. This is done with the new search, so there's no real arguement that it couldn't be done, and therefore would be a perfectly valid solution. or.. 3) Replace the filter with a search, but then pile on as many of the filtering functions as we can onto the search. Now we have something in between, and somehow... even though itunes, windows media player, and every media player i've ever used use a filter, we pull the usability word out of our ass and, without any sort of testing or real data to back up the decision, claim its for the better. I call bullshit.
I have to agree with illissius.
Yes, searching can be hammered into having all the features of filtering, but why would you when you can just filter? The disadvantages of searching as I see them: - It's inconsistent. A line edit above/below a list of items is a filter bar in every single app I can think of. - You can never get an overview of your results. If you have 1000 songs, you have no concept of how many match a given query. With a filter bar, you immediately see from the new list what matches. - You can't quickly try out a few queries to find what you're looking for. With a filter bar you can type a few variations of a query and quickly glance at the results to see if that's what you wanted. With a search bar you have to look through every result with lots of clicking. - More UI complexity. A search bar needs at least two extra buttons (next/prev). And if you want to have equivalent features to a filter bar you need even more ("Remove others" as someone else mentioned). - The behaviour of "Play only matches" will be completely unintuitive. The song progression will skip around the list with no clue as to what song it will go to next. With a filter bar you have a simple progression of songs, you can see exactly what is coming up, and what just played. That's all I can think of off the top of my head. Good work on Amarok otherwise... I don't use it (I'm picky and wrote my own music player) but when I checked out the final it was very nicely polished. You've done a better job using plasma in Amarok than in the plasma desktop itself.
"Other people are doing it" is not a good reason. However, I do see that those other reasons are valid.
I agree with the point some have made about redundancy. Perhaps copy the collection filter but have the option to turn it to search mode? Either search or filter, I can see this having potential with scripts.
Oh please, please make it fuzzy!
http://amarok.kde.org/wiki/FuzzyFilter Any chance we will see this? Fuzzy search kicks ass and as an ex Yammi usere, I totally miss it...
I'd really love to see all the features of the amarok 1.4 playlist back in the new playlist, especially filtering. The power of the old playlist is what drew both myself, my friends and family into using Amarok. We all migrated over from XMMS (wow haven't heard any news from that project in a while!). If we can somehow bring it back as an option it would greatly be appreciated. Right now I'm sticking with Amarok 1.4 over 2.0 because of the power of the playlist. I really do like a lot of the new features in Amarok 2 though, so its quite frustrating for me. At the end of the day though, the playlist features are more important to me.
Hopefully these features can be implemented in Amarok 2. Zubin Parihar
Ok, filter vs search, how 80's
anyway, after reading the developer and the posters i can see value in both approaches, and like buda would have said, go for the middle road Yes, the dev as a point, search is more powerfull, etc etc.. and yes, posters and me included also have a point, filter is infinitely better for quick sorting, and the like, so why no both? Leave search for the colection for ppl that want more powerful and permanent playlists and leave the filter for quick/more fuzzy organizations. Enhance the filter so the clueless dont think the playlist is empty and pronto, best og both worlds, me happy, everyone else happy too just my 2 cents
A User's Perspective
This is a sad situation. We have people who post paragraphs of explanations that basically amount to explaining to the devs why it's better to not poke yourself in the eye with a sharp stick. It should be blindingly obvious. Why does it require an explanation? Why do these brilliant programmers not understand these simple things? 1. Amarok 2 has been pushed out lacking basic features that Amarok 1.4 has. Priority was given to fanciness over practicality. Instead of aiming for feature parity with 1.4, that was put off for later. New features should come after feature parity. Practical, preexisting usability is more important than nifty new stuff. 2. The UI was made less useful and less efficient. I shudder at the large waste of space at the top of the screen that the controls and progress bar are. At least 1.4 uses the blank space for visualizations, has a decent sized volume control, and doesn't have squished, overlapping control buttons. The new playlist has fancy grouping but lacks practical functionality from 1.4 that could have been implemented already, considering all the effort that's been put into Amarok 2 so far. And this context browser takes up the majority of the screen. Dudes, I don't need to look at artist data for every time a song changes, or lyrics, etc. It's a waste of bandwidth and web server time too. And it's a waste of screen space, especially on laptops! It boils down to this: The user experience is a large step backwards. What kind of reaction should be expected from the users? Yeah, the new underlying structures are awesome. So how about using them to recreate Amarok 1.4's usefulness in a more powerful way? "Nah, we're gonna do something completely different than what made Amarok 1.4 so useful, successful, and popular. And don't complain too much; we're doing this for fun; we're doing this for ourselves; we're doing what we want to do." That is the impression I get of Amarok 2's development so far. I really don't understand why the devs have made some of the decisions they have. Are these the same guys that made Amarok 1.4? I hope that Amarok 2 soon becomes all that 1.4 was, and more. But until it does, you can pry Amarok 1.4 out of my cold, dead hands.
"Why do these brilliant programmers not understand these simple things?"
Perhaps its not an issue of understanding but one of perspective. You can be very sure that we all care very much about the success of Amarok 2. To some extend, the success of Amarok 1 is our biggest problem, as no matter what we change, the people who are deeply in love with A1 will not like it. With leads me nicely on to your point 1. Yes, Amarok 2 lacks some features that Amarok 1 has. Many of these will reappear in one form or another, and some will not. The reason for this is quite simply that Amarok 2 was never intended to be just a KDE4 port of Amarok 1 (!!). Every developer felt that there were major design issues with Amarok 1 keeping us from doing some of the cool stuff that keeps us motivated to actually hack on Amarok. In this sense, Amarok 2 is almost a new program. We try to take many of the good things from Amarok 1 with us, but absolute feature parity has never been a goal in itself. The goal currently is something like, "taking what we have learned from Amarok 1, how can we make the best music player possible" With regards to your point 2. No, the ui was not "made less useful and less efficient". You got it backwards. Amarok 2 has a new ui that has some way (a long way?) to go before it becomes as clean, efficient and usable as the very mature GUI in 1.4.10. "The user experience is a large step backwards. What kind of reaction should be expected from the users" We have been very clear in blogs release announcements and so on that Amarok 2 would be a step back for some users depending heavily on specific Amarok 1 features. The big discussion then becomes whether it is right for many of the major distros to abandon the stable and mature Amarok 1.4.x series for Amarok 2.0.0 already, but that is really something beyond our control. "we're doing this for fun; we're doing this for ourselves; we're doing what we want to do." Though you seem to put it on edge a bit, at the core this is true. The most important thing in any project that all or most people work on out of love in their free time is motivation. I touched on this already. No one was motivated to do a straight KDE4 version of Amarok 1, so it did not happen. Yes, there was (and is) user demand for it, but not enough of these users decided to contribute to actually make it happen. Amarok is not driven by committee but rather on what ideas and skills each developer brings to the table. The upside of this is that with Amarok 2, we have more active developers (I think) than ever before, as being able to bring your own ideas to bear on a framework that allows them the become reality is extremely motivating. And in the long run, this is to the benefit of all. "Are these the same guys that made Amarok 1.4" Yes. Or rather, there is a constant flow of people in and out of a project like Amarok, but many of the developers who made 1.4.x are still here. "you can pry Amarok 1.4 out of my cold, dead hands. " As far as I can tell, no one is trying to. This is not the proprietary world where we can "end of life" a product and stop issuing new license keys. Indeed, if anyone steps up to maintain it, Amarok 1.4.x might still have a long life ahead of it.
What about something like this:
http://img.photobucket.com/albums/v331/sabaal/amarok2-filter-mockup.png
Actually I have changed a few things since this blog post.
The "Play only matches" checkbox now read "Show only matches" and actually enables old style filtering (and hides the next and previous buttons since they don't make much sense in this mode...) This option is now of by default though so searching is the default.
Thanks. It's amazing what 5 minutes in Inkscape can save you from typing. "Some things are better expressed with a crayon than a quill."
I like the new filter option, but I still think it would be nice to have my cake and eat it too. However, I've got a nasty habit of overlooking glaring flaws in many of my ideas, so I'll let you smarty-shorts pro types do your thing. 
To give you use cases for my typical use: I know my music pretty well, and really don't like listening to things in the same way / same order each time. So, I basically never used saved playlists. What I did do was one of two things:
1) Go through my playlist manually, adding individual songs that I was in the mood to listen to, and then usually randomizing the playlist and maybe rearranging things a bit if, say, two clashing songs were next to each other, or there was one song I wanted to hear sooner. 2) If I wanted some music quickly, I'd add an entire genre of my music to the playlist. Then, I would sort the playlist by rating and eliminate the ones that I rated lowest (where "lowest" would vary between 3 and 4.5 stars, depending on how long I wanted to listen for), and then randomize that playlist and hit play. SO, what I really miss in Amarok 2.0 (as it stands right now) are the following: a) The ability to sort my playlist by rating, so I can eliminate the poorly-rated ones. (perhaps an alternative would be to allow a search by rating, and then 'select all' to delete, but that seems like a bulky way to do it. On a separate note, it was also nice to be able to play straight down a playlist ordered by rating, so that I could re-calibrate the ratings on my songs.) b) The ability to randomize /the playlist/. I know there's the random play mode right now, but I want to be able to see what's going to be played next, and perhaps change it. Random play mode doesn't let me do that. Thank you, and I hope this also helps you in development with a couple use cases.
Well, I can see how searching would be very helpful. However, with queuing not integrated yet, I find it very difficult to use. Typically when I would use the filter it would be to select a specific song, or songs, and queue them. I would then clear the filter. If that was present, I could just use the collection part to do that. However, right now that's not possible. So filtering is best in my opinion. At least, for now. One other thing that might work is having a section in the context browser that shows all the search matches.
Ohhhhhh! For sweet! I'll go get the Neon Nightly Builds for Kubuntu.
|
Amarok LinksCalendarQuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
