Fruit
A 1px width/height widget should never be resized
The skin engine should be able to recognize any 1px width/height visual/element and avoid it to be resized in that width/height. So this line visual would never get to 0px or 2px when resizing the skin.
Example (only the height should be stretched when resizing) :
<visual type="color" source ="constant '#000000'" tooltip="">
<size width="1" height="200"/>
<pos x="+0" y="+0"/>
</visual>
This improvement would really help to enhance the overall rendering/stretching of the skin's png.
The skin engine should be able to recognize any 1px width/height visual/element and avoid it to be resized in that width/height. So this line visual would never get to 0px or 2px when resizing the skin.
Example (only the height should be stretched when resizing) :
<visual type="color" source ="constant '#000000'" tooltip="">
<size width="1" height="200"/>
<pos x="+0" y="+0"/>
</visual>
This improvement would really help to enhance the overall rendering/stretching of the skin's png.
Posté Sun 30 Nov 14 @ 2:34 pm
groovindj
I was going to suggest the same thing!
Somewhere here recently it was mentioned that a one pixel line had disappeared when the skin was resized, and "great minds think alike" - my idea was to have a 'force size' or 'lock size' command.
The skin I have been modifying was also doing some odd things when being resized. There were some pixels coming and going from the edge of the pitch controls.
Somewhere here recently it was mentioned that a one pixel line had disappeared when the skin was resized, and "great minds think alike" - my idea was to have a 'force size' or 'lock size' command.
The skin I have been modifying was also doing some odd things when being resized. There were some pixels coming and going from the edge of the pitch controls.
Posté Sun 30 Nov 14 @ 3:21 pm
Fruit
Can z-order browser
Now if for some reason I want to put some buttons over the standard browser I just can't because its z-order is set to "on-top". I would have to do a custom browser. Would be cool if we can set the standard browser to another/lower layer to have some graphics hovering it.
Now if for some reason I want to put some buttons over the standard browser I just can't because its z-order is set to "on-top". I would have to do a custom browser. Would be cool if we can set the standard browser to another/lower layer to have some graphics hovering it.
Posté Thu 04 Dec 14 @ 6:18 am
Fruit
Can merge visibility field types
Now, if I want any widget to show semi-transparent AND with a condition, I must write :
<panel visibility="65%">
<visual visibility="var 'myvar' 1"/>
</panel>
I would like to be able to merge the two condition types together like :
<visual visibility="var 'myvar' 1 && 65%"/>
This would save, in some cases, a huge amount of xml lines / useless panels.
Now, if I want any widget to show semi-transparent AND with a condition, I must write :
<panel visibility="65%">
<visual visibility="var 'myvar' 1"/>
</panel>
I would like to be able to merge the two condition types together like :
<visual visibility="var 'myvar' 1 && 65%"/>
This would save, in some cases, a huge amount of xml lines / useless panels.
Posté Wed 17 Dec 14 @ 5:57 am
Fruit
Color modifiers
Using classes / panels, It could be interesting to have some color modifiers just like relative coordinates, and be able to 'add' or 'substract' some colors from classes.
Example :
<define class="square_blue_thing" type="color" source="constant '#0000aa'" tooltip="">
<size width="10" height="10"/>
<pos x="+0" y="+0"/>
</define>
(later)
<visual class="square_blue_thing"/>
OR (two syntax examples)
<visual class='square_blue_thing' type="color" source="constant '+#224466'"/>
<visual class='square_blue_thing' type="color" source="constant_add '#224466'"/>
So, the final color of those visuals would be :
#0000aa (class) + #224466 (modifier) = #2244ff
This should be available especially with textzones and visuals, and would let us skinners setting some colors, BASED on others element's colors from classes. So some entire / huge parts of xml could be written with relative tones, making it far easier to maintain / modify / enhance. Basically, the main idea is : "I can do it with coordinates, so why wouldn't I be able to do it with colors ?"
Using classes / panels, It could be interesting to have some color modifiers just like relative coordinates, and be able to 'add' or 'substract' some colors from classes.
Example :
<define class="square_blue_thing" type="color" source="constant '#0000aa'" tooltip="">
<size width="10" height="10"/>
<pos x="+0" y="+0"/>
</define>
(later)
<visual class="square_blue_thing"/>
OR (two syntax examples)
<visual class='square_blue_thing' type="color" source="constant '+#224466'"/>
<visual class='square_blue_thing' type="color" source="constant_add '#224466'"/>
So, the final color of those visuals would be :
#0000aa (class) + #224466 (modifier) = #2244ff
This should be available especially with textzones and visuals, and would let us skinners setting some colors, BASED on others element's colors from classes. So some entire / huge parts of xml could be written with relative tones, making it far easier to maintain / modify / enhance. Basically, the main idea is : "I can do it with coordinates, so why wouldn't I be able to do it with colors ?"
Posté Wed 17 Dec 14 @ 6:16 am
Fruit
groovindj wrote :
my idea was to have a 'force size' or 'lock size' command.
Not a bad idea, but it would be up to the skinner to set it.
Where my solution, instead, would make an automatic recognition of those visuals, so no extra work would be needed from skinner to get it to work, and it would drastically improve existing skins instantly.
The only limitation of this is : it could only act on xml 1px sized stuffs, and not inside the png pic (which would be impossible I guess).
Posté Wed 17 Dec 14 @ 6:34 am
Fruit
Define can have multiple classdecks
IMO, this would be a HUGE implementation, saving loads of lines.
For some reasons I often have to write 4 times the exact same code. For example, have a look in my skin "v8 but by FRUiT" near line 1360 and below :
<define class="volume_level_small" classdeck="1" action="level" rightclick="temporary" orientation="vertical">
<size width="43" height="97"/>
<off x="589" y="2103"/>
<on x="1804" y="1246+60"/>
<fader>
<size width="44" height="20"/>
<pos x="917" y="1123"/>
</fader>
</define>
<define class="volume_level_small" classdeck="2" action="level" rightclick="temporary" orientation="vertical">
<define class="volume_level_small" classdeck="3" action="level" rightclick="temporary" orientation="vertical">
<define class="volume_level_small" classdeck="4" action="level" rightclick="temporary" orientation="vertical">
I copied only one class here, but the 4 classes have the exact same text/structure and I am actually forced to write the entire 4 classes, one per classdeck.
What I would like to be able to do is a coma separated list in the classdeck field, so I can attrib the same tags to the 4 classdecks at once :
<define class="volume_level_small" classdeck="1,2,3,4" action="level" rightclick="temporary" orientation="vertical">
<size width="43" height="97"/>
<off x="589" y="2103"/>
<on x="1804" y="1246+60"/>
<fader>
<size width="44" height="20"/>
<pos x="917" y="1123"/>
</fader>
</define>
Other small examples :
<define classdeck="left,1,3">
<define classdeck="right,2,4">
etc...
There are many cases where skinners could do some code reduction with this ability, and the vdj classes would be FAR more versatile and handy !
IMO, this would be a HUGE implementation, saving loads of lines.
For some reasons I often have to write 4 times the exact same code. For example, have a look in my skin "v8 but by FRUiT" near line 1360 and below :
<define class="volume_level_small" classdeck="1" action="level" rightclick="temporary" orientation="vertical">
<size width="43" height="97"/>
<off x="589" y="2103"/>
<on x="1804" y="1246+60"/>
<fader>
<size width="44" height="20"/>
<pos x="917" y="1123"/>
</fader>
</define>
<define class="volume_level_small" classdeck="2" action="level" rightclick="temporary" orientation="vertical">
<define class="volume_level_small" classdeck="3" action="level" rightclick="temporary" orientation="vertical">
<define class="volume_level_small" classdeck="4" action="level" rightclick="temporary" orientation="vertical">
I copied only one class here, but the 4 classes have the exact same text/structure and I am actually forced to write the entire 4 classes, one per classdeck.
What I would like to be able to do is a coma separated list in the classdeck field, so I can attrib the same tags to the 4 classdecks at once :
<define class="volume_level_small" classdeck="1,2,3,4" action="level" rightclick="temporary" orientation="vertical">
<size width="43" height="97"/>
<off x="589" y="2103"/>
<on x="1804" y="1246+60"/>
<fader>
<size width="44" height="20"/>
<pos x="917" y="1123"/>
</fader>
</define>
Other small examples :
<define classdeck="left,1,3">
<define classdeck="right,2,4">
etc...
There are many cases where skinners could do some code reduction with this ability, and the vdj classes would be FAR more versatile and handy !
Posté Wed 17 Dec 14 @ 6:52 am
Adion
If the definition is the same and only the deck is different, why are you using classdeck at all, and not just set the deck in the object that implements the class?
Edit: Also don't understand why it would work if the class name is the same...
Edit: Also don't understand why it would work if the class name is the same...
Posté Wed 17 Dec 14 @ 9:07 am
Fruit
Adion wrote :
If the definition is the same and only the deck is different, why are you using classdeck at all, and not just set the deck in the object that implements the class?
You should have a look at my skin, at the line I gave. The reason is, in some cases I want to have 4 instances of the same deck (let's say for instance they are grey) BUT left and right decks would have different colors / behavior. Actually I can have a classdeck for "left" but also for "1" which is not the same. I use this a lot in my skin because I merged a 4 decks layout inside a current left/right 2 decks layout.
This has to deal with 'implicit' callings.
Adion wrote :
Edit: Also don't understand why it would work if the class name is the same...
For example, some controls would show only if they belong to the specified deck. Check in my skin. This way I can refer to some classes for only some decks, and not for others.
Example with my skin and the level slider above :
If i set no classdeck, and then call this class, then the decks 'left' and 'right' would be concerned. But I want them to have a separate behavior from decks 1,2,3,4 (subdecks). But the calling process only refers to the class, not classdeck.
So now I am forced to write 6 classes :
left (blue)
right (red)
1 (gray)
2 (gray)
3 (gray)
4 (gray)
With the ability described I can set 3 classes instead of 6 :
left (blue)
right (red)
1 2 3 4 (gray)
Sorry my english limits me from some explanations. Tell me if you need more info !
Posté Wed 17 Dec 14 @ 10:27 am
Fruit
Fruit wrote :
forced to write 6 classes : [...] 3 classes instead of 6 :
Sorry I meant 6 (or 3) instances (classdecks) of the SAME class (only ONE class name called).
Please also excuse my bad english, maybe I could talk to a french teamer about this if you need. Feel free to pm me :)
Posté Wed 17 Dec 14 @ 12:12 pm
Fruit
Custom button shows its command in tooltip
It would be handy to have the currently assigned entire command to a custom button in its tooltip, regardless what the button name is (just like how a keyboard shortcut is presented when hovering a normal button).
It would be handy to have the currently assigned entire command to a custom button in its tooltip, regardless what the button name is (just like how a keyboard shortcut is presented when hovering a normal button).
Posté Sun 28 Dec 14 @ 9:48 am
locoDog
Not sure on ^that one^ fruit I've lots of long scripts on normal buttons and it looks a mess,
http://pbrd.co/1Bk9KGf
maybe the custom button name would be good (not the script, not the preset custom button number but the name the user gives the custom button)
http://pbrd.co/1Bk9KGf
maybe the custom button name would be good (not the script, not the preset custom button number but the name the user gives the custom button)
Posté Mon 29 Dec 14 @ 4:34 pm
Fruit
But... you're a kind of scripting ufo my dear loco ! In most of the cases that would not be a problem, thus it can be presented on several arranged/CRed lines (and so not looking as bad as your picture).
Posté Tue 30 Dec 14 @ 3:13 am
groovindj
Option to change text colours with variables
Now that we have the ability to set different skin colours using visuals (type="color" source="constant" etc.) it would be useful to change textzone colours based on the colour selected for the visual.
e.g. if text is black, selecting a dark visual colour would render it invisible. Text would need to be set to white.
Now that we have the ability to set different skin colours using visuals (type="color" source="constant" etc.) it would be useful to change textzone colours based on the colour selected for the visual.
e.g. if text is black, selecting a dark visual colour would render it invisible. Text would need to be set to white.
Posté Tue 30 Dec 14 @ 7:39 am
djdad
a workaround on this could be to use class defines, similar to what we have done in the 4 decks default skin.
Apparently, the author of the skin defines what colors the visual uses, so it wouldnt be hard to have textzones with visibility and different class (color) for each case (or at least for the most of them)
Apparently, the author of the skin defines what colors the visual uses, so it wouldnt be hard to have textzones with visibility and different class (color) for each case (or at least for the most of them)
Posté Mon 05 Jan 15 @ 6:19 pm
groovindj
Could you give an example?
Posté Tue 06 Jan 15 @ 8:39 am
djdad
Defines...
<define class="textcolorline1" >
<text color="#xxxxxx" /> (provide a color here)
</define>
<define class="textcolorline1" >
<text color="#yyyyyy' /> (provide a different color here)
</define>
etc.
Then you could have
<textzone class="textcolorline1" visibility="var '@$color' 0">
<size width="327-78" height="22"/>
<pos x="+10+78" y="+11+24+2"/>
<text size="20" weight="bold" scroll="yes" format="%Author"/>
</textzone>
<textzone class="textcolorline2" visibility="var '@$color' 1">
<size width="327-78" height="22"/>
<pos x="+10+78" y="+11+24+2"/>
<text size="20" weight="bold" scroll="yes" format="%Author"/>
</textzone>
Of course you need to handle the variable @$color each time you select a color for your visual
<define class="textcolorline1" >
<text color="#xxxxxx" /> (provide a color here)
</define>
<define class="textcolorline1" >
<text color="#yyyyyy' /> (provide a different color here)
</define>
etc.
Then you could have
<textzone class="textcolorline1" visibility="var '@$color' 0">
<size width="327-78" height="22"/>
<pos x="+10+78" y="+11+24+2"/>
<text size="20" weight="bold" scroll="yes" format="%Author"/>
</textzone>
<textzone class="textcolorline2" visibility="var '@$color' 1">
<size width="327-78" height="22"/>
<pos x="+10+78" y="+11+24+2"/>
<text size="20" weight="bold" scroll="yes" format="%Author"/>
</textzone>
Of course you need to handle the variable @$color each time you select a color for your visual
Posté Tue 06 Jan 15 @ 10:14 am
groovindj
I see. So you're basically having to write every textzone twice (or more). Not very convenient. :-(
It would be nice if colours of skin backgrounds, text etc. were accessible from within VDJ itself, similar to the way track colours in the browser are set. Pick a colour from a palette.
Being a fixed thing written in the skin XML is not so versatile. For example we can set colours for tracks in the browser, but not any colour scheme for the browser itself.
Maybe I would like to have a red browser. I need to modify the skin, and that would only change the browser for that one skin.
Being able to set colours and storing that info in settings.xml would allow me to set a red browser and have it carry over to any VDJ 8 skin.
It would be nice if colours of skin backgrounds, text etc. were accessible from within VDJ itself, similar to the way track colours in the browser are set. Pick a colour from a palette.
Being a fixed thing written in the skin XML is not so versatile. For example we can set colours for tracks in the browser, but not any colour scheme for the browser itself.
Maybe I would like to have a red browser. I need to modify the skin, and that would only change the browser for that one skin.
Being able to set colours and storing that info in settings.xml would allow me to set a red browser and have it carry over to any VDJ 8 skin.
Posté Tue 06 Jan 15 @ 10:53 am
music234
A parameter like loophight="hh" + pos y="yy" so we could place it wherever we want.
So it would be possible to bring the beat grids in front
ImO it's very hard to see the first beat of the pattern...
So it would be possible to bring the beat grids in front
ImO it's very hard to see the first beat of the pattern...
Posté Wed 14 Jan 15 @ 2:21 pm
Fruit
Cover type
That could be interresting to provide the skiner a rounded cover, intended to be an animation. That would avoid the use masks.
It could be choosable providing a type :
<cover type="static" rotate="yes"> <-- that would be a rotating square
<cover type="round" rotate="yes"> <-- that would be pre-rounded
That could be interresting to provide the skiner a rounded cover, intended to be an animation. That would avoid the use masks.
It could be choosable providing a type :
<cover type="static" rotate="yes"> <-- that would be a rotating square
<cover type="round" rotate="yes"> <-- that would be pre-rounded
Posté Mon 19 Jan 15 @ 2:29 pm
