Hi, I would like to start a discussion about the role of the browser and some improvements I hope would become evident once two different but related aspects of the browser are distinguished.
1. The browser is announced as a cache metadata explorer. In this sense it's quite accomplished in its current form. The playlist abstraction has little to do here. 2. The browser is also an alternative and convenient means to populate playlists. Probably this is how most users look at it. In this function, I argue it currently feels like an afterthought and propose relatively simple improvements. Why I say so? Because: 2.i. To populate the browser you need to populate a "mega" playlist first, since there is no direct way to populate the cache, the cache was thought as a way to *cache* contents in playlists and not as a source for the browser. This not only feels clunky but it's inefficient. Unfortunately, if you intend to use the browser to navigate contents and populate playlists, you need to create (and refresh) intermediate playlists first in order to keep the cache in sync with your library. 2.ii.The way the browser adds tracks to playlists is quite inconsistent with the way tracks are added from other sources. For example, both the face and the format are computed in a different manner; in the default configuration, I quickly get a mix of differently nested, colored, formatted, numbered tracks. One could say: it's ok, if you like "browser mode" don't mix it with "vanilla mode". But sadly when you save a playlist all this "browser augmented" stuff is lost and you restore plain old playlists; then you add something from the browser and you get the inconsistent mix again. I believe 2.i is rather easy to fix: make define-emms-source to define a third function ems-cache-xxx, besides the ems-add-xxx and ems-play-xxx variants. This function will just populate the cache. Regarding 2.ii things are not that clear-cut. One way is for the end user to set emms-browser-playlist-info-title-format so that it mimics emms-track-description-function. But I really don't see the point of allowing the playlist contain a lot of extra information it's going to be lost in the next session anyway, so why the user would undertake the work of making things look similar when the differences are transient? I mean, why not simply adding bare tracks formatted the old way with emms-track-description-function? Adding hierarchies, images, etc. is nice for the occasional r/unixporn screenshot but it's worthless if it's going to be lost. Maybe there is a real use case here (users that like to recreate nice looking playlists every time) that I'm quite harshly disregarding, if that's the case I apologize. To sum up, I propose one of: 2.ii.a. Add plain old tracks to the playlist, avoid any browser related enrichment that is going to be lost anyway. Drop emms-browser-playlist-xxx faces and formats from the codebase. 2.ii.b. Add enriched tracks and hierarchies to the playlist but allow native playlists to save and restore them. Honestly, this seems quite hard and worthless to me. Besides there is the aforementioned: 2.ii.c. Do nothing. If you don't like inconsistent playlists, set emms-browser-playlist-info-title-format to mimic emms-track-description-function. This imposes unnecessary customization burden on the end user. I favor 2.ii.a because of its simplicity and consistency with the rest of emms. I would like to know your opinion. I wouldn't mind providing patches in case you like the proposals. Best regards -- Carlos
_______________________________________________ Emms-help mailing list [email protected] https://lists.gnu.org/mailman/listinfo/emms-help
