Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    hi Claudio,

    The bug with the icons reverting to PNG has been fixed and we've made some other changes - the fromSrc values for builtin stockIcons now include the [SKINIMG] prefix and the system will now assume a fromSrc like "icons/logo.png" is relative to your appImgDir, prefixing it with [APPIMG] instead of [SKINIMG]. We've also made some doc changes to cover the details discussed previously.

    Please retest with a build dated November 3 or later.

    Leave a comment:


  • Isomorphic
    replied
    Thanks Claudio - it's become clear what's happening here.

    Firstly, the issue with some icons reverting to PNGs is not related to the change we made most recently (although we will be revising that change). addStockIcons() itself causes a visual update of rendered widget-icons and internal logic isn't properly updating elements with certain src-string formats. If you do an isc.say() followed by addStockIcons() in the console, you'll see the icon in the opened say() window change from an SVG to a PNG while most other icon-uses, like those in an LG menu, do not change. We'll fix this shortly.

    On the path-requirements for StockIcon.fromSrc - we misspoke a bit here.

    1) In general, you do need to provide the proper prefixes for StockIcon.fromSrc values - the builtin stockIcons are all skin-images, so internal logic applies a default prefix of [SKINIMG] if the path doesn't start with a [] prefix or a /.

    We'll be moving this [SKINIMG] prefix to the builtin stockIcon.fromSrc values and changing the default to [APPIMG], so that developers' custom stockIcons will be assumed to be in the appImgDir - but you should still include whatever prefix you need, even if it's [APPIMG], for clarity in your fromSrc values.

    2) Additionally, in this case, you do have to include the [APP] prefix anyway, because an *image* path like "icons/logo.png" is not relative to the app, as you might think - instead, it's relative to either the appImgDir ([APPIMG], [APP]images/) or the skin ([SKIN] + widget skinImgDir, default images/, aka [SKINIMG]) depending on the method, and your file isn't in either of those locations.

    So you do have to give it the proper prefix, as you'd also have to do if you requested it in code ("icons/logo.png" would be expanded to the equivalent of [SKIN]/images/icons/logo.png, or [APP]/images/icons/logo.png - both incorrect).

    If you moved your icon to your actual appImgdir, then your fromSrc would be "[APPIMG]logo.png", and you could refer to it in code by name, or with any partial path that expands to the same URL - "[APPIMG]logo.png" or "[APP]images/logo.png", eg - even just "logo.png" when skinImgDir is cleared on a given widget.

    Anyway - we'll make some changes here and expand the docs to cover these usage and behavior details - we'll let you know when they're available.
    Last edited by Isomorphic; 3 Nov 2024, 06:17.

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by Isomorphic View Post
    One question - do you call Page.setAppImgDir() in your app?
    yep,
    Code:
    isc.Page.setAppImgDir("[APP]images/");

    Leave a comment:


  • Isomorphic
    replied
    hi Claudio - yes, you can map multiple known file-paths to the same SVG by adding one stockIcon per file-path (fromSrc), each with the same target (src).

    We're seeing the second problem you mentioned and will update here when we have it fixed.

    One question - do you call Page.setAppImgDir() in your app?
    Last edited by Isomorphic; 1 Nov 2024, 22:53.

    Leave a comment:


  • claudiobosticco
    replied
    also for isc.warn(), isc.say(), I see the png icon instead of the SVG.

    Leave a comment:


  • claudiobosticco
    replied
    Actually I've just noticed a problem, if I run this code in the showcase:

    Code:
    var myIconSet = [
        {
            name: "logo",
            fromSrc:"icons/logo.png",
            src: "sprite:svg:[APP]/images/logo.svg#logo"
        }
    ];
    isc.Media.addStockIcons(myIconSet);
    
    isc.Img.create({src:"icons/logo.png"})
    I then see both the png and SVG icons for the sections "opener" icons:

    Click image for larger version

Name:	2024-10-31 21.37.48.jpg
Views:	136
Size:	16.2 KB
ID:	274011

    Note that I see the same in my app, where the icons used in myIconSet actually exist.

    Leave a comment:


  • claudiobosticco
    replied
    SmartClient Version: SNAPSHOT_v13.1d_2024-10-31/Enterprise Deployment (built 2024-10-31)

    I can confirm it's fixed, thank you very much.

    Another question: to simplify icons (I've got some icons which are too complex to be effective), in my application, I would like to map multiple PNG icons to a single SVG icon. In this case, can I simply add more than one stockIcon to my iconSet, each with different names, and all using the same SVG icon?

    BTW, that's really a cool feature!

    Leave a comment:


  • Isomorphic
    replied
    hi Claudio - that was a bug and we've fixed it for tomorrow's builds.

    If you're interested, the issue was that the function that maps src-strings to potential stockIcons wasn't checking for an exact match with original stockIcon.fromSrc values, just the parsed version of them as expanded by Page.getImgURL().

    Leave a comment:


  • claudiobosticco
    replied
    Hello, I've just started reading the doc, and experimenting with the APIs, and I've already a question, if I add a StockIcon like:

    Code:
    var myIconSet = [
        {
            name: "logo",
            fromSrc:"[APP]icons/logo.png",
            src: "sprite:svg:[APP]/images/logo.svg#logo"
        }
    ];
    isc.Media.addStockIcons(myIconSet);
    so that I can both use:

    Code:
    isc.Img.create({src:"logo"})
    to render the SVG, and also older code like:

    Code:
    isc.Img.create({src:"[APP]icons/logo.png"})
    will render the SVG


    is it expected that the [APP] part is actually required? It seems that it works only like that, and not with code like:

    Code:
    var myIconSet = [
        {
            name: "logo",
            fromSrc:"icons/logo.png",
            src: "sprite:svg:[APP]/images/logo.svg#logo"
        }
    ];
    isc.Media.addStockIcons(myIconSet);
    
    isc.Img.create({src:"icons/logo.png"})

    Leave a comment:


  • claudiobosticco
    replied
    Thank you so much, it works perfectly now! I also see the new documentation, I'll look into it further as soon as possible.

    Leave a comment:


  • Isomorphic
    replied
    Ah, yes, sorry about that - we've been finalizing and documenting how the StockIcons system works.

    1) You can fix your issue by changing the isc.Media.useMedia() call in the load_skin for your custom Shiva skin

    Code:
    // this will use the stockIcons.svg from the skin
    isc.Media.useMedia("svg");
    
    // or, if you want a different style or weight, these will come from the central
    // repo at [HELPERS]media/svg/stockIconSets
    
    // use the same icons as the Shiva stockIcons.svg, but from the central repo
    isc.Media.useMedia("svg:400:outlined")
    
    // heavier weight and filled style
    isc.Media.useMedia("svg:500:filled");
    2) we've now exposed and documented the StockIcons system - please scan the 13.1 docs for "StockIcon" and let us know if anything isn't clear.
    Last edited by Isomorphic; 26 Sep 2024, 22:18.

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by claudiobosticco View Post

    Unfortunately, I still see the problem using my custom skin based on the build from 5th of August.
    I think the problem is related to this warning I see with my custom skin:

    Code:
    *16:27:18.665:WARN:Media:Unknown iconSetName: svg_materialSymbols

    Leave a comment:


  • claudiobosticco
    replied
    Thanks, I see the fix using Shiva skin.

    Unfortunately, I still see the problem using my custom skin based on the build from 5th of August.

    The optimal solution for me would be a fix for this problem: https://forums.smartclient.com/forum...ployment/page2

    so that I can update my custom skin without even bother what's changed.

    Otherwise, I'll have to look for changes and do a manual update.

    Leave a comment:


  • Isomorphic
    replied
    hi Claudio - this general regression has been fixed for tomorrow's builds, dated September 23 or later.

    Leave a comment:


  • Isomorphic
    replied
    Thanks Claudio, we'll take a look today and let you know when things have been fixed.

    Leave a comment:

Working...
X