[PATCH] multiple music path update

[kdf]

I found a few buglets of my own, so I thought i'd post an update of the patch.

Some things fixed now:

cleaned up the PWD list at the top
tested with OSX (; delimiting is a problem for mounted shares)

-kdf

[Robert Moser]

kdf wrote:
> I found a few buglets of my own, so I thought i'd post an update of the patch.
>
> Some things fixed now:
>
> cleaned up the PWD list at the top
> tested with OSX (; delimiting is a problem for mounted shares)
>
> -kdf

Why not make it into an array pref?

[kdf]

Quoting Robert Moser <rlmoser (AT) comcast (DOT) net>:

> kdf wrote:
> > I found a few buglets of my own, so I thought i'd post an update of the
> patch.
> >
> > Some things fixed now:
> >
> > cleaned up the PWD list at the top
> > tested with OSX (; delimiting is a problem for mounted shares)
> >
> > -kdf
>
> Why not make it into an array pref?

It might have to go that way. The original suggestion was a simple comma or
semicolon separated list. I expected this would be easy to make seemless for
those who still only use a single path. I haven't yet found the nicest way to
skip down automatically with just one path. It also avoids the need to read in
the old single pref, and convert it to an array pref. The same old singleton
works.

However, going back to my first sentence, a comma-sep list may not cut
it, so an array pref could be folded in and I'll have to work up a way to
handle backward compatibility. After looking over what's out there, not many
plugins use the pref anyway. In fact, I only found one, so it is probably not
a huge thing to change after all.

-kdf

[dean]

A comma separated list is a fine way for the user to express the
multiple paths, but so is a pref page like this:

Music folder: [___________________] (Change)
(Add another folder)

Either way, the internal representation could be an array pref or a
string pref.

With the new DB, you could keep the folder list in the DB as a virtual
playlist (with a special name, like __audiodir or something) that
contains one or more paths to the root directories. So, if the user
changes the audiodir, the preference may still be a comma delimited
string, but the change also triggers a modification to the DB so that
it can be looked up with that mechanism.

This way, we have an interface for modifying the preference (using the
prefs file) that independent of looking for the music there (using the
db).


On Jan 31, 2005, at 10:04 AM, kdf wrote:

> Quoting Robert Moser <rlmoser (AT) comcast (DOT) net>:
>
>> kdf wrote:
>>> I found a few buglets of my own, so I thought i'd post an update of
>>> the
>> patch.
>>>
>>> Some things fixed now:
>>>
>>> cleaned up the PWD list at the top
>>> tested with OSX (; delimiting is a problem for mounted shares)
>>>
>>> -kdf
>>
>> Why not make it into an array pref?
>
> It might have to go that way. The original suggestion was a simple
> comma or
> semicolon separated list. I expected this would be easy to make
> seemless for
> those who still only use a single path. I haven't yet found the nicest
> way to
> skip down automatically with just one path. It also avoids the need
> to read in
> the old single pref, and convert it to an array pref. The same old
> singleton
> works.
>
> However, going back to my first sentence, a comma-sep list may not cut
> it, so an array pref could be folded in and I'll have to work up a way
> to
> handle backward compatibility. After looking over what's out there,
> not many
> plugins use the pref anyway. In fact, I only found one, so it is
> probably not
> a huge thing to change after all.
>
> -kdf
>

[kdf]

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> A comma separated list is a fine way for the user to express the
> multiple paths, but so is a pref page like this:
>
> Music folder: [___________________] (Change)
> (Add another folder)
>
> Either way, the internal representation could be an array pref or a
> string pref.

Frankly, if we want an array UI, I'd definitely go with an array pref. The
handlers are already there.

>
> With the new DB, you could keep the folder list in the DB as a virtual
> playlist (with a special name, like __audiodir or something) that
> contains one or more paths to the root directories. So, if the user
> changes the audiodir, the preference may still be a comma delimited
> string, but the change also triggers a modification to the DB so that
> it can be looked up with that mechanism.

That's what I thought it would be too, until I looked at the code.

The problem is that the player UI and the web use rather different methods for
descending and ascending (descendVirtual vs addToList). virtualToAbsolute is
also painful for mutilple virtual dirs. Plus, the DB doesn't completely store
the folder tree. Ideally both would be ripped up and started again with the
array pref in mind.

With what is there now, its easy enough to move to an array pref. Scanning is
still very easy. Navigation is a nightmare. I think in this patch, i've
effectely disabled virtualToAbsolute and it was stil complicated trying to
handle two virtual levels vs one. I'm still not sure how to implement the
combination such that a single path will automatically open, instead of listing
the single path. I've been struggling with that one for some time. The patch
was about all I could muster with the time I have to spare. I'd appreciate any
tips, especially for virtualToAbsolute. If I can get past that hurdle, the rest
should be easier. I might even be able to combine the player and browser
navigation.

-kdf