Appearance Manager

[KingArgyle]

Old Dog:

Thought I'd bring this over to the developer's forum for discussion. You mentioned that it would be necessary for skins to use a common set of names in order to work with the Appearance manager. If you can specify what the Appearance Manager is looking for, I might be able to create some XSLT's that can be used to convert a Skin.xml file to the comptaible format.

Just need to know what the program is looking for in a skin to make it comptabile.

[dottore]

i would suggest a documentation, since i really would like to add the appearance-thing to my skins.

i also would like to have an option to switch between different menu-styles: horizontal and vertical....wouldn't that be cool?

[Old Dog]

Sorry guys, I just noticed this thread and I'm at work now.

I'll get back tonight.

-David

[MixMan]

Regarding the Apperance Manager

Hi, Here are some thoughts that I have.
I think this is something Sub should be involved in this for the new ”BaseSkin”.
As I understand it Sub is changing the “skinning engine” and that the new features allows “global changing” of appearance parameters. Most skins does not differ that much, so an “appearance manager could change images and parameters in the “BaseSkin.xml” and changes would become “global”

What I miss in the most skins, are that button are not wide enough, so other languages/translations does not fit in the buttons. The German words is about 30% more text than English, so the translations usually don’t fit. Keep this in mind when designing skins.

I think that we should work with Sub to “standardize” image names and locations for images, so the “appearance changer” applies to all skins.
I think that the new “BaseSkin” should have “defined areas” for presenting the GUI objects.

MainMenu Button Area
Titel Area
Button Information Area
Panel Information Area
SubMenu Button Areas
File Area


Menu Objects to be defined ….that could be changed in skins.

Main Menu Objects
MainMenu Buttons Images
MainMenu Button Text
Background Image
Task Image
Small Task Image (shown on the button)
Language/Translation

Sub Menus Objects
Background Image
SubMenu Buttons Images
SubMenu Button Text
Confirmation Button Images



I also think a Plugin Development “framework kit” should be defined. Not many plugins works directly when installed.
# Plugin GUI framework/template
# Skin.XML file
# KeyMapping XML file
# Language.XML file (for strings and translation)
# Plugin Installer (perhaps base on WinRar.)
# Documentation template for the Wiki.

[sub]

MixMan is right. I'm getting tired of seeing plugins and skins that dont work.

I've started working on a document that defines standards for how most things need to work, including

- standard names for the various types of buttons, and backgrounds, so that a simple change to BaseSkin.xml changes the look for the entire application
- how the skinhelper should be used so that caching works as expected
- how to get temporary bitmaps so that we can reduce the number of very large 720x480x4 bitmaps we currently have hanging around, reducing memory waste.
- how to use the Inset window
- how to make sure strings are translateable.
- how to make sure the keymappings are configurable.
- use of the ISettings interface

I'll hopefully get this document finished over my Christmas break, and have something to publish early January. This will give you a chance for any feedback before the next public release.

I started some of this work in the last release, introducing the new BaseSkin.xml. I also added new ISettings interface that plugins will need to implement. The ISettings.Reload() method will be used to tell plugins to reload their settings, allowing for dynamic skin changes without restarting the application etc.

[dottore]

sounds good! that's actually what we needed...

[Old Dog]

Sub has identified some areas that he knows require improvement--he knows what he talking about. Of course his plan is good. On the other hand, they are only peripherally related to appearance manager.

With regard to an appearance manager, before we come up with solutions, we should identify the issues. I'll come back to this later because the most important thing is...

We must not do anthing that would constrain or stifle future creativity or innovation. The best solution in this initial attempt will probably be to stick to the simplest solution.

Back to the issues...

We need to address appearance on at least two different levels. First we need to provide an improved environment for the skin designer while minimizing the effort for sub and the plugin developers. The solutions in this area will of course influence the design of an actual apperance manager.

In thinking about the needs of the appearance manager, we must first assume that the skin desinger has done a good job. All the appearance manger need address is custimization for the end user, by the end user. How much custimization is of course the question.

The current appearance manager only addresses the "look". It allows the the skin to morph into something more appealing to the end user. That is all. It does not address usability issues "I can't read that because the text is too small" or because there's not enough contast, etc. Someday it should, but even to take this next small step requires coordination between the user's needs, the skin designer's needs, and the effort required by both the plugin creators and sub.

I believe the baseskin.xml file will play an important role in this effort. Having thought about these various needs for past few weeks, one "solution" that might help would be a small matrix of editable named colors the can be used by the individual skin files. Manipulating the color entries could be used to taylor the look and also to address text foreground/background contrast problems. This is only one small solution, but right now, GBPVR cannot support it. Skinners, pluggers, and sub would all have to do something. That's alot to ask.


I think this is the longest post I have ever written.

Regards,
David

[Old Dog]

Old Dog:

Thought I'd bring this over to the developer's forum for discussion. You mentioned that it would be necessary for skins to use a common set of names in order to work with the Appearance manager. If you can specify what the Appearance Manager is looking for, I might be able to create some XSLT's that can be used to convert a Skin.xml file to the comptaible format.

Just need to know what the program is looking for in a skin to make it comptabile.

I will simply describe what exists. I'll use "Collection" but it could just as well be "TheSkin".

The Collection uses .png files for buttons. There are three sizes of buttons, one for the main menu, one for plugin menus, and one for popup dialogs. For each there is a normal image and a selected image. Thats six button image files

The Collection uses two background .jpg files. One for the main menu (MainBackground.jpg), the other for all of the plugins(Background.jpg).

Skin effects allow the user to switch from say a plastic look, to marble , or brushed metal, etc. Skin effects are drawn right on top of the background within <CompositeImage name="Background"...

The Collection only uses skin effects on the main menu but they could be used with any plugin.

The collection uses a single .png for main menu skin effects(se.png). Graphical elements within a skin effect come in two transparency levels, some transparency or no transparency. Those with some transparecy are based on white, but use black for shading and gradients. They will adopt their presentation color from the background, whiter areas being a lighter shade, blacker areas a darker shade. Opaque (no transparency) elements block the background completly and present their own colors (I haven't created any colorful effects).

Some effects have variations in different files (but only one is used). Brushed metal is a good example, one of the files has some transparency so when placed on say a blue background the effect is metalic blue. The other is fully opaque and is useful with wallpaper (The Enterprise) to frame the central element of the scene and completly block the periphery.

There are two other .png files. Both are full screen, 720x480 and parially transparent. One is bascally white, the other basically black. Right now, I think I only use the Darker.png, scaled down and placed behind the program portion of the TV Guide to improve contrast. This was done before Appearance Manager and may even conflict with it.

All of these files are kept in the "Collection" directory and all of my skin.xml files know the names of the files that they use.

The Appearance Manager knows the names "MainBackground.jpg", "Background.jpg", "MainButtonNormal.png", "MainButtonSelected.png", and "se.png".

More later...

[reven]

about images, to remove them from memory all you can do is

Code:

image.Dispose();
image = nulll;

right? is there anything else, i use the

Code:

using(Image temp = blahblahblah){
}

as much as i can, since it automatically cleans up the object you are using once its finished. but if thats all i know to release resources, if there are any other tips/tricks i dont know about can someone post them. well other than calling GC.collect() every second

[sub]

about images, to remove them from memory all you can do is

Code:

image.Dispose();
image = nulll;

right? is there anything else, i use the

Code:

using(Image temp = blahblahblah){
}

as much as i can, since it automatically cleans up the object you are using once its finished. but if thats all i know to release resources, if there are any other tips/tricks i dont know about can someone post them. well other than calling GC.collect() every second

Is this in response to me mentioning temporary bitmaps above? If so, I'll write something over the christmas break to give you some more pointers, but in general since these are usually large and consume alot of memory, we typically dont want be creating and destroying them all the time, but we also dont want every plugin caching one or more of these large suckers.

As solution, you'll notice there is a SkinHelper.GetTemporaryBitmap() method which can be used to give you a cached bitmap. The idea is you'd call this during your plugin's Render() method, and return the image at the end of the method. You dont need dispose of the image or anything. It'll automatically be reused next time someone Render()s.

Dont call GC.collect to force garbage collection. Its not recommended, and can really hurt performance.