Page 3 of 5

PostPosted: June 20th, 2007, 5:53 pm
by Cliff Cawley
If everyone wants a skinnable playlist, that is going to delay the release of the Component SDK as it will need support for the skinning engine. At the moment, the skinning support comes from a single component; Shimmer (the interface component).

I would have to abstract this back into the core in order to support skinning. After this I will have to add the ability to the skinning engine, to allow for tiling, stretching and resizing (As everyone wants a resizing library/playlist). Thereafter I can start rebuilding the playlist control and building a custom list control that uses the skin engine from the core. There may or may not be problems doing it this way.

To create something like Kev-O has mocked up, is going to be a nightmare using a PSD file, as far as I can tell. It really depends on how customized/skinned it needs to go. A lot of users have already expressed that using Windowblinds already allows them the level of customization that they desire, while others seem to want more out of a playlist/library.

I've had some thoughts about perhaps combining the playlist into the player skin, so that you can define a region where the list will get generated, but I haven't create a prototype yet to see how feasible it is.

Currently I do all of the skin rendering in Software. Hence the reason that users with slower CPU's will be experiencing slow skins. Xion's current bottleneck for skin rendering is being held back by CPU. For most users this isn't a problem as I've optimized it quite heavily.

I have been toying with the idea of Hardware acceleration through the use of DirectX, however I am as yet, unsure whether this will even work in the way that I need it to. I do hope to create a prototype of this in the future. I do plan on still supporting Software rendering if Xion is unable to create a DirectX surface, however these days, almost all systems should be able to create a DirectX surface.

A lot of people are requesting that Xion have a Library/Playlist similar to Foobar. They also want it skinnable. One of the reasons why Foobar can make such a powerful Library/Playlist, is that it isn't skinnable, or only supports a very simple skinnable format.

So basically it boils down to the following:

If everyone wants an awesome skinnable playlist/library/any component, then that is going to take some time before anything, including the SDK is available. (I work on this in my spare time. Xion provides no income for me and people aren't willing to pay for it, so I have no other choice).

If on the other hand, the skinnable playlist/library/any component isn't that important, then I can release the SDK in its current form and let people loose on creating custom Components.

So, after that run down, which road should I take? Feel free to ask any more questions about anything, and I'll do my best to answer them.

Cliff :)

PostPosted: June 20th, 2007, 7:40 pm
by ALAS
a skinnable library/playlist would of course be very nice, but to me it seems much more important to have it well functioning than being skinnable.

The idea of integrating it into the main skin is, well, ok, as far as the option to open it seperately (unskinned) remains.

PostPosted: June 20th, 2007, 10:35 pm
by SLoB
ALAS - probably using the same dll for it just in a seperate instance
so you could theoretically have 2 playlists unless the integrated one inherits the main pl content?

the ability to add columns on the fly with either a right click context menu would be cool, to add columns such as album, artist, ratings, etc...

PostPosted: June 21st, 2007, 12:51 am
by KEV-O
Cliff, I would assume that most of us would prefer a more functional library over a skinnable one. Definatly make it more powerful before making it more pretty.

As far as a playlist window inside of a skin, I could see how as simple version of that might work:

Image

Of course, I'm code-illiterate!
:D

PostPosted: June 21st, 2007, 2:50 am
by ALAS
SLoB- I have no idea of coding, what I think of is, 1 set of data (playlist/library) and 2 alternative ways of displaying/editing it.And if data is edited via one of them the other display is updated. Maybe I think too simple.

If that´s not possible, an alternative was to give the skinner the ability to disable the external pl/lib.

Very important , I think is, that the skinner should not be forced to decide between including a huge, monstrous, ugly playlist or omitting pl/lib completely.

PostPosted: June 21st, 2007, 3:25 am
by SLoB
agree, if and when skinnable playlists are added then it should be optional, however, if you look at the wa skins then part of the requirements is all windows skinned, not that that should be a rule for Xion ;)

PostPosted: June 21st, 2007, 10:48 pm
by eugene2k
Cliff Cawley Wrote:If everyone wants a skinnable playlist, that is going to delay the release of the Component SDK as it will need support for the skinning engine.

Well not everyone wants it :)
I beleive there are some developers among Xion supporters (I sure hope I'm not the only programmer who liked Xion a lot :)) so a Component SDK would probably speed up the development of Xion, as you as author could concentrate on Xion core and others who do have some programming knowledge could concentrate on the development of components for Xion.

Here's my 2 cents on the problems with skinning Xion components:
- If you don't allow the skin designers to put the elements of design whereever they want, than it's very much possible to just use the PSD file for the component elements. The drawback of this approach being that with each new skin the component will essentially look the same.
- If you do, the components can be designed by the skin authors themselves, however: 1. It will probably need to be done in a markup language of some sort (XML or HTML+CSS maybe).
2. You risk that somewhere along the way there will be a component for which a skin wasn't designed for and that this component will essentially brake the whole design.

So with this in mind, perhaps it would be a good idea to implement both ways, so that when a component is supported by the skin author the second approach is used and when it isn't the first is used.

P.S. I've sent you the file that crashes Xion when you load it.

PostPosted: June 22nd, 2007, 6:44 am
by Mudslung
P.S. I've sent you the file that crashes Xion when you load it.


Must be a copy of my skin!!! :D

PostPosted: June 22nd, 2007, 7:07 pm
by eugene2k
Mudslung Wrote:P.S. I've sent you the file that crashes Xion when you load it.


Must be a copy of my skin!!! :D

Nope. That one crashes Windows :lol:
Divine Comedy crashes Xion :)

PostPosted: June 23rd, 2007, 4:27 pm
by Foleor
eugene2k Wrote:Well not everyone wants it :)
I beleive there are some developers among Xion supporters (I sure hope I'm not the only programmer who liked Xion a lot :))


Nope, your not the only one ^_^. I dunno really... On the first side, an intergrated Playlist is awesome, but Component SDK is nice too!

Its hard too choose for a little scripting designer like me :p

PostPosted: June 27th, 2007, 2:36 pm
by Mudslung
Unless I missed it somewhere, I have not seen any consideration for Photoshop CS3 Extended's "ABILITY" to NOW handle animation layers. As well as it's new Ability to Import 3D content. In the scheme of things, it seems these would be Import matters of concern.

Just an Idea to consider! :shock:

PostPosted: June 27th, 2007, 5:56 pm
by SLoB
nor are you likely to in the immediate future, I believe Cliff is still using PS7?
can't keep keeping up with the Jones's ;)
still on cs1 here :)

PostPosted: June 27th, 2007, 10:01 pm
by Cliff Cawley
SLoB Wrote:nor are you likely to in the immediate future, I believe Cliff is still using PS7?
can't keep keeping up with the Jones's ;)
still on cs1 here :)


Yup, I'm still on PS7. Plus I don't have any documentation on the CS3 PSD format. I believe you now have to pay many $$$ to obtain that information, on top of buying CS3.

The last documentation I had was from my PS6 CD when they included the last file format information. Hence, Xion supports up to PS6 features, and even then, not all of them. Only what it absolutely needs.

Cliff :)

PostPosted: June 28th, 2007, 12:41 am
by Mudslung
>[email protected] wrote:
> I read on some other post somewhere that Adobe will be giving up on
> the PSD format, suggesting to use TIF, although PSD will be available
> for some time it its programs.
>
> Any truth to this? Thanks.
>
> --
> Ted

Sadly it's true, but they are offering a PSD to DNG converter so all
your files can still be read in the future.

Bill

This sure sheds new light on the future of the .PSD format. Hmm...

As for that Documentation Cliff, I will see what I can come up with if it would be of any help to you.
I take it that this "Documentation" is not included with a Retail purchase of CS3?

PostPosted: June 28th, 2007, 7:06 am
by Cliff Cawley
Mudslung Wrote:>[email protected] wrote:
> I read on some other post somewhere that Adobe will be giving up on
> the PSD format, suggesting to use TIF, although PSD will be available
> for some time it its programs.
>
> Any truth to this? Thanks.
>
> --
> Ted

Sadly it's true, but they are offering a PSD to DNG converter so all
your files can still be read in the future.

Bill

This sure sheds new light on the future of the .PSD format. Hmm...

As for that Documentation Cliff, I will see what I can come up with if it would be of any help to you.
I take it that this "Documentation" is not included with a Retail purchase of CS3?


I believe they'd moved all the SDK information out of the Retail purchase and now have a separate developers only kit available.

Cliff :)