Some little feature requests

[3breadt]

As I still can't code in C I have to ask you developers to add these features, if you are willing to do so

-An attribute for Animated Bitmaps in which one can specify how often the animation is played
-Something like a delay function, e.g. "delay(1000);window.show()", that one can specify a delay before another command is executed

I hope that is not to complicated to accomplish

[ipkiss]

-An attribute for Animated Bitmaps in which one can specify how often the animation is played

I shouldn't be too hard. I don't have time these days, but I add this on my TODO list...

-Something like a delay function, e.g. "delay(1000);window.show()", that one can specify a delay before another command is executed

What would be the "use case" for this one?

[3breadt]

i thought about using it in a skin i planned to do, you have a main window and the playlist window grows so to say out of the main window, i wanted to have a window which contains the animation which is shown when opening e.g. the playlist, after the animation has played the window is hidden and the actual playlist window is shown.

Code: Select all

animwin.show();delay(1000);animwindow.hide(),plwindow.show()

I hope I formulated it understandable.

[xan2622]

I already asked for this feature some time ago :

From an old forum of mine : link

2.
For the moment, animations are played forever (a neverending loop).

Could you add, for animations, a new option in order play them or forever or a number of specified times.
Let's say :

loop="0" for a neverending animation
loop="1" for an animation played only once, that would stop after all the frames are played once
loop="X" for an animation played X times

Thanks.

I would prefer the skins2 engine to have loop="x" because I think it's more flexible than delay="1000".
With a "loop" attribute, you could create animations that are displayed only once, twice or X times or even with an endless loop.

Example in action :

Code: Select all

<SubBitmap id="main-window-play_over" x="394" y="424" width="24" height="342" nbframes="18" fps="36" loop="4" />

The delay of an animation is already given by "nframes" + with the "fps" attribute.

Please, could you add the "loop" attribute ?

[xan2622]

so ?

[erwan10]

this feature request makes sense. It can be added to the TODO list .... when I have some time, I will look at it.

Erwan10

[3breadt]

But there is still the question when the animation will start. Will it be started anew each time the window/layout is shown, or will it just be starte when the skin is loaded and never restarted?

[erwan10]

Your're right. this "little feature" is not as straightforward as one could think.

at first sight, I would say:
- after a certain number of loops, a animated bitmap is just transformed into a static bitmap, using let's say, the first subimage of the series of nbFrames images.
- the timer start time is not changed (which means that some animated bitmaps may never be seen as such if part of an invisible window/layout). That also means that a special care must be given to the first subimage (must carry a meaningful content in case animation is not seen)

But, other ideas are welcome.

Erwan10

[3breadt]

I would say that animations should be started each time an image gets visible, if it has been not visible before.
That would apply to all images in a formerly hidden layoutm, checkbox images that appear on hovering and other images whose visible status changes from false to true.

[xan2622]

But there is still the question when the animation will start. Will it be started anew each time the window/layout is shown, or will it just be starte when the skin is loaded and never restarted?

The workaround is simple. Just create several layouts..



Here is how I see things :

Let's say we have several background images, one for each layout.
Background A :


Background B :



The skin loads and shows the Main Window - layout_1 (with background A).
This layout_1 contains an "intro animation" which is played only once (loop=1), showing some flashing lights, or blinking neon lights (whatever).
The "intro animation" (placed somewhere over the background A) ends after 10 seconds (approximatively). The animation (which is a vertical sequence of frames in the image file, everybody knows that) ends with an empty frame. Since this animation is only played once, the last frame is the image that will be shown, transforming this animated bitmap into a static bitmap (as erwan10 said). But erwan10 suggested to use the first frame for the static image, I would prefer the last one. It sounds more logical to me (imo).

Then, since the animation is now over, the skin can be used normaly.
The user opens the EQ window, which is in fact, ... a drawer. So the skin loads the layout_2 (with background B). This layout doesn't contain any animation (but it might also.. it depends on what the author of the skin wants.. but nevermind. In this example, layout_2 doesn't contain any).

The user closes the EQ window. And at this moment, the skin loads layout_3, which is almost the same as layout_1, without the "intro animation".
Layout_3 loads the same background A image as layout_1.

This workaround is VERY simple to use. It's just up to the "skin author" just to create another layout_3 (so.. just a copy-paste to do in the xml file).



@ erwan10 :
Could you please, explain me this sentense (it would help me much if you could translate it to french, thanks) :

- the timer start time is not changed (which means that some animated bitmaps may never be seen as such if part of an invisible window/layout). That also means that a special care must be given to the first subimage (must carry a meaningful content in case animation is not seen)

-- xanax

[3breadt]

erwan10 suggested to use the first frame for the static image, I would prefer the last one. It sounds more logical to me (imo).

I'd also vote for the last frame to be shown at the end of the animation.

And that animations start anew each time they get visible.

Is that possible erwan10?

[xan2622]

aLtgLasS : what do you mean about " And that animations start anew each time they get visible. " ?
All animations are already displayed each time the layout is loaded. They don't need to be linked to their "visible" status.. Btw, I don't get what you mean here, aLtgLasS.

[3breadt]

The problem with animated bitmaps that have a loop attribute is how VLC determines when to start/restart the animation. This problem was not there before. Before the animation just was continuously repeated. Now with animated bitmaps that have an "end" the question is, what to do once the animation has been played to the end?

Erwan10 suggested that at this point the animated bitmap turns into a static bitmap. I understand from this, that it wouldn't any more be possible to play the animation again after it has been shown once. That would not be a desirable behavior imho.

What I suggest now is, that each time the animated bitmap gets visible (be it through a layout change, a mouse hover or some other visibility change) the animation is played back from the beginning and, if it is shown long enough, ends with the last frame.

Is that possible erwan?

[xan2622]

Ok, now I clearly understood your point, aLtgLasS. Thank you for your explanations.

But then, I disagree a bit with you. There is no need to implement this "visible" behaviour for animations.
Animations, like before, just have to be displayed automatically when the layout is loaded.

The problem with animated bitmaps that have a loop attribute is how VLC determines when to start/restart the animation. This problem was not there before. Before the animation just was continuously repeated. Now with animated bitmaps that have an "end" the question is, what to do once the animation has been played to the end?

Just let the animation end, and voila. That's the purpose of the setting "loop=1" (or loop="4" ... whatever), ... to set an ending.

Erwan10 suggested that at this point the animated bitmap turns into a static bitmap. I understand from this, that it wouldn't any more be possible to play the animation again after it has been shown once. That would not be a desirable behavior imho.

Again, that's the goal of "loop=1"..
You want the animation to be played again ? Then just create a checkbox.

Example:

Code: Select all

<!-- BITMAP ID DECLARATIONS --> <Bitmap id="main-window-subbitmap" file="images/main-window-subbitmap.png" alphacolor="#ff00ff"> <!-- Background --> <SubBitmap id="main-window-background" x="153" y="830" width="435" height="216" /> <!-- pretty animation --> <SubBitmap id="main-window_pretty-animation_auto-started" x="127" y="1" width="52" height="828" nbframes="18" fps="18" loop="1" /> <SubBitmap id="main-window_pretty-animation_when-hovered" x="180" y="1" width="52" height="828" nbframes="18" fps="18" loop="1" /> </Bitmap>

and below, in the same XML file :

Code: Select all

<!-- POSITIONS OF ELEMENTS --> <Window id="main-window" x="200" y="200" dragdrop="true" playondrop="false" > <!-- **************************************** Main Window **************************************** --> <!-- ******************** Default Layout ******************** --> <Layout id="main-window-default-layout" width="435" height="216" > <!-- ******************** Group ******************** --> <Group x="0" y="0"> <!-- pretty animation --> <Checkbox x="335" y="85" up="main-window_pretty-animation_auto-started" over="main-window_pretty-animation_when-hovered" state="main-window.isVisible" action1="none" action2="none" tooltiptext1="" tooltiptext2=""/> </Group> </Layout> </Window>

What I suggest now is, that each time the animated bitmap gets visible (be it through a layout change, a mouse hover or some other visibility change) the animation is played back from the beginning and, if it is shown long enough, ends with the last frame.

Everything we need is erwan10 to add these settings to images :
loop="0" --> unlimited loop
loop="1" --> played only once
loop="26" --> played 26 times (it's just an example )

[erwan10]

Hi all,

I just made the following patch (not yet committed) :

- a loop parameter is added (default value is 0, meaning infinite number of loops)
- the last frame becomes the static image once the animation is over.
- animation is automatically started again when visibility is toggled for the control or when the layout becomes active
- animation is _not_ restarted when visibility is changed for the window

That means :
- if switching visibility of control, animation starts again.
(for example, a control with visible="vlc.isRecording" can flash something every time a new recording occurs)
- if switching active layout, animation starts again.
- if switching visibility of window, this has no effect on animation (no restart)

fyi, the restarting is indeed important, because _all_ controls are created at skins initialization, and they all start their animation right away (whatever their visibility, whether the layout is active or not, whether the window is shown or not)

Any more comments ?

Erwan10

[erwan10]

The patch has just been committed to the dev branch (vlc1.1).

Nightly build (at least for Windows) should be available tomorrow.

The patch does things as described in the previous post.
Just one minor detail, restarting animation is only implemented on Button controls for now. Checkbox only implements a one-off animation cycle. Tell me if you need restarting animation for checkbox too.

Have fun with it

Erwan10

[xan2622]

I think we need them too. Or examples.
I'll update my skins with this parameter as soon as I get this nightly build.

erwan10 : would there be a way to "chat" with you on IRC someday ? I would like to talk to you about this feature in french, if you don't mind.
I understand english but in french, I would be 100% sure of what's been said here.

[erwan10]

erwan10 : would there be a way to "chat" with you on IRC someday ? I would like to talk to you about this feature in french, if you don't mind.
I understand english but in french, I would be 100% sure of what's been said here.

Well, no problem... But your English sounds good to me ...

[xan2622]

Now Erwan10, could you please add these paremeters :

loop="1" (played only once)
loop="2" (played twice)
...
loop="8" (played 8 times...)

Thank you.

[erwan10]

Already added in vlc1.1 (dev branch)

Nightly builds for Windows has been working fine lately.

Not sure it will be added in vlc1.0.x though, since it's a new feature.

Erwan10

[xan2622]

Which one should I download ?

branch-20100116-0201
trunk-20100116-0002

I never know..

[erwan10]

http://nightlies.videolan.org/build/win ... 0116-0002/ for instance