Winamp Freeform skin engine bug thread

[Plague]

gradients can be done as bitmaps in the elements (thus allowing for gammagroups), and then used as regular layers..
for example:

<bitmap
  id="wasabi.frame.basetexture"
  file="$gradient"
  color="73,78,91"
  w="256" h="256"
  gammagroup="Backgrounds"
  gradient_x1="0.5"
  gradient_y1="0.5"
  mode="circular"
  points="0=#cfcfcfcf;1=0,0,0,0"
  gradient_x2="1.50"
  gradient_y2="0.5"
/> 

the eqvis should work with colorid's like rohan said, or it should work like the regual vis does ie:

<eqvis
  id="spline"
  fitparent="1"
  colortop="60,80,40"
  colormiddle="255,192,255"
  colorbottom="80,40,60"
  colorpreamp="128,128,128"
  gammagroup="eqvis"
/> 

I haven't tested it, but I will later..

[rpeterclark]

I had tried that bitmap gradient method when I read about it, but I couldn't get it to work.

@rohan, unfortunately color ids do not appear to work within the gradient points attribute.

Edit: Interesting, your gradient code DOES work, but only with the "mode" attribute specified which I had not seen before. Where did you read about this attribute and what other values are available to assign to it? I guessed "rectangular" and "linear", but it didn't work.

Another edit: Ah, by digging through the source here it seems that it would expect a value of either "linear" or "circular" but I guess something is still whacked. The "linear" value does not seem to have any effect on the <bitmap> method, and the "circular" value does not seem to have any effect on the <gradient> method.

[Plague]

it defaults to linear if no mode is specified and it works fine, almost.
There's one bug with linear that I have noticed:
you can't do a horisontal gradient, only vertical or diagonal.
As in, one of the 'y' values need to be set, but none of the 'x' values need to be set in order to make it work.
so I can do theese:

<bitmap 
  id="test1"
  file="$gradient" 
  w="256" h="256" 
  gradient_x1="0" 
  gradient_y1="0" 
  points="0=255,255,255;1=0,0,0" 
  gradient_x2="0" 
  gradient_y2="1" 
/>
<bitmap 
  id="test1"
  file="$gradient" 
  w="256" h="256" 
  gradient_x1="0" 
  gradient_y1="0" 
  points="0=255,255,255;1=0,0,0" 
  gradient_x2="1" 
  gradient_y2="1" 
/>
<bitmap 
  id="test1"
  file="$gradient" 
  w="256" h="256" 
  gradient_x1="1" 
  gradient_y1="1" 
  points="0=255,255,255;1=0,0,0" 
  gradient_x2="0" 
  gradient_y2="0" 
/> 

etc, but not these:

<bitmap 
  id="test2"
  file="$gradient" 
  w="256" h="256" 
  gradient_x1="0" 
  gradient_y1="0" 
  points="0=255,255,255;1=0,0,0" 
  gradient_x2="1"
  gradient_y2="0"
/>
<bitmap 
  id="test2"
  file="$gradient" 
  w="256" h="256" 
  gradient_x1="1" 
  gradient_y1="0" 
  points="0=255,255,255;1=0,0,0" 
  gradient_x2="0"
  gradient_y2="0"
/> 

also, gradients like theee only respond to colortheme changes after a skin refresh..

edit:
btw, the eqvis doesn't seem to be able to have gammagroups at all, like mentioned earlier.
The best thing would be to make it accept colorid's for each color and then make gammagroups for those.
Same with regular vis really, instead of, or as a complement to, the current way of doing it with one gammagroup for all bands.

edit2:
actually, it would be nice if regular gradients (not the bitmap one's I've shown in this post) could accept colorid's aswell, so they could use gammagroups.

[Guest232]

Another small bug: the thumb of the balance slider disappears when the slider is used and then set back to the center position, if you use a vertical slider. A working example can be found in Rectangular.

[carlosp]

yep. had this bugtoo in a skin i programmed.

[Plague]

another bug:

isVideo() isn't reliable.
if I for example do a

if (isVideo()) {
//do video stuff
} else {
//do audio stuff
} 

it will do the audio stuff even when playing a video.
I'm not sure it'll do this on all video formats tho.

[Plague]

two more bugs..

the first one is a revisit to the discussion about gradients and gammagrouping.
I previously said gammagroups work with gradients if the gradients are made as bitmap elements.
However, I was not currently aware that regular gradients

 <gradient fitparent="1"
  mode="linear" gradient_x1="0" gradient_y1="0" gradient_x2="1" gradient_y2="1"
  points="0=#dfdfdfdf;0.5=32,32,32,0;1.0=#dfdfdfdf" gammagroup="Titlebars"
  inactivealpha="128"
 /> 

can also have gammagroups, although they don't work as good.
If gradients are used this way, changing colorthemes will only have effect after a skin refresh.. Should be simple enough to fix..

I previously also stated that bitmap element gradients have this bug, but that's not true.. gradients done as bitmap elements respond instantly to colortheme changes.


The second bug is with <wasabi:hslider/> and <wasabi:vslider/>.
they don't respond to an action="" tag, for example:
<slider action="volume"/> works, but <wasabi:hslider action="volume"/> doesn't work.
The only difference between a <slider/> and a <wasabi:hslider/> is that the second one is pre-skinned with system-elements, and that's the only thing that should differ. But since the wasabi one is an XUI, something prevents it from getting the action tag.
I think it's the embed_xui line that's not linking all stuff correctly.

same thing with the tooltip tag actually, and that's the same with all XUI's I know of, except wasabi:button.
The strange thing is that wasabi:button works fine with both action and tooltip..

[leechbite]

yes Plaque, sliders dont seem to react to any "action" tag changes. i dont think its the embed_xui though because even if you do <sendparams ..> still wont work. and even if you do in a script slider.setXMLParam("action","...") still wont respond.

[Plague]

actually, if I create a control script for it that forwards, let's say '_action', to 'action' in onSetXUIParam, it will work.. that's why I think it has to do with embed_xui..

in anyway, it's a bug that's annoying the crap out of me...



now, about the isVideo() bug I mentioned earlier:
I've found out that it only seem to happen when using Christophe's in_mplayer plugin instead of in_dshow.
So it seems like the problem is with that plugin, not maki.
However, it's still a problem.

[pjn123]

Focus bug: When using winamp with a skin with more than one components in a single window the focus of the mouse and keyboard should be what the mouse last clicked. For skins with component/s this should be like this, evering else must be kept as it is at the moment.

Can't open 3d party plugins with a button.(Only works with Video,Libr,Avs,Playlist)

If you use a horizontal slider for the preamp it only goes from 0-127...Not like it should from -127 to 127.

PLEASE fix the focus bug because this make SingleUI skins useless.

[Benski]

The following bugs are fixed in 5.2 Beta Build 427

* regions on components don't work
* <playlisteditor/> objects doesn't count item index in the same way as regular playlist editor.
* PE_Info / VID_Info case sensitivity

Someone please verify

[Plague]

regions on components

I get the attached message when I try using regions on components, with the following maki code:

#include <lib/std.mi>

System.onScriptLoaded() {
  component avs = getScriptGroup().findObject("avs");
  region r = new region;
  r.loadFromBitmap("avs.map");
  avs.setRegion(r);
} 

the bitmap used was transparent with black parts where I wanted the component to be visible.
I've also tried using a transparent with white parts and a full black/white image, all with the same result.

[Plague]

&lt;playlisteditor/&gt;

yea, confirmed..
it now indexes the same way as regular playlist editor..

However, it seems a bit slow to update which item has been selected/played and so on..
And if you manually doubleclick on another item in it, the previously played item will still have the outline around it, until you click somewhere in the playlist.

Also, does the <playlisteditor/> object now work without having to have a sidecar present (but not neccesarily visible)in the xml, as long as main="1"?


edit:
PE_Info / VID_Info case sensitivity also confirmed working
they're both now case insensitive.

[Benski]

Re: regions on components

Originally posted by Plague
I get the attached message when I try using regions on components, with the following maki code:

#include <lib/std.mi>

System.onScriptLoaded() {
  component avs = getScriptGroup().findObject("avs");
  region r = new region;
  r.loadFromBitmap("avs.map");
  avs.setRegion(r);
} 

the bitmap used was transparent with black parts where I wanted the component to be visible.
I've also tried using a transparent with white parts and a full black/white image, all with the same result.

Plague - can you provide a functional skin that replicates this? or at least attach your avs.map file

[Plague]

sure, here's a very simple skin with a play and a stop button and the avs component placed in the same window.
the avs should be round in this skin, covering the blue area in the main.png file, if and when regions work that is..