Dieter Deyke <[EMAIL PROTECTED]> writes: > Another way to solve the mplayer -playlist problem would > be to resolve playlists coming from urls in Bongo, and > just pass song references to the backend.
It would be relatively straightforward to do this for `i l', at least: If given an URL, download it and look inside. > If we would add some more of the do-what-i-mean logic, > then 'i f', 'i d', 'i t', and 'i l' could all become the > same, handled by some smarter insert function. I do think it would be good to increase dwimminess of the insert commands. Currently, `i f' is a bit dwimmy in that it can glob and insert directory trees, which makes it much more useful than the other insert commands. There was a short thread about this once. I suggested that we make `i' into a sort of general insert command, and put special insert commands on an `I' submap. The `i' command could handle files, directory trees, URIs and playlists. It probably could not handle CDs in a convenient way (having to type `cdda://' to insert a CD isn't user-friendly at all). The same goes for action tracks (though something like `x-bongo-action:(bongo-stop)' could work, it again would not be user-friendly). So we would have `i', `I C' and `I a'. What about `i d'? People do use it (case in point: Daniel). We could either just move it to `I d', or we could do something more intelligent and dwimmy. What if when you selected to insert a directory containing both playable files and subdirectories, you were asked, ``Recursively insert all subdirectories of `/foo/bar'?''. We could have an `always'/`ask'/`never' customization option for this. Actually, as I recall, in the old thread, I suggested `i' and `I', with the latter command prompting for a type. Daniel thought the five key presses in `I cd RET' was a little over the top, but since `I C' only requires three key presses, he might like this approach better. The reason I like unifying `i f', `i t', `i u' and `i l' is the improved usability. Just `i' is easier to understand, easier to remember and easier to type. Having to decide ahead of time what _type_ of thing you want to insert is a bit counter-intuitive. It is is more natural to issue the insert command, browse around your filesystem, and only then decide what, exactly, you want to insert. Imagine if The GIMP had `Open PNG Image', `Open JPEG Image', `Open XPM Image', `Open TIFF Image', and so on. :-) Inserting a CD or an action is different. In these cases you really do have to decide ahead of time, because you are not going to find those things in your filesystem. You won't find URIs in your filesystem, either, of course. In this case, it is merely a matter of convenience that inserting a URI wouldn't require a special command. The code in `i u' that looks for a URI on the clipboard can be carried over to `i' and extended to look for any absolute file name _or_ URI. > I am not good at emacs lisp, but let me show you some > pseudo code of what I mean: > > def bongo-insert-item(uri-or-filename, OPTIONAL title): > if not title: > title = remove-extension(basename(uri-or-filename)) > if is-a-playlist(uri-or-filename): > insert-section-header-line(title) There is no way to get Bongo to put a given set of tracks into their own section unless those tracks actually share the value of the (by default) `artist' field. > pl = fetch-playlist(uri-or-filename) I just realized that it would be really convenient if there were some way to get Bongo to download the content of a URL and then play the content locally. I mean, for arbitrary content types --- not just playlists. I often do that manually to avoid buffer-fill delays, and because I often want to play remote files multiple times. > for each item in pl: > bongo-insert-item(item) > elif is-a-directory(uri-or-filename): > insert-section-header-line(title) > d = list-directory(uri-or-filename) > for each item in d: > bongo-insert-item(item) > else: > insert-into-current-section(uri-or-filename, title) > > The idea here is that remote playlists are handled like > local ones. They get expanded by Bongo. That makes sense. > A local playlist can be determined by looking at the > extension (.m3u, .pls, .asx). A remote playlist could be > determined by extension or by mime-type. If we were to use the latter approach, we would have to perform an HTTP HEAD request for every inserted URL. I guess that's okay (if the user can disable it), because I don't expect anyone to insert massive collections of URLs, and if the HTTP HEAD request is slow, then playing the URL will probably be equally slow --- which is a bigger problem. What else can we do with the HTTP headers? Maybe backend selection based on the MIME type? > To read remote playlist Bongo would either need some > networking code, or it could make use of wget. We can use the `url' library. It is part of GNU Emacs 21 and GNU Emacs 22. > What do you think about this approach? To be sure, there are many interesting possibilities. :-) -- Daniel Brockman <[EMAIL PROTECTED]> _______________________________________________ bongo-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bongo-devel
