Print

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

[~:Eternal Themer:~]

-

[Matt]

I looked at the toolbar separator. 

It's exactly two pixels from the top and bottom.  Some skins make a border in MainFrame_BottomBorder.png so the top has a one pixel border.  Not all skins do that though.

So I'm not really sure there's anything to change on that one.

[~:Eternal Themer:~]

-

[Matt]

Inactive toolbar buttons are made by making the active image monochrome with the text color.  The algorithm is a little advanced, but seems to work pretty well.

[~:Eternal Themer:~]

-

[~:Eternal Themer:~]

-

[Matt]

"Type your search here" is built by blending the active edit color and the background.  Here's the code:
m_rgbTextFaded = JRBuildColor(m_rgbText, m_rgbBackground, 0.4f).GetNoAlpha();

I don't follow what's wrong about selection.  I need more details.

[~:Eternal Themer:~]

-

[HPBEME]

I don't follow what's wrong about selection.  I need more details.

Matt, Eternal is noting that the "highlight" around selected thumbnails is not symmetrical.  The highlighting is biased 2 or 3 pixels to the left/top.

I personally use the "no thumbnail spacing option", so for my use case I see a 2 pixel highlight border at the left/top, and nothing (no border highlight) on the right/bottom.  For other thumbnail spacing options, the highlight is "smaller" on the right/bottom.  It is not a showstopper, but it has definitely annoyed me for 15 years - it would be great if it were fixed.

[HPBEME]

"Type your search here" is built by blending the active edit color and the background.  Here's the code:
m_rgbTextFaded = JRBuildColor(m_rgbText, m_rgbBackground, 0.4f).GetNoAlpha();

well its ugly at grey scale....

I have to agree with Eternal here... the color "blend" is ugly. It is not that noticeable on light skins, but on dark skins... yeah... bad.  When I created my skin, this color blending was a source of extreme frustration - first, just figuring out which of the 100+ hex color assignments were getting blended, and secondly, I was forced to use less than optimal colors so the overall skin "worked".

More importantly, it kneecaps the skin developer's options - instead of blending two colors specified for other purposes, why not add a new input variable for "disabled text" (like is done in many other locations of the xml)? A disabled appearance is effectively what occurs when you blend active and background text colors. This way, the skinner can under-intensify the color with any hexcolor they desire, or they can make it the same "full" active text color (which is definitely my preference).  Same goes for the "disabled settings" text color in the Options Window. You cannot set it directly, as it is a blended color. With multi-color dark skins, it is very hard to get this text color to come out right, and have the blended colors still look good for their primary purpose.  A dedicated "disabled text" color for this would be enormously helpful.

Matt, you may or may not be aware, but I documented all the "blended" color locations in the Dream in Blue skin "main+comments.xml" (https://yabb.jriver.com/interact/index.php/topic,128460.0.html - see post 1 for additional info).  In that same comments xml file I documented every issue that makes MC skin creation a huge challenge. My hope was that you/JRiver would go thru it and make updates to the skinning code to alleviate at least some of these issues. I cannot count how many times I almost threw in the towel when I was creating my 1st skin.  Since then, I have created 2 more skins (1 with 12 variations, and the other will have at least 4 variations). At this point, I am more familiar with MC skins and how to best manipulate that xml file than I care to admit. If you are interested, I would be happy to discuss with you directly the areas that need correction and/or improvement.

[~:Eternal Themer:~]

-

[EnglishTiger]

The problems with the Skinning Engine go even deeper  Not only are there the ones I reported in this thread:- https://yabb.jriver.com/interact/index.php/topic,131619.0.html

I recently purchased a 2020 MacBook Air and found a few more

Problem 1:- Skin Creators take, hopefully, time and effort to get their skin looking decent/good, including putting Frames around various Windows/Panels; Like The DSP Studio Panels - Guess what on a Mac those Frames are not used. Image 1 in the attached gallery shows the DSP Studio Panel that the user gets to see on the Mac; Image 2 shows the same form in Windows.

Problem 2:- Mini-View

When switching from Playing Now, with a TrackInfo Plugin being used, in Standard View to Mini-View not only do you get the Mimi-View on the screen you also get the Display Panel showing the TrackInfo Page. Image 3 in the attached gallery.

But when I had Artists View open in Standard View, which of course means the Display Panel is visible in the Tree, and switched to Mini-View this time there was the Mini-Player and below it was the Display Panel in exactly the same place it had been when in Standard View. Images 4 and 5 in the attached gallery.

Now for the oddity - I could only Move and Resize the Mini-Player and every time I moved it the other "Window" also moved.

For completeness Image 6 is what you get when you see when you switch to Mini-View in Windows.

Another difference I spotted - The image that gets added to the Toolbar when you add "Stop after Current Track" on a Mac is not the same one used when you add it in windows. The one the Mac Uses is actually better.

Pix01 Gallery - https://pix01.jriver.com/PL1%40cd3L

Oh and just to add to HPBME's list of oddities I discovered that whilst the skins provided with MC refer to the Variant of the Player Controls that appears when you hover the mouse over the edges of the screen in Display and Cover View as FullscreenPlayer - PixOS refers to it as DisplayPlayer.

It is becoming painfully obvious that a lot of work needs doing on the Skinning Engine to make it more fit for purpose.

Plus, if the same totally illogical order I found in the main.xml files for most existing skins use is anything to go by then the skinning engine needs to be restructured so that it operates in a more logical/efficient way.

[Awesome Donkey]

The problem is, redoing the skinning/window drawing engine of MC likely would be a huge undertaking, so it's probably not worth the development time (which time = money) at the current time for JRiver. The best you're probably going to get is describe and explain in as much detail as possible why a change or addition to the skinning engine is needed. Personally I'd like to see things like SVG image support (so scaling at any size would be possible without needing multiple images), improvements to the OpenGL backend for glass, an alternative Vulkan backend for glass effects (so it can be used on any OS), glass improvements so it can be used anywhere in the UI without glitching or flashing (and hopefully fixing the white colors appearing as opaque instead of semi-transparent with glass effects no matter what) and things like having an option to use the OS' menus and use of the OS' minimize/maximize/restore/close buttons without relying on skin images would be nice, but at the same time one has to be realistic and look at it from a return on investment point of view, which means it's probably not worth it. Instead, try to be simple about it, and like I said describe why the change/addition you're requested is needed.

Also having one giant, single topic covering skin issues/bug reports and requests for the skinning engine might be a good idea.

[HPBEME]

The problem is, redoing the skinning/window drawing engine of MC likely would be a huge undertaking, so it's probably not worth the development time (which time = money) at the current time for JRiver.

I think you can remove the qualifier "... at the current time ...". The chances there will ever be an overhaul of the "skinning engine" is slim and none... and slim left town over a decade ago.  I would be happy to proven wrong about that, but I won't hold my breath.

That said, I already provided extensive and detailed notes (as you suggested in your previous post) over a year ago now, of numerous things that should be addressed via my skin's main+comments.XML.  I grow weary of referencing this document, as I have pushed it in half dozen+ posts across several threads in the hope it will be looked at and acted upon.  If JRiver has read thru it I have no idea - there has certainly been no acknowledgement they have, so I can only assume they haven't. I wonder if anyone as read them - have you AD?  I am not sure what else I can do to promote these fixes/improvements.

I am certainly no coder or graphics designer...  I truly just brute-forced my way thru creating the Dream in Blue skin.  I learned a helluva lot along the way, and based on that experience I personally have zero expectation for a code rewrite - that almost certainly would require all the skin input XMLs be completely redone as well. My suggestions are ones that would be backward compatible for all those 20 year-old legacy skins. Adding new input variables have no affect on old skins - they would simply lack those inputs (though adventurous MC users could certainly add the necessary lines to the legacy XMLs to make them compatible).

I would love to think this time my post will generate some action! But if past is prologue, I expect... nothing.

[HPBEME]

I recommend reading my post again - a "skin engine upgrade" is not going to happen.  No amount of praying or overuse of exclamation points!!!!!!!!!! is going to change that.  Any changes will be incremental at best.

[EnglishTiger]

A lot of the work needed to correct some of the problems with the skinning engine, if done correctly, should break nothing; including those Legacy Skins that reference parts of the Skin that no longer appear to be used.

Another thing that is being overlooked is that some of the problems are down to the size,  images and "Template" being used for those Skins - including some of the ones encountered by Eternal Themer.

Let's look at an example of Size and using a template that does not conform with what it says in the Skinning SDK - https://wiki.jriver.com/index.php/Standard_View_Skinning_SDK

I just removed 21kb from the Modern Cards Dark Edition Skin by reducing the number of sub-images used for the PlayerBar_Butons from the 5 that were there to the 3 it says should be used in the SDK Tutorial. The ListHeader image can, and does cause miss alignment between the Dividers in the header and those in any lists below it because the ListHeader Image has a Vertical Divider at the left hand end of it. Switching that Vertical Divider to the other end of the image cures the alignment problem.


Even if nothing else gets done at the very least what is seen on the screen/vdu should be exactly what the Skin Creator Designed regardless of platform and that thing about the Skin being drawn differently when a change of Skin happens to when a change of track happens.

On and yes there are other problems with the skinning engine that I have encountered, to keep the weight down to a minimum I tried to see if I could reduce the number of sub-images used for the Volume and Progress sliders. If I tried to use an odd number of sub-images I never got to see the full image on the screen, but did if I used an even number of sub-images.

Even if nothing else gets done at the very least what is seen on the screen/vdu should be exactly what the Skin Creator Designed regardless of platform and that thing about the Skin being drawn differently when a change of Skin happens to when a change of track happens.

Regardless of if I'm on my Windows or Mac PC this is what I want to see when I'm using my New "Bloat Free" ET Dark Day Skin

Compared to the Modern Cards: Dark Edition Skin which weighs in at 1.07 Mb this little baby weight in at a mere 176 Kb

[JimH]

Regardless of if I'm on my Windows or Mac PC this is what I want to see when I'm using my New "Bloat Free" ET Dark Day Skin

Compared to the Modern Cards: Dark Edition Skin which weighs in at 1.07 Mb this little baby weight in at a mere 176 Kb

Thanks for the feedback, but why does it matter so much? 

A 1 TB SSD is now about $100.
So 1 GB of storage is about $0.10.
and 1 MB is hardly worth calculating.

What is a KB?   

OK, I'm kidding you, and I'm very grateful for you attention to skinning, but we have to focus on the future.

[HPBEME]

Thanks for the feedback, but why does it matter so much? 

It matters not at all.

My skin is the "heaviest" by far (50% more than the next heaviest), and it loads instantaneously and without issue, just like super-flyweight skins. No doubt English Tiger's coding knowledge dwarfs mine, but on this one... real-world use is simply not proportional to his concern.

A lot of the work needed to correct some of the problems with the skinning engine, if done correctly, should break nothing; including those Legacy Skins that reference parts of the Skin that no longer appear to be used.

OK... that is great if true. JRiver is still does not going to rewrite the skin code - note JimH's remark:

... but we have to focus on the future.

Not exactly sure why making skins better and easier to create is not part of JRiver's future, but that confirms my point.

I still think it could be improved to address many skin issues without requiring anything close to an extensive rewrite.  And if it does require that, perhaps JRiver could hire English Tiger to develop the new code?  Hey... look at that ET... I just volunteered you for some work  . 

(Note: ET= English Tiger, not Eternal Themer)

[EnglishTiger]

Thanks for the feedback, but why does it matter so much? 

A 1 TB SSD is now about $100.
So 1 GB of storage is about $0.10.
and 1 MB is hardly worth calculating.

What is a KB?   

OK, I'm kidding you, and I'm very grateful for you attention to skinning, but we have to focus on the future.

It's not only about the amount of disc space being used - Larger files take longer to load and put more load on just about everything attached  to the motherboard. Which equates to reduced efficiency and higher energy consumption.

Forgive me if I've completely misunderstood the concept of Going Green but I thought one of the things we are all supposed to do is Reduce our Consumption of Resources whose production will continue to have 'less than acceptable Carbon Footprint".

[HPBEME]

So.... use "lightweight" MC skins and save the world?  I am skeptical of this notion.

[JimH]

Infinitesimally greater load.  You're playing files that are at least several MB's for hours.  Lossless audio would be more than 100 MB's per hour.

[EnglishTiger]

HPBME - Your skin is larger than most because, unlike the vast majority of skins ,you provide the individual user with some ability to configure it to suite their own requirements without having to. use an image editor.

But the one thing it does not suffer from is the "the kind of bloat" that I found in the Modern Cards Dark Skin and others.

In your skin all the "PlayerBar Button" Images only contain the 3 required/necessary sub-images. Consequently the Skinning Engine is loading a smaller image and only having to extract the one-third of the image it needs as opposed to the one-fifth of the larger mage it's having to extract for the Modern Cards Dark Skin.

Therefore your skin, despite it's size, is actually more efficient than most of the other skins available.

Maybe I should redefine Bloat as Feeding the Skinning Engine with larger than necessary images and/or ones that contain more sub-images than needed to create the assembled skin.

[marko]

Things have a purpose... The Fifth image of the playerbar buttons defines the "click" zone of the button. If omitted, The entire space used by the button reacts to a mouse click.

[Matt]

So it sounds like we should make skins be able to specify the faded text color for edit controls.

I found that the disabled list text color was specified, but built instead sometimes.

Are there any other colors we should allow to be customized?  Thanks.

[HPBEME]

Marko!  About time you joined the fray.

I was not aware the 5th image defined a click zone - interesting.  That said, I cannot ever remember thinking... that play control button activated when I did not intend it to...   And what about the 4th image? It is presumably for when the play buttons are "inactive", which is never. So only 3 sub-images add any value IMO.

ET is correct, I did pare down a whole slew of sub-images for various elements in my skin.  If I determined a sub-image never "showed itself" when using a certain aspect of the skin, I nuked it.  But again, image size, whether extra sub-images are needed, increased load time, burden to the motherboard, being more green, saving the planet... can we just stop please?  It is so... to steal Jim's word... infinitesimal, it cannot possibly be less relevant. I thought this thread was about fixing skin errors, not how to make a skin hyper-light (sorry ET )

[HPBEME]

Yes Matt, the ability to control the color for search box "placeholder" text would be nice. The following is straight out of the Dream in Blue main+comments.xml that I reference ad nauseum:

• Bizarrely, [Back] color is also used as a "blend" text color in Search Boxes, but ONLY for the placeholder word "Search". Once you begin typing, the "blend" goes away, but the typed text color depends on the specific search box. MC has 4 primary search boxes: PlayerBar, Tag Window, Playdoctor (only visible when play is stopped), and the OptionsWindow.  And of course, the search color settings are not consistently applied. For my current color settings, all 4 searchbox placeholder text is "blended", two are "mostly" white, and 2 are "mostly" blue (the text looks thin and faded). To see this more clearly, temporarily change the [Back] color to red (FF0000) and reload the skin.
  

The text color of "inactive" settings in the Options window blends Text and Back hex codes in the TREE section. That should also have it's own independent input.

For an oddly specific skin location, here is another comment from the Dream in Blue main+comments.xml (see the FRAME section for combobox):

• [DisabledBack]    Background color of disabled combobox: does not apply since an image is used. However, in one highly specific location (there may be others), unless this color is the same as [Text] it is very thin/faded. To see this, set  color to red and go to the Tag Window. Note the placeholder word "Add" in the "new keyword" combobox at the bottom is thin/faded (the combobox list items however, are not affected). I am surprised I found this, but using red to find issues works wonders.  I thought simply deleting this specific hexcode might work, but the text defaults to black and displayed text is again thin/faded. All these blended color issues always involve "placeholder" text. Hopefully JRiver can fix this.
  

I put an enormous amount of effort into documenting the myriad of skin issues - the above are just a tiny sub-set.  Instead of me regurgitating all that here on the forum, why not read thru that comments XML file? You will find a whole bunch of stuff that... maybe... can be addressed fairly easily.

[EnglishTiger]

Why are "Blends" even being used - surely the Skinning Engine should be doing exactly what the Skin Designer/Creator wants/told it to do and not a mix of their requirements and something imposed on them by a Demented Script Kiddie simply because they think it looks cool

[~:Eternal Themer:~]

-