[Isomorphic]

Yes, we fixed this yesterday - it applied to any auto-sizing fields

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-07-25/AllModules Development Only (built 2024-07-25)

The other issue where there's no separator between the last two fields - no, that's not normal and we'll update again here when it's been fixed, along with the opacity issue from #24.

I think this was the only issue still open in this thread, but now I see it's fixed, thank you very much.

[Isomorphic]

The issue from #24 was a bit mysterious - it presented as an opacity which we couldn't find being directly applied, but we do perform some tricky pushing backwards and forwards of styles for Buttons, between the content div and the outer table.

We did correct opacities for disabled buttons, tabs, sections and so on, so most likely one of those fixes addressed this one. Always nice. :)

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-07-05/AllModules Development Only (built 2024-07-05)

A partial update - the issue with the sorterButton being clipped is addressed for today's builds - it's now the proper size, not clipped and the right color.

I see it's fixed, thank you very much

[cut]...along with the opacity issue from #24.

this seems also fixed, isn't it?

[Isomorphic]

A partial update - the issue with the sorterButton being clipped is addressed for today's builds - it's now the proper size, not clipped and the right color.

The other issue where there's no separator between the last two fields - no, that's not normal and we'll update again here when it's been fixed, along with the opacity issue from #24.

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-07-03/AllModules Development Only (built 2024-07-03)

hi Claudio,

On post #16, we've fixed icon-scaling in Buttons and Menus - both of these were widget-level issues, their iconWidth/Height attributes weren't included for scaling for any image-type.

We've also made changes that cause sizes specified directly in an SVG string, like "size:12,12;", to also be scaled. You would specify sizes like that for better control independent of the container-size - but those icons would never scale, because scaling is applied to widget-attributes like iconWidth/Height, and setting "size:w,h" in a src string side-steps those scaled values.

Auto-scaling specified "size" attributes in SVG strings seems like the best default behavior, since other SVGs will be scaled and SVG can scale without loss of quality. But, you can disable it by setting "scale:false;" in your src string if you want to - for example, we've set scale:false on the ends of scrollbars, which don't get wider with density, so the icons probably shouldn't scale up either.

I see the icon-scaling issue in Buttons and Menus is fixed (and I also like the iconBaseStyle color), and I also see that the sizes specified in the SVG string are scaling.

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-07-03/AllModules Development Only (built 2024-07-03)

hi Claudio,

For the initial report about right-aligned SectionHeader open/close icons, we agree that icons on the right feel out of place when there are other icons or inlined components there - so, we've switched the icons to the left in Obsidian and Twilight, and made them lighter and more visible in Twilight.

much better!

The issue with disabled opacity from #24 is being looked into.

I see it's fixed, thank you very much

[claudiobosticco]

[cut]
for example, we've set scale:false on the ends of scrollbars, which don't get wider with density, so the icons probably shouldn't scale up either.

Hello, maybe related to this, there's a problem with the arrow for the sorterButton (this is from fetchOperationFS sample):


this is with Spacious density, as you may see the arrow is clipped on its right.

Also, is it normal that I don't see the separator between the "In Stock" and "Next Shipment" column?

[Isomorphic]

hi Claudio,

For the initial report about right-aligned SectionHeader open/close icons, we agree that icons on the right feel out of place when there are other icons or inlined components there - so, we've switched the icons to the left in Obsidian and Twilight, and made them lighter and more visible in Twilight.

The issue with disabled opacity from #24 is being looked into.

[Isomorphic]

On your question from #21, you can try out the changes mentioned there in the next build, dated June 29 or later. We also added a FormItem.iconBaseStyle attribute, which is now set to "icon" in Shiva - so arbitrary SVG icons, without a cssClass specified, will now get the color from the skin's "icon" class in FormItems, rather than inheriting the formItem's text-color, which is a bit darker than we want for icons in this skin.

We'll take a look at the opacity difference among the buttons from #24 and get back to you.

[claudiobosticco]

Hello, yes, I mean the background opacity.

This is after clicking "Try it":

Pressing Tab doesn't make a difference. Neither clicking the "Stretch Button".

This is while hovering the "Stretch Button":

[Isomorphic]

Sorry, what is the difference you are seeing there? The background opacity?

Did you try pressing Tab to change the selected button?

[claudiobosticco]

Hello, another note about this test case, in Shiva I see a difference between the MenuButton and the IButton which I don't see in other skins:



not sure what it's causing this in the CSS

[claudiobosticco]

Wow, these sounds as great enhancements, in which build will I find them?

[Isomorphic]

hi Claudio,

On post #16, we've fixed icon-scaling in Buttons and Menus - both of these were widget-level issues, their iconWidth/Height attributes weren't included for scaling for any image-type.

We've also made changes that cause sizes specified directly in an SVG string, like "size:12,12;", to also be scaled. You would specify sizes like that for better control independent of the container-size - but those icons would never scale, because scaling is applied to widget-attributes like iconWidth/Height, and setting "size:w,h" in a src string side-steps those scaled values.

Auto-scaling specified "size" attributes in SVG strings seems like the best default behavior, since other SVGs will be scaled and SVG can scale without loss of quality. But, you can disable it by setting "scale:false;" in your src string if you want to - for example, we've set scale:false on the ends of scrollbars, which don't get wider with density, so the icons probably shouldn't scale up either.