Feature request and discussion: Flash/Ajax/... for UI

[oreillymj]

BTW Flashy skins are all well and good, but something that would make Slimserver more useful would be automatic detection of new music and additional to the library.

I'm wondering if this is something that has been difficult to implement due to Slim supporting multiple OS's.
There are Windows API's for "watching" directories for changes. I'm sure that same also exists for Mac & Linux, but perhaps the implementation is different enough to make programming this feature 3 distinct jobs.

If Slimserver detected new music, optionally Replaygained it, and added it to the library automatically it would cut down the learning curve for new users considerably.

Slimserver could then install something like CDex for beginners and set the default rip path to match the users selected music directory.

Then adding to Slimserver becomes a simple job of imserting a Cd, fire up CdEx and click rip.

[Simon Still]

On 7/10/06, oreillymj <
oreillymj.2ar25z1152568801 (AT) no-m...limdevices.com> wrote:
>
>
> How about setting http://<slimserverip>:9000/handheld as the homepage on
> your pda?
> Or just add to the browsers bookmarks.
>
> Indeed, my Nokia 770 has the icon bookmark on the desktop as a Squeezebox
image that launches the handheld skin (i'm running 6.3). That skin does
have some issues -- particularly with changing the player it's controlling.


I'm not a big fan of skins. Obviously Slim needs a few aimed at different
devices but frankly the unmaintained 'not fishbone/default/exbrowse' should
be plug ins rather than in the default distribution.

[Michaelwagner]

I'm sure even Michael (Wagner) has used some
Flash he didn't dislike. And he didn't notice, because it was _good_ design and good Flash usage. Good design and usage of a tool is when you don't notice it.

That's probably a fair comment.

I don't always check how something is implemented. If it's clean, appropriate, not confusing, just works and not full of whiz-bangs, I pass over it happily and go on with the work at hand.

[Michaelwagner]

(also, having two little daughters doesn't speed development much either ).

Summer's coming. Give them a summer job coding :-)

[Michaelwagner]

Hmm...a lot of interesting thoughts here.

I think we are overlooking a lot of important Slim flexibility.

The web interface attempts to be all things to all people on all platforms (combinations of O/S and browser).

As such, I think it ends up being jack of all trades, master of none.

A tremendous amount of work has gone into the CLI since Slimserver 5 days, and it now seems to be quite a viable interface. There are bulk data extraction options, event driven options with the listeners, there is current status stuff that is fast.

That gives people who want a different interface the ability to write their own. Or use someone elses.

Moose is one. For all that people like or don't like .net, the version I downloaded some time ago was quite serviceable and I gather it's improved since.

I considered writing one in my favorite language, Visual Foxpro. It won't port to a mac, but I don't own one. It won't run on Linux, but I don't have any of those either. Nor a Unix. I also don't have a Cray. The point is, sometimes you can do a better job, especially when trying to do graphics rich, highly interactive things, when you do get a bit more implementation specific. There's nothing wrong with that, and nothing that offends the gods of cross-platform. No one says the whole thing, and everything that anyone would ever chose to use with it, has to run on every conceivable platform from Windows to a slug to my toaster.

For instance, everyone has their own music ripper. These pretty much line up by platform. No one seems to feel that you have to run a perl based CD ripper in order to be following the spirit of Slim. Similarly, there'd be nothing wrong with a windows only UI implementation, running as a CLI client and a totally different one for the mac, for the palm, for the penguin, etc.

Trying to make them all run one set of common code might well, unfortunately, end up with a least common denominator UI. And that might be pretty sad.