Support and General Use > Theming and Appearance Customization

radio screen skin token suggestions!

(1/3) > >>

JdGordon:
well, I was going to keep this quiet untill I actually had something working, but meh.... if this happens it would be sweet... If i take too long someone else will take over...

SO..... radio screen skinablity discussion time.... believe it or not.. I tinhk the biggest difficulty here is deciding on the new tokens to add to the skin language. I would like to call it [r]fms (for [remote] fm screen/skin) and would have liked to use f as the first letter for tokens but apparently they are being used already...

So how should we do this? overloading tokens might be a possibility but then we need to decide if we want to make sure they are reasonable... e.g overload ff to be frequency in both the wps and fms, or if ff can be something completly different between the two. For now at least I dont like this idea because it means more mess behind the scenes because the displayer/parser needs to know which screen its in... and then there is the mess with the statusbar needing to work with both!!

The better idea is to come up with a new set of tokens, and I need suggestions, both what to add (what info do we want avilable) but also what their token string is going to be...
f,F and r are all being used already and I'd rather not go to 3 or 4 letter tokens (although I'm kidding myself thinking we wont have to do that eventually anyway)...

So.... here is the quick list of the bare minimum I want... reply with more and what token you'd like to use for them

--------------------------
frequency
tuned? (yes/no)
mono/stereo
scan mode (preset/scan/?)
preset name (if its coming from a preset)
preset<N> name
preset<N> frequency (both of these N are +- from the current one... so -1 would be the previous (or the last if this one is the first)
preset count(?)

recording tokens:
status
time
filename
prerec time(?)

few more: ability to use translated strings
e.g "Station", "Mode"


not sure what else is needed... (Also remember that in the long term we'd like (*MAYBE*) for the rec screen to use these and other tags also...



OK, the displayer will know which screen it is in so maybe sharing *some* tags might be ok... anyway, reply with your thoughts

edit: really crappy screenshot of the first ever customised fm screen!!!

AlexP:
A couple more (albeit less important):

I guess all the things like vol, play/pause etc can be reused directly.

Album art - but this time showing the station logo (taken from the preset name?)

various RDS tags (not currently implemented, but for the future) - I only mention this now to keep in mind that more tags will be required if/when this is implemented.

Good work!

JdGordon:
the tags which arnt obviously linked to the current playing track will obviously be shared, AA is something I want to add but it could be tricky...

pixelma suggested we use the %t prefix even though it and %T are used already (for subline and umm...)

shotofadds:
Maybe not what you had in mind when you asked the question, but we will eventually need touch-enabled FF/RW buttons to choose presets (and/or tune depending on the current mode) on touchscreen targets.

Maybe even a touch-enabled progress bar for tuning? Sounds odd but it works quite effectively in the D2 OF.

kugel.:

--- Quote from: shotofadds on September 24, 2009, 01:39:47 PM ---Maybe not what you had in mind when you asked the question, but we will eventually need touch-enabled FF/RW buttons to choose presets (and/or tune depending on the current mode) on touchscreen targets.

Maybe even a touch-enabled progress bar for tuning? Sounds odd but it works quite effectively in the D2 OF.

--- End quote ---

Overloading the progressbar (%pb literally) seems useful for showing the current frequency in the within the spectrum.

Most of the fm tags can be done with the %St tag (channel config, scan mode, other radio related settings).

I'd rather have the preset tags act like track (and next track) in the wps. For consistency, since the preset list is basically a radio-playlist.

Letting the displayer now the current screen is actually quite easy (see a patch on the custom statusbar task), by exposing next_screen from root_menu.c. Except that recording-from-fm-screen doesn't change that variable so that it needs some hook.

Navigation

[0] Message Index

[#] Next page