bongo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bongo-devel] Insert commands (was: URI mplayer question)


From: Daniel Brockman
Subject: [bongo-devel] Insert commands (was: URI mplayer question)
Date: Thu, 22 Feb 2007 00:48:02 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux)

Dieter Deyke <address@hidden> 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 <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]