Too many skins, too many options, too many plugins...

[Old Dog]

BTW,

On a project at work, the graphics guy gives me a single image file for a screen layout (this is the way they do it!). I have to extract the elements and create individual files for each of them. At runtime, I draw the background gradient then compose the screen programactically, element by element. (I do it the other way!)

gotta go, later

...later

Of course the design goals are different.

My point is that I do understand what you are promoting, I use it myself, I'm not against it. It simply isn't the best approach considering our goals.

When I know the difference, whenever possible, I prefer to use the better approach.

Since we are developing a tool for general use, I think it appropriate that it enforces the best approach.

I think you guys ought to make a real effort to learn the single static image technique before deciding you will not use it. In short, you don't know the difference.

[Old Dog]

I am positive to define a static graphics image located in the plugin skins directory, like the task images.
But I don't think that anybody but Old Dog will use this method to create designs.

Unfortunatly, I don't think that both ways can be supported at the same time. The base xml files must be written to draw either the single image, or to draw the individual pieces.

BTW, why and how would the base xml file know what the pieces are?

Wouldn't you need a different base xml file every time the number of elements change? Isn't that a pain?

[MixMan]

Both tecniques can co exist and must ortherwise it would be imposibble to apply a graphic design to a different XML design, without rework of the graphic static image. There are not that many static images in a design either. What images do you think of, that would be incorperated in a single static image?

Unfortunatly, I don't think that both ways can be supported at the same time. The base xml files must be written to draw either the single image, or to draw the individual pieces.

BTW, why and how would the base xml file know what the pieces are?

Wouldn't you need a different base xml file every time the number of elements change? (what a pain!)

[Old Dog]

Please correct me if I err.

Plain Jane is what you would call a baseskin, a single set of xml files. *

Groove, Rosewood, Plastic, Black Jack, PJ's Blue skin, her Mayhem skin, etc. These are equivalent to themes (only kind of because buttons are separate).

Please realize that these different themes use different numbers of static elements. Some have list backgrounds, some don't. Rosewood has decorations, the ivory carving and the bowie knife, etc.

AM is able to rotate Jane through these different themes without replacing any xml files or modifying any lines of xml code.

Note: AM does edit xml code when enabling panels and task images, but not when changing themes.

* If you have never seen Jane in the nude, I suggest you take a peek soon!

[Old Dog]

Both tecniques can co exist and must ortherwise it would be imposibble to apply a graphic design to a different XML design, without rework of the graphic static image.

Our goal is to apply many graphic designs to a single xml design.

If I read this correctly, it is the opposite--applying a single graphic design to many xml designs--which is not our goal. Please check this?

In any event, you are right, it is not always possible to apply one graphics design to different text layouts (xml designs).

There are not that many static images in a design either. What images do you think of, that would be incorperated in a single static image?

You are so right. It is such a small job, learning a new, better way of doing it simply is not a big deal.

[MixMan]

I know how AM works.....and I think you have done a great graphics work.
My approach to skinning is different....a more lazy way.
I have put in a lot of work into the Themepacks, that I will not throw away.
BaseSkin will remain, but evolve into many XML designs.

Many plugin skins just have a background, buttons, list view bar and a frame surrounding the listview.
Defining "standardising" the outer and inner measuerment of the listview image. When defiing the baseskin, this was the first thing I did, so all graphic designs would apply themself perfect to the XML design.
This is the only image the should be really well defined. I have defined a with the current image size and propotions, a 20 pixel frame that can be used for different styles on the list view border.
I adjust the image X,Y values in the XML so the image surrounds the listview perfect.
Then all Themepacks listview.png will work with that plugin.

[Old Dog]

I have put in a lot of work into the Themepacks, that I will not throw away.

We must preserve your work. I will commit to this as one of our requirements!

I have always said that AM was designed to support skins from pure XML to pure image and anywhere in between. The new system should have this attribute as well and this will be a good task to prove it.

The wheels are spinning...
it actually seems easy...
let me sleep one it...

(Alright! Now I won't have to finish MCE.)

[Fatman_do]

I think you guys ought to make a real effort to learn the single static image technique before deciding you will not use it. In short, you don't know the difference.

From my experience, with my skill set, this is not the "better" approach by declaration.

When I added a "list box" as a SkinEffect, it caused me more headaches when I was tweaking its layout position and size to match my goals than editing a x,y number in the xml.

Once I had a size that worked, fine, but when I felt it needed to be changed my troubles began. I was able to figure out how to resize the image and location after several attempts at what was obviously the wrong way to do it. Then if I wanted to change its look altogether, I had to import another source pic, resize it, locate it, go through all those steps again.

If I wanted the same screen compostion with different list boxes only, this is what I would have to do:

I may have to make 10 or so different ones for the various plugin styles.
I have to create 10 or so variants for each different list box variation I want to provide.
I have to locate and resize that new source pic in each one of those new variations.
I still have to use a separate image for those listboxes for plugins that use dynamically changing list displays. If I have to use one there, why not everywhere?

If I change that one image, the results populate instantly under a multi-image format.

A plugin author or skinner already has to work with images in the xml for buttons and they need to position their content within the screen using xml.

How is having a button image defined and located by xml any different than a list box?

I have tried it. It required me to download several graphics programs and stumble my way around them. The best ones were 30 day demos of $100+
software. All were more complex than making "25,25" be "30,30" in notepad.

To define one method as superior, please list for me all the positves you see for both methods. Then list all the negatives for both. Try as hard as possible to keep the number the same between both methods. Does that declare one a better? Not always (The fastest way to get to work is to ride a jet powered backpack. Can everyone do that?). It is a debate technique to learn how to better defend your postition by taking the side of the oppostion and arguing for it with as much vigor as your own. I can do this for both.

I am not going to spend any more time on this.

I am going back to the baseskin.xml and looking at all the xml structures and see what can be done in general that does not impact any graphical scheme. I want to poke around under the hood more. Whatever method is superior will have little impact on what I want to look at right now. The "content layer" as Old Dog states it tends to be the most challenging aspect of skinning. As you can tell, there are many ways to put graphics on the screen.

You guys hash out the graphics.

[Fatman_do]

This is the only image the should be really well defined. I have defined a with the current image size and propotions, a 20 pixel frame that can be used for different styles on the list view border.

That needed to be stated sooner. I found that out the hard way. I checked your listboxes and found some had a 10 pixel transparent boarder. I then allowed for extra to keep away from borders and I think I chose another 10. If it wasn't 10, it was close. When I first converted to BaseSkin I used 0 offset and themes looked terrible!

I want to run through Chameleon and check all other size location differences and see how that effects me. Can you think of anything else? I know I didn't allow for button positioning on the left side of the screen for plugins. I have to revisit that.

[MixMan]

Sorry for not having good documentation.
When I skin new plugins like the new Photo, Video and music Library and also Plugins, I always use the DesignerGuide ThemePack to align listboxes, buttons, listbars.
There is one SubMenu "Recording" that has a really funny skinning method, that makes it almost impossible to apply graphics packs.
Hope Sub "reskins" the Recordings....so it is more like the other Submenus logic.
There are not anymore undocumented "things" that I can think of right now.
I will keep on working on the Guideline document.

Old Dog.....do you want the static graphic image named se.png or a more describing name?

That needed to be stated sooner. I found that out the hard way. I checked your listboxes and found some had a 10 pixel transparent boarder. I then allowed for extra to keep away from borders and I think I chose another 10. If it wasn't 10, it was close. When I first converted to BaseSkin I used 0 offset and themes looked terrible!

I want to run through Chameleon and check all other size location differences and see how that effects me. Can you think of anything else? I know I didn't allow for button positioning on the left side of the screen for plugins. I have to revisit that.