upcoming new skin feature discussion.. FS#11998 - skin vars

[JdGordon]

Hi all,
I've been working on an idea which was originally implemented in FS#11084 which adds alot of fun stuff to the skin code. This email is to hopefully explain how to use it and get feedback incase anything needs to be tweaked before it goes in (next few days probably).

What this patch adds is an ability to save some sort of state in the skin, these can almost be thought of as variables in any programming language or the x in algebra. You can arbitrarily set a value (any number 1-2.1billion), increment (optionally rollover at a specific value), decrement (with rollover backwards also), and finally, check if the value changed in the last X seconds.

Why do we want/need this?
If you try any of the touchscreen cabbies you should see a popup appear if you press the screen *anywhere*. This works but the popup can only be controlled by using the tag which checks if a touch region was pressed in the last few seconds. Now, if you want the popup to stay and be able to press other buttons on it this gets very complicated very quickly (you need to now check more than one region to see if the popup should stay open).

Concrete example: When you press the volume button on the WPS you want a display to appear with a nice slider to control the volume and to stay open until 5s after not being changed. In svn today this is incredibly difficult. With this patch it becomes much simpler.

Below is my test sbs. It is obviously a ridiculous example but I think it shows off the functionality enough to get people started (or ask questions if needed). This can be copied directly into a .sbs and run on any touch target. What it does is count from one to seven then back to one in an endless loop using two variables. One (dir in this case) is to keep track of which direction we are counting, and the other (a) keeps track of the actual count. Lastly, whenever the count changes directions it will display "CHANGE PLACES!" for ~3 seconds.

%vs() is used to change the value, %vg() is used to get the value, %vl() is used to check if time has elapsed since anything touched the value.

-----------------------------------
%Vi(-,0,0,-,-80,1)
%V(0,-80,-,-,1)
%t(0.1)%?vg(dir)<%vs(a,inc,1,7)|%vs(a,dec,1)>;%t(0.1)
%?vg(a)<one%vs(dir, inc, 1, 2)|two|three|four|five|six|seven%vs(dir, inc, 1, 2)>
%vg(a)
%?vl(dir, 3)<CHANGE PLACES!|>

-----------------------------------------

explanation:
The first 2 lines just set up viewports so ignore them.
The 3rd line checks the direction (the conditional), values are arbitrary so '1' here means count up and '2' means count down.
The 4th line checks the value and prints out a number. the first and last options also change the direction variable (both incremenet because it rlls back to 1 after 2)
The 5th line just displays the value
The 6th line checks if it is less than 3 seconds since the direction was changed, and if so display some text.


OK, finally, proper explanation of the 3 new tags:

%vs(label, action, value, [max]) : label is the unique id of this variable. action is one of "set", "inc", "dec". "set" means "x=value", "inc" is x = x+ value, "dec" is x = x - value.  vars are always initalised to 1 on load.  max is optional and means the last value before rolling back to 1 (or with the dec action the value to set to after decrementing from 1).

%vg(label) : get the current value, use in a conditional.

%vl(label, [timeout]) : check if it is less than (optional) timeout since the value was changed *by any %vs tag contorlling this variable*.


Not done yet but on the list is touch actions to control these vars directly which should simplify things even more.

So, I hope this helps explain the feature. I'm not entirely happy with the tag names and the "set/inc/dec" names so suggestions welcome.

http://www.rockbox.org/tracker/task/11998

Jonathan

[gbl08ma]

This seems exciting, unfortunately for the touch part I don't have a touchscreen target to test with (I wish I had...  even my Windows Mobile phone has a broken LCD screen, so I can't even try RaaA if it is developed for Windows Mobile). But, the variables part looks promising...
A (stupid) idea I had some days ago and is somewhat related to this, was to call LUA code from themes when certain events happen, as well as allow LUA code to draw on the themes, but this would just add complexity to the thing, and I repeat, it is a stupid idea (LUA parser is a viewer plugin, calling it just two execute two lines of code would just be waste of performance, to not enumerate other problems of my idea)

Anyways, as a user of non-touchscreen builds (I have a iPod nano 2G), I think it would be good if there was a way to show a popup when the volume is changed or the screen is locked, for example - I'm not sure if this is already possible, but I don't think so - please enlighten me. The idea was to show a viewport over all other viewports (a big volume indicator or a big lock image, respectively) for some seconds, but AFAIK this triggers a "overlapping viewports" error (and that's why I don't think it's possible). This is a subject of another thread I'll post when I'm in mood so I'll end by here to not create more offtopic.

[[Saint]]

Anyways, as a user of non-touchscreen builds (I have a iPod nano 2G), I think it would be good if there was a way to show a popup when the volume is changed or the screen is locked, for example - I'm not sure if this is already possible, but I don't think so - please enlighten me. The idea was to show a viewport over all other viewports (a big volume indicator or a big lock image, respectively) for some seconds, but AFAIK this triggers a "overlapping viewports" error (and that's why I don't think it's possible).

This should be possible with creative use of sublines and conditional viewports, no real need for skin variables to achieve what you want, though you'll probably have to rely on draw order to make sure things display as intended.

EDIT: re: overlapping viewports, ...this simply shouldn't happen if the viewport display logic in the theme code is sane.

The case for hold might be interesting to code around, but...my line of thinking presently has me leaning towards "still possible, but maybe I need to think about it some...".

The case for displaying a popup on volume change is most certainly possible already. We can already check if the volume is being changed, and display <X> for <timeout> after the tag going true/false.
With that in mind, if you're overlapping viewports, then your viewport display logic just needs a kick in the pants


[St.]

[Ste-]

A lot to get the head around but I'm sure once I do it can provide some nice results.