viewport labels allow real names now (do the same for images?)

[JdGordon]

as of r27665 viewports allow you to give them a proper name instead of a single letter. Now is this as nice as I think it is? Would this be useful for images?

The reason I didnt outright do this for images is because the %xd() token is bat shit crazy odd...

IMO %xd(Aj) makes no sense at all. My proposal would change that to a full name for the image (or one letter if you wanted) and using a NUMBER for the subimage instead of a letter. i.e %xd(playmode, 2).

The other possible change would be to allow something like this: %xd(playmode, %mp) which would mean "use the subimage from the "playmode" image strip using the value from the %mp (playmode) token).. You would have to split your images into logical strips (which presumably is happening anyway) but IMO that is much cleaner than %?mp<%xd(Fa)|%xd(Fb)|%xd(Fc)|%xd(Fd)|%xd(Fe)>

The last part of the question is then do we want to allow the current %xd() tag to keep working if you use one letter labels? (This would eventually be removed, sometime in the future, more than 1 release away)

[JdGordon]

I might need to clarify the idea a bit...

The new tag would allow you to either use a number or a tag for the subimage (%xd(a, 1) or %xd(a, %mh) ).
The %xl line wouldnt change, so you still need to specify how many subimages are in the image. What happens when the tag says "subimage 6" but the image only has 5 subimages? we would need to decide.

To make the tag type slightly better it would probably get an options offset value (i.e %xd(foo, %mh, 3) so the subimage would be %mh +3) so you could join image strips, although I wonder if that defeats the purpose of the change which is really to make the names easier.

[Llorean]

The obvious solution is to have it simply fail and display nothing if you ask for an invalid sub-image. But it might also make sense to just reuse the highest image, or repeat (treat it like modulo and return to the start of the list of images). I can't immediately think of a use for "repeat" but at the same time, I imagine it adds a degree of flexibility (for example, if you just wanted a short animation to loop while changing volume to give you an idea of the rate of change, you could loop through a 4 frame animation without having to cover all possible volume values, and it would update at the rate of change).

[JdGordon]

well, right now we dont have a tag which just counts, animations are done with sublines but if a counter tag was added I tihnk we could make that work here also... %xd(animation, %xx(<timeout>, <max count>)) no need for mod at all.

I'm not sure which of blank or last image makes more sense (I dont think either is correct) but (quickly checks code) it looks like last image would sort of win... the evaluate_conditional() function needs to know how many options the tag has which would need to be faked, logically that number would then come from the %xl() line.

[Llorean]

I wasn't really thinking like subline animations.

Rather, for example, volume more or less returns a value on Player X between -80 and 0 (just as example numbers).

So if you gave it a four frame image, and then "volume" as the tag to use, and put it inside the "volume is changing conditional" as you adjusted volume you'd cycle through those four frames continually, moving upward or downward in line with the rate you were changing volume. This would mean that it wouldn't be "a frame every 2 seconds" or whatever, but rather "a frame every time the volume level changes" to match activity (something similar could be done for, say, fast forward such as the tape wheels on the tape animation spinning in a rate in line with the seconds position in the song, so as FF accelerates, the wheels spin faster).

Just an idea though. Still not sure if I'm quite explaining it clearly. But basically, use the existing value tags like location in the song or volume as the index, but modulo it the number of frames so that you constantly cycle through a shorter fixed animation at a rate equal to change. It adds some feel of interactivity beyond what we have now.

[[Saint]]

I've been thinking it and thinking it, and just have to really say it...

This seems like throwing out an idea that works fine, for an idea that will just end up complicating things.

I'd really love to know the percentage of users that voted "yes, and dont bother keeping the old %xd(Aa) type tag" that actually theme Rockbox.

Is:

Code: [Select]

"%xd(animation, %xx(<timeout>, <max count>))"
*really* any better than what we have now...which is perfectly usable, and readable in my opinion.
(remember, there might be an additional offset value in there too somewhere...)

If you can guarantee that the tag has no less states than the bitmapstrip it is assigned to has subimages, and that you only want to use said images in the exact order as dictated by the layout of the subimages, then this works....but it seems like a terribly specific, and limited use case to me.

(example: What if you wanted a different timeout for just one image even? This code can't help there and you need to do it the 'original' way)


[St.]

[Llorean]

Neither jdgordon nor I suggested anything that includes a "timeout" value. It's pretty clear you're misunderstanding what is being suggested here. This isn't time based at all, and time is only involved in the one instance I suggested where the time is not a timeout, but the frequency at which a user pushes a button and the rate of playback of the song.

If you want to complain about the idea, take the time to understand it first. If you don't get what I'm suggesting, I can try to explain it again more clearly, but I need to know what you think I suggested first. What do you think is being described exactly?

[seani]

On the face of it, useful, but two questions:


What is the cost in terms of binsize?


Wouldn't it be better to abstract this sort of syntactic sugar out and just put more effort into hiding these details behind the theme builder?

Your resources are essentially unlimited on the Linux  / Windows client end.


Surely you'd hope that the fine art of hand-crafting a theme would slowly become redundant as the theme editor became more refined?


Give that's the case, why sacrifice any size / performance for readability of the raw theme file?

[[Saint]]

Llorean,


You read Jd's posts...right?

I did.

well, right now we dont have a tag which just counts, animations are done with sublines but if a counter tag was added I tihnk we could make that work here also... %xd(animation, %xx(<timeout>, <max count>)) no need for mod at all.

[Llorean]

Yes, and if you read the whole thread, he posted that in response to a misunderstanding about my post - that is, he didn't suggest a timeout, but he thought I did and was disagreeing with it. Since I didn't, his point there was pretty irrelevant.

Sure, cherry picking one post in which the author also missed the suggested idea can work in your favor, but the point is the original idea and my suggestion both don't include the idea of a timeout, so nobody was arguing for it at the point you started arguing against it.

[JdGordon]

I wasn't really thinking like subline animations.

Rather, for example, volume more or less returns a value on Player X between -80 and 0 (just as example numbers).

So if you gave it a four frame image, and then "volume" as the tag to use, and put it inside the "volume is changing conditional" as you adjusted volume you'd cycle through those four frames continually, moving upward or downward in line with the rate you were changing volume. This would mean that it wouldn't be "a frame every 2 seconds" or whatever, but rather "a frame every time the volume level changes" to match activity (something similar could be done for, say, fast forward such as the tape wheels on the tape animation spinning in a rate in line with the seconds position in the song, so as FF accelerates, the wheels spin faster).

Just an idea though. Still not sure if I'm quite explaining it clearly. But basically, use the existing value tags like location in the song or volume as the index, but modulo it the number of frames so that you constantly cycle through a shorter fixed animation at a rate equal to change. It adds some feel of interactivity beyond what we have now.

My initial thought is probably a no to that. The counter tag would be able to do the same thing and it wouldnt need special extra support code to make it work (right now the volume tag is handled in 3 different ways, I dont really want to add another )

[St.]: you misunderstood the post you quoted %xx would be a tag which counts, completly seperate from the %xd() tag.

Seani: frankly the bin/ram delta would be tiny and the needed cpu time would arguably be smaller with this change anyway.

[JdGordon]

for those that care %xd has now been changed to do pretty much everything I outlined in the first post (i think).
If you want to you can use a full label name, and another tag or number to specify the subimage to draw.
I couldnt be bothered with the hassle of breaking themes so the old way still works.

[epithetless]

I couldnt be bothered with the hassle of breaking themes so the old way still works.

Thank you for that.