Sorry for all the quotes but they're all relevant to my question.
jmarshall Wrote:Player.SeekOffset is in SVN as of r31232. It's now up to skinners to support it. I expect Confluence will have support as soon as Jezz_X has a bit of spare time 
Cheers,
Jonathan
Hitcher Wrote:Works perfectly -
Thanks.
Jezz_X Wrote:Just out of curiosity what did you use as the visible condition to display it? and did you try FF RW to see if it also shows (when it shouldn't)
Hitcher Wrote:I didn't check FF/RW but have fixed that now with the following -
PHP Code:
<control type="label" id="0">
<include>OSD_Player_Labels</include>
<label>$LOCALIZE[773] $INFO[Player.SeekOffset]</label>
<visible>Player.DisplayAfterSeek + ![player.forwarding | player.rewinding]</visible>
</control>
And I also changed the PLAYING label -
PHP Code:
<control type="label" id="0">
<include>OSD_Player_Labels</include>
<label>$LOCALIZE[40244]</label>
<visible>Player.Playing + !Player.DisplayAfterSeek</visible>
</control>
Jezz_X Wrote:yeah thats basically what I was using too but I was kind of hoping that after I gave jmarshall the hint that "Player.DisplayAfterSeek" should do what it says and only display After Seek then FF and RW wouldn't be an issue at all thats why we have "Player.Seeking" it would seem both do exactly the same thing
Hitcher Wrote:I tried using Player.Seeking but that seems to be true even when playing.
The problem I have is if you press seek immediately after a seek only the label (SEARCH in my case) appears on screen with no seekoffset time.
Now if I change the visible condition to Player.SeekBar it works perfectly all the time but only if you're not viewing the info at the same time (obviously because the seekbar isn't being called then).
Finally changing the condition to Player.Seeking results in nothing being displayed at all which seems to defeat the purpose of that condition altogether.
Ok, I suspect I can do a quick fix for this, so will try that first up.
Really it shows this whole thing needs a spring clean. I wonder whether that might be (in the long run) the less painful fix.
I think we need 3 separate bools.
1. A general bool to specify that the seek bar should be shown. Player.Seeking perhaps? This will be true during a seek, during an analog "seek" (eg moving the analog seekbar) during ffwd/rewd and for a period after the seek has finished.
2. A bool for ffwd or rewd (Player.Forwarding/Player.Rewinding).
3. A bool for have we jumped. re-use Player.SeekOffset ?
We then need some info:
1. Information about the jump amount (Player.SeekOffset)
2. Information about the ffwd/rewd speed (Player.Forwarding2x crap) - perhaps we could reuse Player.Forwarding to return "4" or "8" to cut down the code?
I think that is all that's needed?
Cheers,
Jonathan
Player.Seeking should be analog seek, jumping with Arrows, entering time with keypad
Player.Forwarding, Player.Rewinding and all their little addons of x2 x4 etc should not be included in Player.Seeking
Player DisplayAfterSeek should only be valid after a Player.Seeking event has taken place and that does not include FF RW
But thats just my take on it
Why do we need to be able to distinguish the above cases?
Most skins would then just OR them all together in the dialogseekbar anyway, right?
well real work confluence example
Player seeking would just show the seekbar
Player.Forwarding, Player.Rewinding and all their little addons are used for the x2 x4 graphics that move left and right depending on what you are doing
Player DisplayAfterSeek is just for that to display something after we have finished seeking in this case to show the offset values in dialog seekbar but could easily be used to pop up something else separate on the screen
And if you mean why separate out Player.Forwarding, Player.Rewinding its a hell of a lot nicer than a bunch of string compares to get the same effect
We're I think on the same page here, just coming at it from different angles.
Player.Seeking I was going to use for any event that specifies that the time bar should be shown. i.e. it would be a combination of Player.DisplayAfterSeek, Player.Forwarding, Player.Rewinding, (the current) Player.Seeking, and Player.SeekBar. After all, you hardly want to not show the bar when ffwd/rewd'ing, so this was to make it easier.
There's really 4 types of seeks
1. Jump seeks.
2. Chapter seeks, or bookmark seeks (a special type of jump seek).
3. RRwd/FFwd.
4. Analog seeking.
Player.Seeking would be true in all of them. In addition, Player.Forwarding/Rewinding would be true in case 3, and Player.SeekOffset would be true in case 1.
Case 2 and 4 don't really need anything else - they're taken care of by the seek bar anyway.
As for the idea of extending Player.Forwarding to a label, it was so you could do <texture>$INFO[Player.Forwarding,OSD,x.png]</texture>.
Cheers,
Jonathan
Sounds good to me, thanks.
I just don't think FF and RW should also be classed as seek what do you think Hitcher ? to me the seeking is the ones that make it jump
Don't know really, seeking is 'searching for' and FF/RW do fall into that category.
I can preclude FFwd and RRwd if you really want to add the conditions everywhere yourself. I'm just trying to make it easier on skinners in general by having a single boolean that they can use to popup the seekbar.
yeah but as a rule I find generalizing things takes away from the flexibility as well so its a compromise either way
Righto, will && !Player.Forwarding && !Player.Rewinding in the code.
Cheers,
Jonathan
Ok, I've fixed the problem in r31507 without changing anything as yet.
Ideally we'd do a cleanup, but I'm not sure I have time prior to Dharma, so it will have to wait until after.
Cheers,
Jonahtan