My last patch to add merge / remove duplicate was fairly easy, since I could piggyback the hard part by calling existing functions. For example, all I had to do was create a vector<PlaylistItem*>* pointing to the duplicates, then call an existing remove function. Using a playlist to hold the search results cannot by implemented so seamlessly. The "New Playlist" operation is strongly tied to creating a brand new browser window, with an *empty* list and the new window creates a brand new PlaylistManager. The operation returns void, so there is no way to then add anything to the new playlist. I need access to the PlaylistManager, so I can AddItems. Since the obvious way fails, here are some less obvious approaches: A) Name the playlist, save it to disk, and then create a new window with the filename which will open and read the results. If the user selects an existing filename, figure out how to open the list & append or replace with the results. B) Simply append the search results to the active playlist. (Makes the most sense if you are doing a search on the catalog selection). C) Make a new factory for browser windows which is passed a playlistmanger holding the search results. This is a promising, if more complex, idea. D) Find a way to replace the current playlist in the window with a new playlist. ( Anyone know an existing example of this ? ) Additionally, the PlaylistManager understand three categories of lists, the currentlist being played, an external list which is represented by a url, and a portable mp3 player's playlist (which is not a url, there is no rio:// ). Notably, there is no category for an "in memory list" that has no external name (even the current list has a filename under ~/.freeamp). Perhaps in extending Freeamp to allow searches, it would be wise to add another category to cleanly represent the difference between a "view" of the catalog returned by a search and a file associated list. One conclusion might be that the existing class architecture is simply ill suited to playlists generated by the program. In which case option (A) is the best path, and all search results are returned as an already saved playlist. ------------------------- As for the search itself, the GetTreeSelection which the right click menu items use is perfect. It return a list of items which can be filtered by a search routine written as a static playlistmanager method (or something). The problem is presenting the results to the user. -- Chris _______________________________________________ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
