As MC has evolved, a lot of effort has been put into trying to ensure the Wiki reflects the changes made to the software via modifications to the existing functionality and/or new features/options that have been added/implemented.
This is my attempt at collecting together things like the Skinning Tutorial, the Skinning SDK, the 2 Matrix Drawing Methods, the Submission Process and any other useful information that I can easily find into one place.
Another aspect is to find and implement methods, ways of working, that would increase the efficiency of the MC Skinning Engine via a reduced load on the users OS, CPU, GPU and the MC Skinning Engine.
Stage 1 was to extend the main.xml layout used by the ET Family of Skins to provide a layout that contained every Skinning Function and Section a Skin Creator can use/alter when creating, or modifying, a skin.
That “Uniform main.xml layout” is arranged in a better logical order; for example, the parts covering the Main MC UI are arranged based on a working from the outside to the inside, top to bottom and left to right sequence. That same sequence is also applied to the instructions within each section.
In addition, each Section and Instruction had to be annotated if and when information about each Section and Instructions Purpose was available; to allow the Skins that used the uniform main.xml layout to become part of the Documentation Set.
Stage 2 was to “convert” every “MC Stock Skin” from their existing main.xml layout to the main.xml layout and at the same time:
Remove any code sections, instructions and images that were known to be unnecessary, obsolete or redundant.
Convert any/all images that were not in png format to png format
To remove any/all occurrences of the use of Hex Code FF00FF, that was used to indicate Transparent areas in bmp and gif images, from all images either before their conversion to png format; or because it had been left in the image when originally converted to png format.
If the skin had originally been written when MC was only available on the Windows Platform and had not been modified for the other platforms, like Aruba; I added the relevant code and images need to the MainFrame and Frame sections to allow the skin to use the Windows Control Buttons (Close, Minimize, Maximize/Restore Buttons) for the platform being used.
Once they were all “converted” I then went back through the main.xml for each skin looking for any instances of the use of “Different Names” in the same instruction in individual skins to be able to determine if those “Different Names” were referring to the same thing or not. For example, in the List Section “Current” and “HotText” are “Alternative Names” for the same part of a skin and not references to separate parts of it.
Some of the benefits the “Uniform main.xml layout” provides.
For the skin creator/modifier –
Since there is no redundant/obsolete/unnecessary instructions/code in the main.xml you are not going to waste any of your precious time changing or modifying something that will never appear on anybody’s screen/monitor. Nor are you running the risk of changing something in one of those areas that can have unexpected consequences in one of the sections that you can change/modify.
The annotations/comments are there to help you identify sections and instructions. For example, when a <Colors …. /> instruction is used the Code reveals what “individual colors” are being set for that skin; the comments inform you what those individual setting gets applied to plus all the other settings that can be used in that instruction.
Because the main.xml files for every skin that uses the Uniform main.xml layout are in the same order comparing specific instructions with those from other skins becomes easier.
For everybody –
Smaller skin folder sizes, the amount of disc space taken up by bmp images along with that taken up by images the skin is never going to use is a lot bigger than that taken up by a skin that only contains the png images it is going to use.
A reduction in the CPU and GPU Load
If the main.xml is in the order that Skinning Engine, hopefully, expects/uses it reduces the amount of time taken to get it into the relevant order.
An image in png format is going to load faster than one in bmp format of the same size in pixels and if that png image has transparent areas in it is certainly going to be loaded and rendered a lot faster than one where the Skinning Engine is going to have to convert that texture used to indicate transparency into colour/texture free areas.
One example of the unnecessary code I removed were any instructions that were telling MC to use a Bitmap that had an Image Name that was not the name of an image in the skin folder. If that instruction is in the main.xml file the Skinning Engine, or the OS, will go looking for that image and fail to find it. But if the instruction isn’t there no time gets wasted.
Unless you have been hiding under a rock for the last couple of months you are probably already aware that Stage 2 has been successfully completed.
Once Matt found out what I’d been doing and was convinced that I had not made changes that would affect the look/feel and operation of any of the “MC Stock Skins” as of MC 33.0.63 they are now all using the correct uniform layout main.xml files on every platform.
I had hoped that I was now at a point where I could start to create the new skinning guide, downloading and examining the main.xml file of some of the Skins available from the MC Skins Download Page revealed that not only did I not have enough examples/information some of the annotations/comments in the existing uniform layout main.xml files was either incomplete and/or, in a few instances, wrong.
Stage 3 – Converting the xml file for every skin available from the MC Skins Download Page that was Created by someone who is not currently active in MC into versions that use uniform layout main.xml files.
This used exactly the same methods used when converting the “MC Stock Skins” with a couple of additional changes that Matt gave me permission to carry out. The correction of any Lack of Contrast Problems, typically the use of dark colored text on a dark background or light colored text on a light background. Including in a couple of instances adding the relevant <Colors …. > instruction in the <TAGWINDOW> section to correct lack of contrast problems in the Advanced Tag Window of skins that were created long before the Advanced Tag Window was introduced.
If and when I encountered a skin that did not include a <SPLITVIEWTAB> section but did have a, now obsolete, <CUSTOMTAB> section because both sections used identical instructions, I was allowed to use those instructions to Add a <SPLITVIEWTAB> section to skins that previously did not have one; instead of forcing those skins to use the default <SPLITVIEWTAB> section.
NOTE – Whilst the older MC Stock Skins had undergone occasional updates to include any New Major changes/options/features as and when they occurred. This was not true of many of the skins available from the MC Skins Download Page; consequently, the converted versions of those skins, other than because of the 2 exceptions mentioned above, when installed in MC will have an identical look, feel and presentation style to the original versions in most versions of MC higher than the version of MC that was current when the skin was created or a section or instruction in it was discontinued.
Of the 65 skins available on the MC Skins Download Page:-
“Black and Blue” and “The Fly” were created by Marko and “Dream in Blue” was created by HPBME both of whom are currently very active members of the MC Community so they have not been converted.
DJ_Hazelwood’s “NightLife Mega” skin appears to held on a web-page that no longer exists so I was unable to download it.
Every “Maverick07” skin is currently held on DeviantArt and you have to join DeviantArt to be able to download them and you have to manually install them. The download of his “FusionX3” contained 2 Skins – FusionX3 and FusionX3 - Blue and the download of his “MetroX” didn’t contain a skin named “MetroX” but did contain skins named – MetroX - Win 8 - Default (Cyan), MetroX - Win 8 - Default (Zune), MetroX - Win 10 - Modern (Cyan), MetroX - Win 10 - Modern (Gold), MetroX - Win 10 - Modern (Green) and A MetroX - Win 10 - Modern (Pink).
During the conversion process I spotted that the Carbon, Minimal and No.4 Skins contained sufficient “alternative” images to justify the creation of 2 versions of each of them, one that used the images named in the relevant parts of the main.xml and a second version that uses the relevant “alternative” images.
N.B. The folders for each variant of a skin only contain the images that variant uses.
Since both the MC Stock Skins and the Skins available from the MC Skins Download Page, sometimes referred to as “Site-Skins”, form a large part of MC Heritage. Matt has already told me that, once I’ve completed any work I need to do to those Site-Skins the “Converted Versions” will replace the Existing Versions on the Skins Download Page and for the very 1st time they will all be installable from within MC.
Stage 3 – The one I’m currently working involves working section by section and instruction by instruction of the 84 “Converted Skins” installed on my PC; doing things like checking to see what happens if I use a Plain Red Image or Color in that instruction or what happens if I change the numbers in instructions that use numeric values. To identify the real purpose of those instructions and any unnecessary or redundant instructions and any corrections/additions needed to the annotation’s/comments.
Because I’m using 84 skins to test/prove individual instructions and settings I am now in a position where I can start to compile the JRiver MediaCenter Guide to Standard View Skinning.
NOTE – In this stage I am only checking what using a red image or color, or changing the values/numbers for other instructions has in the section I am checking and any other part of the skin mentioned in the existing annotation’s/comments.
Stage 4 – This one may take a while to complete because I will be trying to identify every place in a main.xml where changing an instruction causes a change, or changes, in other parts of the skin. To determine where that “unexpected” change has occurred and what has been changed.
Hopefully, and this is the thing that may take some time to prove, I will be able to discover that some or most of the “unexpected changes” can be prevented by adding a suitable instruction in the area/part the skin creator didn’t want that change to happen.
Stage 5 – Collect everything together so that I can compile the definitive version of JRiver MediaCenter Guide to Standard View Skinning.
Stage 6 – Liaise with Bob to enable the Converted “Site-Skins” versions to replace the original versions on the Skins Download Page.
And with Matt for the current versions of the “Stock Skins” to be replaced with the versions that have had their annotation’s/comments corrected/expanded, if he deems it necessary.
Stage 7 – Revert MC on my Windows and Mac computers back to being a source of entertainment and take a well-earned break from scrolling backwards and forwards through multiple main.xml files.
------------------------------------------------------------------------
What This is Not About.Whilst one of the aims is to get the MC Skinning Engine running more efficiently it is definitely NOT about making any changes to the way it works. Or as Matt once put it in an email
“Does all this skinning work have you cooking a list of suggested changes, or are you just reasonably happy with the engine?”
The approach I am taking, and will continue to take, is “The Skinning Engine Works” the concepts/ideas/principles embodied in are designed to help it work more efficiently. So, I can see no reason to change the way it works based on the whims and desires of a single person.
I would like to have more control over every aspect of Standard View Skin Creation.
Some of those problems caused by what could be called “Inter-Linking” changing something in one section of a skin causing a, usually unexpected, change in another part of the skin are down to the lack of adequate documentation because they can be avoided by deploying a suitable instruction in the part of the skin that the skin creator didn’t want that change to happen.
My ideal would be a Skinning Engine that didn’t do things that I would prefer it not to do. But as someone who spent 40 years of their working life designing, creating and testing software, including some that used a skinning engine, I am well aware that a change to a program that the user thinks is a very simple one can end up having some very unexpected, and disastrous, consequences especially if it’s a skinning engine that is being changed/amended.
------------------------------------------------------------------------
What this thread/topic is for.To keep everybody informed of my progress and since it may contain information that could be relevant/important to any skin anyone is creating or modifying access the current, but incomplete, PDF version of the Skinning Guide.
For you to provide me with positive/critical/negative feedback of those parts of the Guide that are available. i.e. to report any typos or errors I have made or anything you feel may benefit from a fuller explanation.
It provides a way in which you can provide information that I may have overlooked or not been aware of its existence.
------------------------------------------------------------------------
What this thread/topic is not for.Discussions on what is wrong with the Skinning Engine or what needs fixing.
Raising points/problems with the Skin Creation Process that neither I or anybody else can fix.
------------------------------------------------------------------------
This link will give you access the current PDF version of the JRiver MediaCenter Standard View Skinning Guide
For anybody interested in wanting to see what the 84 skins I’m working on look like in standard view
This link is to a Pix01 gallery showing what each skin looks like on the Windows and Linux Platforms
Or this one to see what they look like on the Mac Platform
N.B. in both galleries the Skin Name is below the image when in Thumbnail View
Author
Topic: A Guide to Standard View Skinning (Read 413 times)