GBPVRSkinTools alpha

[gruskada]

Wow, there's a ton of complexity to the skin XML files! I'm wireframing like crazy to try and best manage it all. It may actually be a few days before I'm able to post anything, but when I do, I'll post a whole shell application (all the UI, none of the code) for people to play around with.

gruskada

[McBainUK]

I'm wireframing like crazy to try and best manage it all.

Sorry for my ignorance but what is a wireframe? Is it kind off a dummy app? As in you can click buttons and other UI elements which appear to do things (open windows etc) but there is no functionality behind it?

Wow, there's a ton of complexity to the skin XML files! I'm wireframing like crazy to try and best manage it all.

There seem to be 3 main parts to them: Special Elements (SE), Composite Image (CI) and what I call compsoite elements (CE). Also most skin files have defined textstyles and color constants.

• The SE defines the position of the element on the background (and in the case of list boxes some extra info - spacing).
  
• In the plugin each SE is kind of mapped to one or more CI. The CI define the name and size of the overall image.
  
• In turn each composite image is made up of CE (eg DrawText, DrawRoundedRect)

[McBainUK]

Looking forward to the wireframe, seems like you've done it before

Think I will continue to work on the skin classes I outlined above. My idea is that these will form the basis of the skin data inside the program. These will be "rendered" to make the preview image (as they do in the demo above). And "exported" to make skin.xml files. Does this seem right?

[McBainUK]

Also in the same style as Photoshop, we could have "layers", so you could easily arrange the z-index of each object.

This would need to be done in the preview, but when the skin is in use the z-order is determined by the plugin (ie which element is rendered 1st - the last is the top most)

[gruskada]

You've probably figured it out, but I'm describing a wireframe as a mockup of the application - not the exact correct usage of the term.

My dummy app now includes an Asset View, which includes pre-built assets like "Clock" and "Recording Soon", as well as letting you add assets yourself (images, text styles, composite images, etc.). It also includes a hierarchal tree view of the skin, with each folder mapping to a physical folder, and each containing physical assets (i.e. skin.xml files, images), and for lack of a better word, virtual assets (text styles, composite images, etc.) that will be merged into the XML file when the XML is exported. The design is meant to be flexible though, so you could have a "Resources" folder that contained all the images, that you could drag onto the visualization of the XML file, and it would make the appropriate reference in the XML file, and represent it in the heirarhy.

Here's an example (not using the actual elements of the Olbia skin):


Oblia
|--Main Menu [w/ folder icon]
| |--skin.xml [w/ xml icon]
| | |--SmallMenuText [w/ text style icon]
| | |--BigMenuText [w/ text style icon]
| | |--main_menu.png [w/ image icon]
| | |--bottom_border.png [w/ image icon and shortcut icon]
| | |--Button [w/ composite image icon]


Clicking once on any of these would highlight all instances of the object in the WYSIWYG view. Doubleclicking would open the object up for editing (ideally, you'd be able to choose what program handles each type (i.e. Photoshop for images, internal (this app) for composite images, etc.)

I'm on the fence as to whether or not to include text styles and colors in this view - my initial thought was to have a Microsoft Word-like interface for these - you could view all styles globally, and then have a dropdown menu in a top toolbar that would show all available styles / colors.

Anyway, this is a very rough draft. As soon as I figure out how to restore my GBPVR app on my desktop (it works with the MVP, but not on the desktop), I'll work on a test skin to try and get more insight into how this should work.

Your composite rending code looks about right, and will be useful for preview --> XML. I'm hoping we can use Sub's rendering code for the actual XML --> visual preview so that skinners could be sure that how it looks in SkinTools is how it will look in GBPVR (though I'm not sure if these methods are exposed or not - I'll look into this tonight), but maybe this isn't necessary, and there may be a benefit to having the same set of methods handle both.

(sorry for all the edits to this post - I think I'm done now)

gruskada

[McBainUK]

I think the way to go would be to extend the GBPVR Widget Library.

I looked at the source code of the Widget Libary to see how he did a few things and found that the widgets arnt skinable, widget render and images are handled inside the plugin code. Quick search on the forum confirmed it.

I've made a 'GBPVRUIElements' dll that is used by the files plugin. This handles the display, scrolling, and user input on the menu buttons, filter and favorites popup lists, and the file lists itself. Posted a preview of it here, not ready for public release tho. I made it because it was taking 10mins to add a button, and over a hour to add another File pane! This also involved copy and pasting code which was a nightmare. Using the fileList class in GBPVRUIElements.dll I can just declare 2 objects, fileListA and fileListB.

The dll provides support for buttons and button lists, object lists, labels, and file lists. Will think about developing it further and realeasing it for public use if there is interest?

[McBainUK]

gruskada In respect to the skin tools app, we cannot rely on a plugin or GBPVR being widget based.

How is the wireframing going?

[McBainUK]

My dummy app now includes an Asset View, which includes pre-built assets like "Clock" and "Recording Soon", as well as letting you add assets yourself (images, text styles, composite images, etc.). It also includes a hierarchal tree view of the skin, with each folder mapping to a physical folder, and each containing physical assets (i.e. skin.xml files, images), and for lack of a better word, virtual assets (text styles, composite images, etc.) that will be merged into the XML file when the XML is exported. The design is meant to be flexible though, so you could have a "Resources" folder that contained all the images, that you could drag onto the visualization of the XML file, and it would make the appropriate reference in the XML file, and represent it in the heirarhy.

This sounds good, along the lines of what I was thinking. Post on here with a demo when you're ready, be good to see it in action.

Your composite rending code looks about right, and will be useful for preview --> XML. I'm hoping we can use Sub's rendering code for the actual XML --> visual preview so that skinners could be sure that how it looks in SkinTools is how it will look in GBPVR (though I'm not sure if these methods are exposed or not - I'll look into this tonight).

I've been thinking this also, dont know how public this is tho.

edit
Looking again could use this skinHelper.getNamedImage("imagename", args); Don't know why I didnt think of it before. I think the classes will still be useful as they could do the write to xml stuff.

If you can get the wireframe out can see better how things would fit together Any chance of a preview screen grab?

[gruskada]

gruskada In respect to the skin tools app, we cannot rely on a plugin or GBPVR being widget based.

How is the wireframing going?

That's true. I guess one way to approach it might be to make the SkinTools app flexible enough so that plugin developers can somehow add support for their own plugins? Like having the ability to add a plugin plugin to the app :-)

I'll pick up the wireframing again tonight. I'll email/PM you a preview as soon as I get home (~6:30pm EST) (I don't want to post it publicly yet, as I think I'll want to change quite a few things.)

gruskada

[McBainUK]

Ok 6.30 EST is about 2am here.

Just a question, have you thought about <SpecialElements> in the skin files? These determine the location of elements (composite images). This could be a problem in previewing how the GBPVR screen/plugin will look because the code determines what elements are used. Only the plugin would know which images are used for a particluar specialelement. Also, list boxe elements are made up of multiple images!


Also the WYSIWYG preview would only be able to show all the comosite images, it wouldnt be able to simualte the running GBPVR, eg popup boxes showing and hiding, menus being scrolled, lists filled with data...
You could have an option to hide/show elements in the preview - abit like 'layers' in photoshop