Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[markf2748]

Background:  AFAIK, we currently have two ways to specify the location of special custom artwork for View Header files, SmallIcons.png, ActionWindowNavigation.png, and Options.png:

(1) C:\Program Files\J River\Media Center 33\Data\Custom Art\    (Windows OS example)

(2) Store the files within the skin directory, entering each custom artwork file individually in section <Art> ... <\Art>.  In practice, this typically means renaming these special custom files with a single unique preface so that they do not get scattered throughout the skin directory.

Request: Add a third option: 

(3) In <Art> ... </Art> allow us to specify a local directory which contains the custom artwork files named with MC's normal conventions (avoiding any special renaming).  For example to specify a location relative to the skin directory:
<Art> Entry="ArtworkDirectory" Directory=".\MyArtwork" </Art>

Alternatively, standardize the name of an alternate relative directory so it would not have to be entered by the developer at all.

Files found in this skin-specific "isolated" sub-directory would take precedence over files found with the same name in other directories (...\Data\Default Art and ..\Data\Custom Art) which impact all skins.  If the special directory is not found, MC defaults to current behavior.

Advantages:  Going forward, this scheme would make it easier to develop and distribute non-interfering custom skins without necessarily renaming these special files, listing them, and effectively baking them in.  It would also give the end-user more flexibility in choosing which special artwork to use:  Default Art, Custom Art, or Skin-Specific Art.

[Matt]

Would it be better to add a section to the XML or just allow the user to pick an extra image search path in options? Thanks.

[markf2748]

Would it be better to add a section to the XML or just allow the user to pick an extra image search path in options? Thanks.

(1) Key ideas:  Make it easy on the skin developer, it is a "standard" alternate location for special art files with the usual filenames, lock it to the specific skin (travels with it), no need to modify the main.xml, and keep it out-of-mind for the average end user.  Also, a custom resource file images.xml should be allowed in "This Art".  All this suggests to me the special directory should be a first level sub-directory below the skin installation directory, no matter where or on what platform the skin is installed.  It may as well have a fixed standard name, such as "This Art" (or something more creative  ).

(2) Allowing the user to search an extra path via an options setting, to override "This Art", is a separate question.  Maybe a "nice to have" in addition to (1).  In any case, the end user can still keep custom files in "...\Data\Custom Art"', as now, which automatically apply across all installed skins if the files are not found in "This Art".  "This Art" or files in it would have to be removed or renamed to skip over them unless you implement an override option.

Note:  The <Art> ... </Art> functionality should remain in place.  A good example is the MC built-in "ET Pastel Green I".  This skin should still work as long as the special View Header files "ET_*.png" are not over-ridden by corresponding "This Art" files.  But going forward, this functionality could also be achieved without special renaming, if desired.

[Matt]

(1) Key ideas:  Make it easy on the skin developer, it is a "standard" alternate location for special art files with the usual filenames, lock it to the specific skin (travels with it), no need to modify the main.xml, and keep it out-of-mind for the average end user.

I'm totally open to doing this, but need a little more help understanding.

Today skins can already define the custom artwork and just put a copy of the image in the skin folder itself. You said:

lock it to the specific skin

and it seems like the current approach does that nicely.

Are you just looking for a third directory "This Art" for artwork? As you know, the system already looks in two folders today (default and custom).

Thanks.

[markf2748]

Today skins can already define the custom artwork and just put a copy of the image in the skin folder itself. You said:  and it seems like the current approach does that nicely.

Are you just looking for a third directory "This Art" for artwork? As you know, the system already looks in two folders today (default and custom).

Skins display two general types of artwork.  (A1) "Fundamental" artwork which resides in the skin directory and is usually baked into the skin through main.xml.  (A2) "Special" artwork, which typically resides in either Default or Custom directories, usually comprising View Headers, SmallIcons.png (which also requires a mating resource file images.xml), ActionWindowNavigation.png, and Options.png.  When stored in Default or Custom dirs, (A2) normally gets applied to all skins (except as noted below).

Presumably the designer can incorporate (A2) directly into the skin folder (guessing), but I observe that in practice, when doing so, some experienced designers rename those files with a unique fixed prefix and then list each and every such renamed file in <Art> .... </Art>.  The latter maps the unique Special filenames to the filenames which MC expects.  Why unique Special filenames?  They are easily identifiable and don't get alphabetically scattered throughout the skin directory, which would make them somewhat hard to keep track of.  But also, importantly, this mechanism guarantees the designer's (A2) files will be used, independent of whatever resides in Default and Custom dirs.  So Request (1) is to create "This Art", where (A2) can be conveniently stored without renaming and without the tedium of using "<Art> ... </Art>" for a large number of files.  Its main intent is to simplify the design workflow while maintaining current functionality.  For a designer who actually wants to use unique filenames, and for backward compatibility, "<Art> ... </Art>" by itself will still work.

All this still leaves the end-user at the mercy of the designer.  A user who might change (A2) files in "This Art" for a built-in skin would be at risk of getting reverted back when MC updates (though a cumbersome workaround would be to copy the skin and rename it at the top of main.xml).  Therefore being able to change the path to the "This Art" directory as an MC Option (as Matt brought up) gives the user a lot of additional flexibility.  It's actually more than just a "nice to have".  For example, the user could create new "This Art" directories for different skins if so desired.  Or the user could redirect "This Art" to the Default or Custom dir.

I acknowledge my lack of experience in designing skins compared to many others.  So please correct whatever I got wrong.  Thanks for listening. 

[EnglishTiger]

The purpose of the <ART>.... </ART> Section in the main.xml file for any skin is to Instruct the Skinning Engine which Images/Icons in the Skin Folder are to be used instead of the ones in the relevant JRiver /Data/DefaultArt Folder.

In an earlier posting you mentioned the ET Pastel Green I Skin which demonstrates that a Creator can include Customised Versions of most of the images/icons that are in the JRiver DefaultArt Folder to create a skin that will not be adversely affected by any Customised Images/Icons anywhere else in MC.
And yes I use the ET_ prefix at the front of those customised images/icons names to make it easier for anyone wanting to make changes to that skin to spot/find them.
Marko uses a prefix or Art_ for the same reasons.
If you look in the main.xml for the ModernCards Dark Skin you will see that it doesn't use a prefix for it's customised images/icons
Just like the rest of the images/icons in that skin those customised images/icons are baked into the skin by the skinning engine but when a  customised SmallIcons.png is used if the images.xml file in the skin does not contain the same number of images as there are in the one in the JRiver DefaultResources Folder you will end up with a skin that uses a mixture of customised icons from the skin plus the Standard  MC SmallIcons set. If you load the ModernCards Dark Skin and add the ErrorFree icon to one of the toolbars you will see the one from the Standard  MC SmallIcons set because the images.xml file for the skin only goes up to image #142 but the one for the MC SmallIcons set goes up to image#148.

If somebody making changes to an existing skin follows the correct procedures, i.e. copy the Folder the skin is in to a Folder that will allow them to make changes to any of the folders content, Modify the Folder Name and then opens the main.xml file in a proper text editor and changes the Skin Name their Skin; when copied back to the relevant JRiver Folder nothing the original Skin Creator or JRiver does will harm/damage or overwrite their version of that skin.

Another thing you mentioned is View Headers who was the person who asked for the to be Made Customisable and is still the only person to create Skins that uses Customised View Header Images, including ET Pastel Green I? Although I was the one that requested that change  it was my 7 year old Granddaughter who came up with the idea to make the skins we were creating different to every other skin in existence.

You have only seen, and maybe even used, the  ET Pastel Green I Skin but it is only 1 of 19 skins from the ET XXXX XXXX I series of skins which all use the same Image Names for every Fundamental Skin Image and Customised Image/Icon including in the <ART>...</ART> section of their main.xml fie.

The attached image shows the Tree Section of the Standard View Skin of 3 of them ET Blue Card I, ET Pastel Green I and ET Platinum Jubilee I and it quite adequately demonstrates that even though all the individual images use the same name in all 3 skins when a skin is created with all the images in the Skins Own Folder and the correct procedures are followed, is doesn't matter what names you give to those images as long as the Skinning Engine is told, via the <ART>...,<ART> section of the main.xml.

There is no need to make any changes to the present way of creating skins and the proof of that has to be the fact that my 7 year old Granddaughter created the ET Platinum Jubilee I and Platinum Jubilee II Skins in under 3 days, without any help from me. I didn't even know she had created them until the day she came in and asked me to copy them onto my Win and Mac PC's so that she could check to see if she had made any mistakes that were not obvious/visible on her mam's laptop. For most of that time she was using PSP to colour the Fundamental Skin and Customised Images because the only difference in the main.xml for both skins is the number of Customised Images listed in the <ART>....</ART> sections of their respective main.xml files.

[marko]

Advantages:  Going forward, this scheme would make it easier to develop and distribute non-interfering custom skins without necessarily renaming these special files, listing them, and effectively baking them in.  It would also give the end-user more flexibility in choosing which special artwork to use:  Default Art, Custom Art, or Skin-Specific Art.

I've read the OP several times over, across a few days, and honestly, I'm having trouble following. Apologies for being a bit slow. The whole thing reads as if there is some issue with the artwork file naming? or is it location? or both? What would you define as an "interfering custom skin"?

The cascading nature we currently have is simple:
A skin author can choose to include artwork as an essential part of the skin by having the files in the skin folder and referencing those files via the <art> section of the xml.

If there's no <art> section with the skin, MC checks for files in the \Custom Art\ directory and uses anything it finds there for every skin
If there's no \Custom Art\ directory, files from the \Default Art\ directory are used, for every skin

These last two are important. Especially the last one. Some skins are old. They date back to a time when there was no 'Modern' tag window, or further back, for example, no tabs in MC. When an old skin is loaded that does not cater for these new areas, files from the custom or default art folders are used.

Before we had an <art> section to utilise, skin creators could include custom art files, but always with the need to explain the caveats, and where to place them. It wasn't good from a user experience POV really.

Now it's good. Skins arrive with the user ready to go with custom art that does not affect their experience with any other skin they might choose to use. That custom art is chosen by the skin author and should remain with that skin. The files can be named anything the creator chooses. Why does the file name matter to anyone other than the skin creator?

If an end user wants to experiment with files included with one skin, in another, that would be their choice. They're free to do so, and by using a new skin folder, they can use any naming convention they choose.

Advantages:  It would also give the end-user more flexibility in choosing which special artwork to use:  Default Art, Custom Art, or Skin-Specific Art.

I can only speak for myself about this, possibly, other skin creators feel the same way. To create a high quality MC standard view skin from scratch is an enormous undertaking. It involves many hundreds of hours work, possibly even thousands (a long time, anyway ) to get the component images right, to get the drawing instructions right, to get the colours right, to get the scaling right, to get the platform specific stuff right, to get the icons and artwork right, and so on.

We then donate all that work, freely, and encourage interest in how and why it works, so that maybe, someone will be inspired to make something else. This is fine, but, that skin we released? It needs to stay as it is. It uses artwork that we chose during skin creation. Just because we give these things away, does not mean they have no value. They do. If an end user feels the need to use different artwork, it is up to them to learn how the whole thing works from skin directory down, and then create their own version. AwesomeDonkey calls them 'Forks'

What exactly is it that needs fixing/simplifying here?

[markf2748]

Gentle People All:  Thanks for your considered replies.  No question that the current methods for including custom artwork into a skin work perfectly well.  But FYI here is what motivated my OP:

I have spent many hundreds of hours, spread over a couple of years, developing a minimal dark skin that I like.  Studying the prior work of others made this possible.  So I recently start thinking, “Should I release this skin (even though it is only developed and tested for Windows and focuses on Audio), and what would it take to do so?”

The first concern is how to incorporate my artwork which resides in …/Data/Custom Artwork (plus …/Data/Custom Resources/images.xml).  It consists of ActionWindowsNavigation.png, Options.png, SmallIcons.png, TaskbarButtons.png, three NoThumb*.png files, and thirteen ViewHeader*.png files.  A total of 21 files!

I could throw them all into the skin's directory and let them scatter (admittedly at least the "NoThumb" and "ViewHeader" files would cluster).  Or I could rename them all with a preface such as “_Art_” to keep them together at the top of an alphabetical directory list.  In the latter case I would have to make 20 entries in <Art>…</Art> and modify names in my original *.svg Inkscape generator files to be consistent.  Both methods create a new "non-interfering skin", i.e. one which does not disturb other skins while preserving all my artwork.

Ever thinking “there must be a better way”, I proposed creating a skin subdirectory “This Art” as described in previous posts.  Then I just throw all the files in there as is.  The subdirectory acts similar to …/Data/Custom Art/ (though it also handles custom images.xml), but it travels with the skin in a non-interfering way.  Problem solved, all clean, backwards compatible, a good way to move forward.

I hope this helps and that JRiver will still consider the idea.  Thanks.

12/30/2024 Additional Note:  As originally stated, "This Art" takes precedence over …/Data/Custom Art/, but the user would have straightforward ways to override this (delete or rename the file in "This Art").  By design, files with standard names in "This Art" would eliminate the need for (and override) corresponding entries in <Art>...</Art>.  A non-standard or missing entry in "This Art" would be ignored, leaving the <ART>...</ART> entry in force.  In this case, if lacking an <Art>...</Art> entry, then in the customary way .../Data/Custom Art/ and ...Data/Default Art/ come into play.  main.xml only requires modification to add or change an <ART>...</ART> entry, which the end user would not normally do.  The goal is to eliminate <Art>...</Art> entirely in any skin that strictly adheres to standard filenames placed within the collecting subdirectory "This Art".

[Matt]

It seems to me that including your custom artwork in the skin folder is a nice answer. What's the problem with that? If you want it in multiple skins, you need to copy. But then the skin is self contained which is good.

[EnglishTiger]

The purpose of the <ART> .... </ART> section of the main.xml file is to tell the Skinning Engine the name of the image you want your skin to use in a specific part of the skin because if it's not listed in that section it will use the image from the Default Art Folder.

Even if the system was changed to allow those images to be in your "This Art" sub folder you are still going to have to make those 19 Entries in the <ART> ... </ART> section of the skins main.xml file

Nobody is forcing you to rename those images that will be listed in the <ART> .... </ART> section the only rule that applies to that section is the entry in the Name="..." part of the instruction has to be identical to the name of the Image it is replacing in the Default Art Folder.

Let's take a look at some statistics:-
Awesome Donkey - 17 Skins, Marko - 12 Skins, EnglishTiger - 38 Skins
Most of which have an <ART> .... </ART> section, for 19 of my skins it contains 22 Entries
Has Awesome Donkey, Marko, I, the creator of the ModernCards Dark skin, or any other creator of a skin that uses customised images/icons ever complained about having to use the <ART> ... </ART> section of the main.xml file and asked for a different approach be implemented?

There are problems with the Skin Creation Process and the way the Skinning Engine Works but having to use the <ART> ... </ART> section to get the Skinning Engine to use a Customised Image instead of a Default One isn't one of them.

There are over 150 skins available for use with MC and the current method of assembling an Installable Skin Package did not give their creators any problems, so until a Real Problem occurs there is no need for it to be changed.

[markf2748]

It seems to me that including your custom artwork in the skin folder is a nice answer. What's the problem with that? If you want it in multiple skins, you need to copy. But then the skin is self contained which is good.

Indeed worked, after I added all the required entries in <Art>...</Art>.

The purpose of the <ART> .... </ART> section of the main.xml file is to tell the Skinning Engine the name of the image you want your skin to use in a specific part of the skin because if it's not listed in that section it will use the image from the Default Art Folder.
...
Nobody is forcing you to rename those images that will be listed in the <ART> .... </ART> section the only rule that applies to that section is the entry in the Name="..." part of the instruction has to be identical to the name of the Image it is replacing in the Default Art Folder.

Thanks for the clarification.  Worked as you describe without renaming the files, as long as they were entered in <Art>...</ART>.  In the end, I used standard filenames as the root and prefaced each with "_mf_" so the type (A2) files all appear clustered in a Windows alphabetical file list, usually at the top.  Then I also added same preface to standard filenames in my artwork development folders for consistency.  I will eventually update their internal "Export" filenames within Inkscape.  If using them in .../Data/Custom Art/, I remove the preface, thereby reverting to the standard filenames.