Xion 1.0 build 112 Beta Release

[Jikaru]

Well you see...The skin I just uploaded for your viewing pleasure is the one I was trying to skin, either resizable or not I do not care, personally it's easier to skin without resizing because of all the borders and trying to figure out how to order them and so on...yea it's pretty rough.
Xionidus v1.0

I was trying to figure out how to skin that playlist and I just gave up...

What I think would be easier is just having four layers tr, tl, bl, br and either four or two more layers that would define the two/four areas that will fill in the middle parts in between the tr, tl ,bl, br.

The way Xion would determine what defines what would resize it would just simply be the tr, tl, br, bl corners of the skin (not defined by layers but simply by the skins outer most corners). That's is about as easy as it gets but would require you to delay sadly. Your thoughts?

[Edit:] The reason why I waited to discuss the ease of making the playlist is because first I wanted you to have a working skinnable playlist to play with, I just happened to notice it gets tedious figuring out how to place the borders and such so I figured I'd bring up trying to make it easier.

[Cliff Cawley]

What I think would be easier is just having four layers tr, tl, bl, br and either four or two more layers that would define the two/four areas that will fill in the middle parts in between the tr, tl ,bl, br.

The way Xion would determine what defines what would resize it would just simply be the tr, tl, br, bl corners of the skin (not defined by layers but simply by the skins outer most corners). That's is about as easy as it gets but would require you to delay sadly. Your thoughts?

Umm, this is what Xion currently does You define the corners and then the fill bits. The edges are used so that you can have tiling, but they don't act as resizeable edges, only borders do that.

borderX = the resizeable border. The part you can click and drag to resize.
edgeX = a decoration piece. Can be placed anywhere and can be combined with 'tile'.

You also don't need to manually set the anchor points. Xion will intelligently guess what they should be. If you need to force them then you can add extra ones.

What I mean by this, is that if you place a layer in bottom right of the skin, Xion will automatically add anchorbr to that layer on load, just because it was in the bottom right of the skin.

If you have a layer that is perfectly centered in the skin, then Xion will automatically add the appropriate anchors to make it always centered in the skin.

Try it, create the close button and put in the bottom right of the playlist skin. Now when you resize you'll see that Xion keeps it aligned correctly. If you move it to the bottom left you'll see that now Xion just automatically compensates and keeps it in the bottom left.

Cliff

[Cliff Cawley]

I've also fixed the issue with the strange alignment of the playlist in your previous skin Jikaru.

It had nothing to do with missing parts or no scrollbar, etc it was just some old alignment code that was only active on the playlist and only exhibited the problem because you had perfectly placed the pl_list object in the center of the skin with equal distance on either side.

All fixed in build 113

Cliff

[Jikaru]

What I think would be easier is just having four layers tr, tl, bl, br and either four or two more layers that would define the two/four areas that will fill in the middle parts in between the tr, tl ,bl, br.

The way Xion would determine what defines what would resize it would just simply be the tr, tl, br, bl corners of the skin (not defined by layers but simply by the skins outer most corners). That's is about as easy as it gets but would require you to delay sadly. Your thoughts?

Umm, this is what Xion currently does You define the corners and then the fill bits. The edges are used so that you can have tiling, but they don't act as resizeable edges, only borders do that.

borderX = the resizeable border. The part you can click and drag to resize.
edgeX = a decoration piece. Can be placed anywhere and can be combined with 'tile'.

You also don't need to manually set the anchor points. Xion will intelligently guess what they should be. If you need to force them then you can add extra ones.

What I mean by this, is that if you place a layer in bottom right of the skin, Xion will automatically add anchorbr to that layer on load, just because it was in the bottom right of the skin.

If you have a layer that is perfectly centered in the skin, then Xion will automatically add the appropriate anchors to make it always centered in the skin.

Try it, create the close button and put in the bottom right of the playlist skin. Now when you resize you'll see that Xion keeps it aligned correctly. If you move it to the bottom left you'll see that now Xion just automatically compensates and keeps it in the bottom left.

Cliff

Cool, but not exactly what I was proposing. I was actually thinking, eliminate the borderX completely, OR leaving it but Xion will determine to use the outer most edges (again by the skin only and not determined by layers) for resizing.

This means this preview (included a psd if you wanted to see layer names):

Alpha Playlist Layout Psd

Without borders would resize properly, cutting the filesizes and tediousness of making a playlist, also helps to define the actual stretching/duplicated area.

Edit: I was also thinking, that if you left out any of the tile areas in the psd that xion would just not resize in that direction, for instance:

If you left out the left one or the right one or both xion would only resize vertically and vice versa with the top tiles would only resize horizontally, and of course leaving all of them out would not resize.
I think this would efficiently erradicate the need for confusing borders/edges and be an easier way to sort where everything goes, and you could keep extra designs to the way you control snapping now.

Also In Xionidus 1.0 the skin I provided at the top of this page when you resize you'll notice the control buttons get split which is not what was intended. I cannot figure out how to get those to stay in the center of the skin...

[SLoB]

Not looked yet but is the playlist scrollbar skinnable yet?

Oooo.... approaching the 1000 post mark

[Jikaru]

Yes the scrollbar is skinnable.

[Cliff Cawley]

Not looked yet but is the playlist scrollbar skinnable yet?

Oooo.... approaching the 1000 post mark

SloB! Where have you been? The entire playlist is skinnable now! Including Alpha and the ability to place layers over the top of the playlist!

Cliff

[Cliff Cawley]

Cool, but not exactly what I was proposing. I was actually thinking, eliminate the borderX completely, OR leaving it but Xion will determine to use the outer most edges (again by the skin only and not determined by layers) for resizing.

This means this preview (included a psd if you wanted to see layer names):

Jikaru,

What you have here is exactly what Xion does already. Instead of 'edge' the keyword to use is 'border'. If what you're proposing, is to not use keywords at all, and just let Xion determine how close something is to the edge of a skin in order to transform it into a 'border', then no, this is not a good idea.

One thing I can think of that would break that is adding shadows. Xion would allow you to resize on the shadow as its closest to the edge, this would not look so nice.

Without borders would resize properly, cutting the filesizes and tediousness of making a playlist, also helps to define the actual stretching/duplicated area.

As above, 'border' is the keyword instead if 'edge'

Perhaps the confusion comes from the differences between 'edge' and 'border'

'border' is used to define the resizeable parts. 'edge' is used to setup a tileable area that is constricted to a direction. So edgel means it will tile along the left side, from top to bottom. You don't need to add any 'edge' layers to your skin at all if you don't need them! Perhaps 'edge' is a bad name for it. I used it to make edges in the default skin, so it made sense there.

Edit: I was also thinking, that if you left out any of the tile areas in the psd that xion would just not resize in that direction, for instance:

If you left out the left one or the right one or both xion would only resize vertically and vice versa with the top tiles would only resize horizontally, and of course leaving all of them out would not resize.
I think this would efficiently erradicate the need for confusing borders/edges and be an easier way to sort where everything goes, and you could keep extra designs to the way you control snapping now.

It already does this. If you leave out a certain 'border' keyword then you won't be able to resize in that direction. If you don't use 'border' at all, you won't be able to resize the playlist.

Also In Xionidus 1.0 the skin I provided at the top of this page when you resize you'll notice the control buttons get split which is not what was intended. I cannot figure out how to get those to stay in the center of the skin...

Ok first of all you've build the skin in a fixed format instead of allowing Xion to know what it should tile and move around.

The first thing you need to do is break up the 'background moveable' layer in the same way that you made the 'alpha psd'. You'll also need to split up the 'moveable' layer.

Optimization tip: Your 'moveable' layer has a LOT of wasted pixels. Photoshop will save your layer as 280x309 pixels. If you split the highlights into two, Photoshop will save them as 2x(28x309). That's a saving of 224x309 pixels, or 276864 bytes of memory, and less for Xion to draw!

I'll need to look into the 'centering' of the controls. Normally to center something I would add 'anchorbl anchorbr' so that I tell Xion where to anchor (on the bottom), instead of letting it guess. However it looks like a bug in that all buttons will now be perfectly centered instead of offset slightly, so I'll look into that one.

I took about 15 minutes to modify your skin: http://xion.r2.com.au/temp/Xionidus_pla ... iffmod.zip

So now it resizes perfectly, instead of requiring the user to resize it to the smallest possible and using it like that. It also uses less memory and less disk space. In build 112 you'll still have the issue with the playlist list offsetting itself strangely, just resize then hit F5. (This is fixed in build 113).

Take a look at the skin now and you'll see its been split up. I've used 'border' pieces to determine where the user is allowed to resize and I've used 'edge' pieces to fill parts that I want as a border, but I don't want the user to resize. (perhaps 'edge' should be renamed to 'fill')

NOTE: I left the 'left' and 'right' borders as a large area to show you what will happen. Try and resize horizontally and you will see that you can do so, on a VERY large area. Now look at the 'top' and 'bottom' border sections and you'll see that I split them up so that they're smaller areas to resize by and I used 'edge' layers with 'moveable' in order to allow the user to move the skin around with those.

I also modified the 'border' corners and just created some moveable layers as I didn't want the user to have a massive resizeable area on those either.

Cliff

[Jikaru]

Thanks cliff I'll look at it when I get home and have time.
I guess I just need more time dealing with special circumstances and the way the playlist engine works. I haven't had a whole lot of time to skin lately school tends to dump a few projects on at a time.

[Dilinger]

Cliff, can you take a look of the animated indicators. On the last frame they don't hide, just fade out around 50 %.

"animation indi_stereo animtype(1) delay(2)"

[SLoB]

Hah been busy with other things

Had been kind of tracking the playlist, but last time I looked specifically for the scrollbar it was still winblows style must have missed it in my scanning heheh

cool stuff

[Jikaru]

The cliffmod is good but the resize (border layers) are huge. I was proposing that Xion would just use the edge of the skin to resize, and you said well what about the drop shadow if someone were to apply something they didn't want to react to the resize...well you can create a keyword to dismiss a layer from triggering the resize and Xion can choose to use a set of pixels lower on a hierarchy.

So say you did the playlist like I proposed using border instead of edge, then you can eliminate the need for the "edge" keyword instead. Either way I don't feel the need to have the two of them if Xion can determine a border and dismiss a layer if specified to, so here's an update of the alpha psd with my idea of how it could work:
Alpha PSD v2.psd
anything with !resize on it will not be considered by Xion to be a border.

Edit: Also something that I noticed that persists even today is when you make a visualization have "indi_active" or "indi_inactive" it doesn't completely disappear when it supposedly "hidden" it just kinda pulses in and out and continues it's thing...any chance that could be fixed?

[SLoB]

hmm is the passthrough keyword borked for playlist then? Surely that would eliminate the issue of the drop shadow being selectable?

[WinstonGFX]

Having both margin and border is useful if you have a really complicated PL design.

[Jikaru]

Winston the point is, you can still have a complicated design, but it would eliminate having to do "edges" Just have everything in a few less layers and you have the same effect.

And SLoB thats a great idea, passthrough would work perfectly in this scenario, I just want to see Cliff's opinion on this setup. I think it is a great way to do the playlist, and not much has to be changed....