[BUG] Slider Positioning

[joethezombie]

I created a slider like this:

Code: Select all

<Slider x="19" y="269" points="(0,0),(57,0)" up="volume_slider_normal" down="volume_slider_down" over="volume_slider_over" tooltiptext="Volume: $V%" value="volume" xkeepratio="true" />

The images for the slider are 560x69. However, when the skin is displayed, the slider is half-way off the left of the window and much to high. I have to adjust the code to

Code: Select all

<Slider x="300" y="303"

in order for it to display in the correct location. But that doesn't even work because if you resize the window, the slider is repositioned strangely, and not like if I used a 560x69 image.

[ipkiss]

According to the 'points' attribute in your XML file, your slider is horizontal. Is it really what you want? If so, could you provide a skin showing the problem?

[joethezombie]

Here is a quick skin that shows the problem.

You will note that although both the image and the slider are to be displayed at x=400, y=250; the slider is not displayed correctly (even when set at 0%). Now, resize the window and you will see the slider is not positioned the same as the image at all. In fact, it seems to move 2x as fast as the image towards the right while resizing.

Also note that the y position is off as well. The two red squares should be directly on top of each other (at y=250), but again, the slider is positioned incorrectly, although vertical adjustments to the window do not cause strange positioning as it does with horizontal adjustments.

This makes a centered control group absolutely impossible as the sliders do not move with the rest of the controls.

The problem increases exponentially as the size of the slider and image is increased. If you make a slider that is 400 pixels wide, it will not even be displayed on the screen.

[ipkiss]

You will note that although both the image and the slider are to be displayed at x=400, y=250; the slider is not displayed correctly (even when set at 0%).

I guess it depends on what you call "correctly"...
Currently, the corrdinates defining the Bezier curve of the slider are relative to the top-left-hand corner of the Slider control. The slider cursor being centered on the corresponding curve point, it is normal to see this offset. You can see this easily when the slider is at 0%: the center of each square is exactly on a corner of the other square.
So this is a feature, not a bug

Now, resize the window and you will see the slider is not positioned the same as the image at all. In fact, it seems to move 2x as fast as the image towards the right while resizing.

It rather looks like only the left position of the slider is taken into account when xkeepratio is set to true (as if the width was 0). This is indeed a bug, I'll have a look at it during the week-end.

[joethezombie]

I guess it depends on what you call "correctly"...
Currently, the corrdinates defining the Bezier curve of the slider are relative to the top-left-hand corner of the Slider control. The slider cursor being centered on the corresponding curve point, it is normal to see this offset. You can see this easily when the slider is at 0%: the center of each square is exactly on a corner of the other square.
So this is a feature, not a bug

Oh, I see. That makes sense. I had just assumed the slider's 0% should be the same coordinators as the slider control. But that small offset can be taken into account, so I'll agree that is a feature!

It rather looks like only the left position of the slider is taken into account when xkeepratio is set to true (as if the width was 0). This is indeed a bug, I'll have a look at it during the week-end.

Thank you very much! As long as the SliderBackground is positioned the same as an Image when resizing, the problem would be fixed. We can always fine-tune the slider itself using the Points attribute.

[ipkiss]

Now, resize the window and you will see the slider is not positioned the same as the image at all. In fact, it seems to move 2x as fast as the image towards the right while resizing.

In fact, this is not a bug either!
The xkeepratio attribute means that the ratio between the space on the left of the control and the space on its right is constant. So if 2 controls are at the same position, but have different widths, their ratios are different (because the space on the right is different). As a result, they won't "move" at the same speed when resizing the window...

[joethezombie]

But the widths are the same size. In the example skin above, they are both 10 pixels wide. They are both to be displayed at the same position, but the volume control does not follow the image.

Here is a better example of the bug. Look at my skin here. Resize the window and watch the volume control. It is not positioned correctly, even though it is the exact same width and height as the other controls (560x69).

Code: Select all

<!-- MAIN CONTROL Background --> <Image x="19" y="269" image="main_blank_controls" lefttop="leftbottom" rightbottom="leftbottom" xkeepratio="true" /> <!-- Mute and Volume Slider Controls --> <Slider x="19" y="269" points="(405,35),(463,35)" up="volume_slider_normal" down="volume_slider_down" over="volume_slider_over" tooltiptext="Volume: $V%" value="volume" lefttop="leftbottom" rightbottom="leftbottom" xkeepratio="true" > <SliderBackground image="volume_slider_background" nbhoriz="1" nbvert="7" padhoriz="0" padvert="0" /> </Slider>

Both the MAIN CONTROL background and the volume_slider_background are 560x69. They are both displayed at x=19 and y=269. But when resizing, the volume control background does not stick with the image.

[ipkiss]

The width of the slider is the width of the Bezier curve (51 pixels in the case of the slider_bug.vlt skin), not the one of the cursor.

[joethezombie]

Are you saying the position of the <Slider> is dictated by the width of the bezier curve? If so, that is the problem!

If the <Slider> contains a <SliderBackground> that is larger than the bezier curve, then the position of the <Slider> should be dictated by the width of the <SliderBackground>, not the bezier curve!

The slider_bug.vlt skin does not contain a <SliderBackground> because I did not understand how positioning worked, or what really was wrong. Now I do. The bug is that the <SliderBackground>, if present, is not used to dictate the position of the slider.

Can we please change the positioning of the <Slider> so it works like this:

• If <Slider> contains a <SliderBackground> then use the width of the <SliderBackground> to determine the position of the <Slider>
• If <Slider> contains no background, then use the width of the bezier curve to determine the position of the <Slider>.

[dionoea]

Can't you just resize your bezier curve to fit the background image ?

[joethezombie]

No. The bezier curve only takes up a very small portion of the sliderbackground.

Currently, the only way to have a centered control group is to create all the controls with a fixed width-- let's say 560px.

So, even though your stop button is (visually) only 25x25, the actual button is 560px wide, with transparency. Again, see this skin for an example. Note how all the control buttons move as a group, with no space increasing between the buttons as you enlarge the window.

All the control group buttons are 560px wide, with the actual visual portion of the button placed specifically where it is to be shown. See this post for more information.

Because the slider control doesn't use the actual width of the control to determine position (instead, it only uses the width of the bezier), it can not be grouped with the other controls.

Like I say, the greatest width out of the beizer or the background should determine position. Currently, the width of the background is simply thrown out of the equation, even though it is most likely larger than the bezier.

[ipkiss]

Can we please change the positioning of the <Slider> so it works like this:

• If <Slider> contains a <SliderBackground> then use the width of the <SliderBackground> to determine the position of the <Slider>
• If <Slider> contains no background, then use the width of the bezier curve to determine the position of the <Slider>.

No, I don't want to do that. The SliderBackground tag is there to allow animation effects when moving the cursor of the slider. The "core" of the control is still the Bezier curve, and the background should not dictate its width to the control.

What's more, I think that using very wide images with transparency is a bad thing (in particular for the performances... handling the transparency is expensive, and resizing becomes quite slow). I understand your need to move controls together, and there is indeed no other way to achieve this goal. But changing the slider will simply solve this particular case, while it would be much better to provide a generic way to move controls together.

I would prefer something like the following:
A new Panel tag (for example) could be used to contain a Group tag. All the controls inside this Panel tag would be moved together if the Panel tag has xkeepratio="true". The initial width of the Panel could be either computed using a width attribute, or using the leftmost and rightmost positions of the controls inside the Panel (I don't know what would be the most convenient... but the first one is probably easier to code!). The Panel tag could also behave like all the other controls, i.e. have the x, y, lefttop, rightbottom, visible and help attributes. The lefttop, rightbottom, xkeepratio and ykeepratio attributes of the controls in the Panel would then be relative to the Panel instead of the Layout.

Of course, there are probably a few details to solve, and it may be hard to implement
Would such a solution suit your needs, or did I miss some requirements?

[joethezombie]

I also agree that creating large images with transparent areas for the purpose of grouping is a kludge. I think your panel tag idea is a superb idea. That would be a very much welcomed feature!

But, I still think the width of the sliderbackground should be used to position a slider. Here is the reason:



See that slider control? Notice how the bezier portion of the slider is not as wide as the sliderbackground? The sliderbackground image contains 7 steps, so as to animate the speaker icon when the volume is increased. I thought that was the whole idea of the nbvert= element.

In order for that control to be placed correctly, the width of the background must be used, not the width of the bezier (which is a much shorter width).

I think a panel tag combined with fix I am asking for is the perfect solution.

[ipkiss]

I get your point, but I am still not convinced. What you are doing is a particular kind of grouping, and it could always be done with a Panel control containing the slider and its background, both being tied to the lefttop corner of the Panel. I don't know if the current situation (using the size of the curve for the size of the control) allows doing more things than what you propose, but it is more consistent between sliders with and without background images. What's more, it is backwards-compatible, so we avoid breaking older skins...

The nbvert attribute is there to compute the height of the individual background images, since we also have the number of images, the number of padding pixels, and of course the total height of the image. This attribute is not used for anything else.

[joethezombie]

Well, that is a very good point and I agree. The panel tag would allow for 100% backwards compatibility and for working positioning for grouped controls. Is this something that is going to be implemented?

[ipkiss]

Probably. I will start it tonight, but I don't know when it will be finished.

[joethezombie]

Wow. That is impressive. I have released my current skin, but hope to create an all new original when panels become a reality. Thanks for this good discussion, and for your hard work on VLC!

[ipkiss]

I have finished coding it, it will be available in the next nightly build. The online documentation will also be regenerated in a few hours.

Note however that the nightly builds may be less stable, and some features may be broken (the Video control in particular).

[joethezombie]

All I can say is that, Wow! You are good.

I adapted the WMP11 skin to use panels, and it is absolutely _perfect_. Thank you so much for this included functionality!

(Note to would be downloaders: this skin requires the use of a nightly build of VLC)

[Asim]

about time something like this was done

no more need for one big image w/ transparency


edit: i found a typo on the skins page...

If you still don't find any skin you like, why not creating a better one?

creating... should be create...

- Asim

[Jean-Baptiste Kempf]

repaired.

[Asim]

hmm.. i've had a look @ the panel thing... i reckon we should do away with the group? or perhaps merge the panel w/ the group element, since they're both similiar?

anyway... i had a request for the panel thing... perhaps allow the visible attribute for the panel? and for the visible attribute itself... allow for a "dummy" value e.g. dummySet

these features would greatly enhance the skins functionality i reckon

- Asim

[joethezombie]

Panels with a visible attribute (you'd have to give the Panels an ID attribute as well) combined with a PanelID.isVisible boolean expression would be a really great idea, but I think that is more what the Layout tag is for?

The problem with Layout, is that after switching Layouts the video is broken until the user presses stop, so that feature is really not usable right now until it is fixed.

[Asim]

that's one of the reasons why i didnt implement the layout system in my skin... simply beacause of the video issue. however, having to create a whole new layout just for a single change is rather insane. hence, it would be great if the "Panel" had all the "common attributes"... no need for redundancy in the coding that way...

- Asim

[joethezombie]

Very true, very true...

I'd love to see these enhancements to the panel tag, but I also say the biggest roadblock right now in creating skins is the video problem when changing layouts.