new skins, skin editor and checkboxes

[claudiobosticco]

Hello, I've been experimenting with the skin editor and the new Shiva skin – which looks nice even though it's not complete yet.

With this new skin, it appears that there's an effort to make customization easier using the skin editor, though please correct me if I'm mistaken.

What I've noticed, however, is that the checkboxes (similar to the Tahoe and Obsidian skins) aren't "neutral"; instead, they have a color that matches the "Highlight Color."
This actually makes it a bit challenging to take one of those skins and attempt to create a new skin with a different Highlight Color.

Do you have any plans on your roadmap to allow customization of these checkboxes (perhaps using font icons)?
Or maybe to include an option for using "neutral" checkboxes (similar to those found in the Stratus and Twilight skins)?

[Isomorphic]

hi Claudio,

Yes, we have plans to much improve and simplify the Skin Editor, including a UI to edit settings grouped by class/widget rather than / in addition to cascades, configuring JS settings (like those in load_skin.js) and editing of icon-sets, to cover font-icons.

These Skin Editor enhancements and others have been sitting for a while, in favor of more pressing framework additions and enhancements. They likely won't hit 13.1, but they'll be in 14.0.

On your comment about checkboxes in Shiva - we'll take a look and either make the coloring configurable or switch it off to match other skins.

[claudiobosticco]

Hello, I see that now in Reify the checkboxes (in a modified Shiva) inherits the highlight color, even if I don't see it in the skin editor preview. Very nice!

[claudiobosticco]

On the other hand, I've noticed that the "Toggle" doesn't take the highlight color.

[Isomorphic]

hi Claudio,

We've improved the styles for isc.Toggle in Flat skins, including Shiva, and fixed so they cascade properly in the Skin Editor - you'll see those changes in today's builds (although not yet in live Reify 13.0, which is not updated daily).

On your other point about checkboxes in Shiva - to clarify the issue, is your complaint that the checkbox tick in Shiva is green, and if you change the Skin Editor's Highlight Color to red, the tick doesn't change color as you expect *in the Skin Editor*? But it *does* change color when you use the skin in Reify?

[claudiobosticco]

hi Claudio,

We've improved the styles for isc.Toggle in Flat skins, including Shiva, and fixed so they cascade properly in the Skin Editor - you'll see those changes in today's builds (although not yet in live Reify 13.0, which is not updated daily).

Thank you, I don't know to what extent you changed its styles, because I also noticed that the Toggle style appears to be more effective in the Tahoe compared to the Shiva (and maybe also Stratus and Twilight). In the Tahoe, it's more clear which is the FALSE state and which is the TRUE state, and in the TRUE state, there's more contrast between the slider track and the thumb.





Are you in agreement, or am I making a mistake?

On your other point about checkboxes in Shiva - to clarify the issue, is your complaint that the checkbox tick in Shiva is green, and if you change the Skin Editor's Highlight Color to red, the tick doesn't change color as you expect *in the Skin Editor*? But it *does* change color when you use the skin in Reify?

Yes, that's exactly right.

[Isomorphic]

hi Claudio,

We had a few days where the builds didn't run and the code you were looking at was still the old code. If you try it today, you'll see the Slider looking better in Shiva, and the Toggle looking better in all skins. If you still see issues with Toggle styling, please let us know.

The issue with the Shiva "tick" not changing color in the Skin Editor was that the customized part of the skin was not having its variables converted to CSS properties, which are runtime-mutable and needed for the Skin Editor to do its thing. This has been fixed for tomorrow's builds.

Note that neither of these fixes will yet be visible in live Reify 13.0, which is not updated daily. However, skin and Skin-Editor changes are simpler to apply there, so we may be able to push these changes over the coming weekend. We'll update here if we do.

[claudiobosticco]

hi Claudio,

We had a few days where the builds didn't run and the code you were looking at was still the old code. If you try it today, you'll see the Slider looking better in Shiva, and the Toggle looking better in all skins. If you still see issues with Toggle styling, please let us know.

Really nice work, thank you very much!

The issue with the Shiva "tick" not changing color in the Skin Editor was that the customized part of the skin was not having its variables converted to CSS properties, which are runtime-mutable and needed for the Skin Editor to do its thing. This has been fixed for tomorrow's builds.

Yes, I see it working for the Shiva skin, thank you very much.
There are also Tahoe and Obsidian which use a "not neutral" color for the "tick", which may benefit from this enhancement. Is it something that you could apply to them also?

[Isomorphic]

Those skins use a set of fixed images, unfortunately, where Shiva uses a pure CSS technique where colors can be easily modified.

We have (14.0+) plans for Skin Editor to allow selection of an icon-set which maps to the entire internal list of stockIcons, which represent icons used by the framework - eg, a font-icon or svg-set, or the icons from a specific skin - and this base icon-list could then be further customized.

Font-icons and SVG can be easily re-colored using CSS -but in order to recolor actual icon-files dynamically, we'd need to effectively stick the original image in a <canvas>, manipulate its pixel-colors and then cache the associated dataURL as part of the skin.

It can certainly be done, and we may add the facility in the future for mono-chromatic icons, but a font or svg icon-set would likely be a better option.

[Blama]

Hi Isomorphic,

unfortunately object-SVG + CSS support is still poor in browsers. AFAIR Chromium is doing better by now than Firefox, where it is still a big issue with flickering images.
See this thread.
I assume that any other solution that is not SVG+CSS will work better.

Best regards
Blama

[Isomorphic]

Are you familiar with SVG <symbol> tags? You can define a bunch of those in a single svg file, treating it as a giant sprite, and you can then <use> them later - in this case, there are no bulky DOM modifications or reloads associate with svg, so flickering should not be an issue.

We have some 13.1 docs which discuss it.

[Blama]

Hi Isomorphic,

no, I did not know that and just read the docs. Amazing! If this works and does not have any flickering (browser) problems, this is the perfect solution.
Could you add a sample for this? This would make feedback on the feature a lot easier.

Quick question: Right now with stateful images one has "Over", "Down", "Disabled" but also "OverDown". Is this still supported? I assume yes, but just to be sure.

Best regards
Blama

[Isomorphic]

hi Blama,

Yes, the state-list hasn't changed, the doc sample just didn't include them all. Also yes, we'll look at adding a sample soon.

[Isomorphic]

hi Blama,

We added a 13.1 sample that demonstrates using SVG symbols in the framework, as described in the docs - the sample is there now but, unfortunately, we included a path error, so the SVG container file is never loaded.

You can either wait for tomorrow's builds or you can tweak the sample source - instead of

var spriteFile = "/isomorphic/system/reference/inlineExamples/html/svg/mediaPlayer.svg";

it should be

var spriteFile = "[ISOMORPHIC]system/reference/inlineExamples/html/svg/mediaPlayer.svg";

Note that this sample is a limited/pruned look at an internal testbed for this mechanism, so is both fairly complex and may be incomplete - so we may simplify the code - but the current sample code should show the feature sufficiently.

[Isomorphic]

Bad link in the previous response - the sample is here.

As you move between skins, you'll see these SVG represented differently by default, either filled or not