PDA

View Full Version : Command location index needed?



ceejay
2006-09-30, 02:28
Over in the beginners forum today we had yet another query (http://forums.slimdevices.com/showthread.php?t=28073) in the form "where do I find the command for xxx..."

I've asked a few of these myself in the past! It can be a pain trying to find some command or setting that you just know is there but you're not sure which of the several server or player settings sections its in. Worst, when you are in a hurry, you might miss it first time you look at a page and find youself going in circles.

So, would an index help?

Ideally this would be in the slimserver "help" section but if we are to do the community/open source thing we might be better putting it in the wiki, at least to start with.

I was thinking of a table along the lines of (please excuse scruffy prototype)




Command Function Location Sublocation

Date Format Set Long and Short date displays Server Settings Formatting
Firmware Version Show current player firmware Player Settings Basic
Language Set language used by UI Server Settings Basic
Music Folder Where SS will look for music files Server Settings Basic
Title format Define formats for titles Player Settings Basic


Obviously we'd need to qualify which version this applied to.

If something moved in some future version, this could be even more valuable... you could show the location as "Player Settings - Basic (6.5.x)" and underneath "Player Settings - Newstuff (7.x)"

So - do we think this is a good idea?

Does it already exist somewhere and I've missed it?

Is there a better way of achieving the result than the one I've outlined?

Do variances in skins make this too hard to make valuable?

Is it going to take longer to find and use the index than it would to go slowly through all the options?

Optional extras:
(1) more columns to show location in player UI menu [but this is user configurable!]
(2) something about plugin configuration screens (not all of them go into "plugins" !) (my guess on this is to allow the inclusion of a single entry per plugin, not per config item, flagged to make it clear that its a plugin and not core... also need to distinguish between bundled plugins which are officially supported and third party ones which are obviously not...)
(3) for options which apply only to specific hardware, we might need an additional column to show which this item applies to, default = all

I don't mind having a go at this but would appreciate some discussion first...

Ceejay.

Michaelwagner
2006-09-30, 06:48
I don't recall seeing anything like this, and I've hunted through the wiki more than a few times.

Yes, I think it would be very valuable.

I think it would be most valuable if, with some cleverness, you could list in place of the last 2 columns, the last few versions of slimserver. So where you have location and sublocation, if you could have (at present)

current 6.5 past 6.3 past 6.2.2
location sub location sub location sub

Again, excuse the formatting, I have no idea how to make tables in postings.

This would show up, as Ceejay pointed out, what has moved in the last release or 2, since the last 4 columns could just be "same" unless they aren't the same.

And, of course, there are the issues of skins, and the player UI as well. I have no idea how to get all that into one table. I suspect you couldn't (and still retain any usefulness).

Maybe you need one such table for the player UI, and one table for each skin.

Perhaps document the "default" skin and then a differences document for the other skins?

ceejay
2006-10-01, 05:22
Thanks for the response, Michael. Any other inputs from anyone?

I note that there was another question of the same type overnight!

Oh well, in the absence of other input I've knocked up a prototype. It is at http://wiki.slimdevices.com/index.cgi?CommandIndex

I've just done a couple of the web pages so far, so we can see how it looks. In playing with this I've come to the view that:

- plugins are too hard to include so I'll ignore them (except for the ones that come as standard? - discuss!!!)
- going back to cover earlier versions is too hard and pointless
- the best way to handle future changes (ie an item moves location from one version to the next) isn't by multiplying columns as things rarely move: the small number of case we will get can better be covered by extra rows (see "DUMMY" example).
- as its an INDEX I've duplicated several entries, so for example SONG TITLE FORMAT appears in three places...
- This could get to be a very large page, it might be necessary to split it up eg A-F, G-M, etc

If anyone sees this and feels like jumping in to help fill out the table or correct errors - please DON'T just for the moment.

I think I have a neat way of creating and updating the table using excel and I could easily blow away any updates that people make. Can we just establish the principle / layout first?

Then I'll populate it and then everyone can have a go.... or else we can decide not to bother.

Ceejay

Mark Lanctot
2006-10-01, 09:10
Ceejay:

That's a great idea!

I'm wondering if something like this could be extended to the player UI. It might be more complicated, but there are frequent questions regarding "how do I re-enter DNS" and such that force me to get up off my butt, go to my SB2 and fiddle with it, hopefully not inadvertently changing something!

It'd be nice to have this all documented and perhaps numbered so that you could point a user to the wiki, "step 9".

This would be dependent on firmware version, just as the web commands is dependent on SlimServer version.

I like your idea of the command index and I'll take a look at it.

Fred
2006-10-01, 13:21
First comment is that you need to know the player: settings do change by player type (slimp3, sb, transporter).

It is scheduled for an update, but even in 6.5 the setting mechanism is entirely dynamic. The code builds up some data structure in memory which is then used to display the HTML.

As a first idea then, the table you want is *almost* in the code today. Maybe a way to create the table is to have some clever routine dump the in memory data structure... This has the advantage of easy regeneration if something gets changed! Making the table is easy, keeping it up to date is the hard part!

Another idea might be something similar to the OS X spotlight mechanism... It does index the terms in the preferences (so if you search, say, brightness, it finds "Display preferences")... What I am saying is we could have the server itself propose a search option for the setting texts. We'd get translation as a benefit. Practically, maybe we need to add an invisible "tag" or "keyword" to the data for searching.
That would be self-updating and on-location (but could not cover player initial setup).

Fred

ceejay
2006-10-01, 15:45
First comment is that you need to know the player: settings do change by player type (slimp3, sb, transporter).


Thanks for pointing that out. I don't have access to a slimp3 but if its very different I guess that means an extra column for some volunteer to fill! Looking at the Transporter emulation in Softsqueeze, it appears not so much that its different from an SB, rather that there are a few extra options which I think is easier to handle (I have an example in my prototype table).




It is scheduled for an update, but even in 6.5 the setting mechanism is entirely dynamic. The code builds up some data structure in memory which is then used to display the HTML.

As a first idea then, the table you want is *almost* in the code today. Maybe a way to create the table is to have some clever routine dump the in memory data structure... This has the advantage of easy regeneration if something gets changed!


Hmm, I'm not so sure about this... I doubt the ability of any automated dumper to be able to decide which words to index under...




Another idea might be something similar to the OS X spotlight mechanism... It does index the terms in the preferences (so if you search, say, brightness, it finds "Display preferences")... What I am saying is we could have the server itself propose a search option for the setting texts. We'd get translation as a benefit. Practically, maybe we need to add an invisible "tag" or "keyword" to the data for searching.
That would be self-updating and on-location (but could not cover player initial setup).

Fred

Now this I like... if I understand correctly, you'd have a permanently available search field that you could type in a keyword and have it find the relevant sections ... it has the big advantage (in addition to translation) of being much more immediately accessible than the wiki.

Is this something do-able or just a glint in your eye? :)

Thanks
Ceejay

ceejay
2006-10-02, 15:48
I've now added all (I think) of the Server Settings. Player Settings mostly not included yet. I'm building this up in an Excel sheet so mass edits / reformats are fairly easy to do if required.

As before, don't "wiki" this page just yet as you may get blown away by my next update, but comments on format / usefulness appreciated.

http://wiki.slimdevices.com/index.cgi?CommandIndex

Fred - your comments on the maintainability are well taken, I have been worrying about this myself! Minor changes are obviously easily wiki'ed. For more major changes, or for a QA check, its not too hard (I have checked) to pull the table back from the wiki page into an Excel sheet, re-sort, then compare with the real system and check for internal consistency. On the grounds that (I hope) the structure isn't hugely fluid, I think this is manageable... however I do still like your spotlight idea which could make this redundant!

Ceejay

ceejay
2006-10-07, 14:53
Player settings and most player UI commands now included.

http://wiki.slimdevices.com/index.cgi?CommandIndex

I don't have access to an SB1 or Slimp3 so can't comment on the differences in player UI commands on those boxes. Is anyone feeling brave and wants a go at filling in an extra column or two?

Hope someone finds this helpful... doing it has thrown up a few questions for me which I will look into with interest...


Ceejay

Michaelwagner
2006-10-07, 20:38
I have a few SB1s, but no time at the moment.

However, I can tell you from memory that they have extra commands that SB2s and 3s don't have.

Treble, Bass, Pitch.

Fred
2006-10-09, 07:43
Hmm, I'm not so sure about this... I doubt the ability of any automated dumper to be able to decide which words to index under...

Don't get it? You have the entire explanatory string available...


Now this I like... if I understand correctly, you'd have a permanently available search field that you could type in a keyword and have it find the relevant sections ... it has the big advantage (in addition to translation) of being much more immediately accessible than the wiki.
Is this something do-able or just a glint in your eye? :)

Do-able. We want to update the settings code for 7.0 so now is a good time for this idea to be considered by the powers in place. Maybe post an enhancement request?

Fred

ceejay
2006-10-10, 13:33
Don't get it? You have the entire explanatory string available...


My problem is wondering how any automated process is going to select, say, "Power" and "Resume" when presented with text like

"You can choose how your player should resume the current playlist when you press the POWER button to turn the player off and then again to turn it on again later. This setting applies to this player and other players while they are synchonized to this player."

Someone, somehow, is going manually to have to select the keywords, which is where your idea comes in...



Do-able. We want to update the settings code for 7.0 so now is a good time for this idea to be considered by the powers in place. Maybe post an enhancement request?

Fred

http://bugs.slimdevices.com/show_bug.cgi?id=4334

Thanks
Ceejay