<div dir="ltr"><div><br></div>Yes, I'll take a look at the widgets in Cuis-Smalltalk-UI and see if there's a way to fit it into that.<div><br></div><div>I just took a look at IconImporter and I'm not sure how to fit IconMorph into it yet, maybe you have a clearer idea. From the apps that use the IconImporter, do you usually need the icon as a Morph? or do you often need a Form instead of a Morph?</div><div><br></div><div>I see that you have IconImporter>>getMorph:, getMorph:ofSize:, and getMorph:ofSize:fill:, if instead of referring to the icon by a symbolic name you just use a path data string like in IconMorph class>>example1, I think you can do those same 3 things as: IconMorph new pathData: ...; morphExtent: ...; color: ... (although I'm not sure it's the same meaning of your fill: aColor, is it the foreground or the background?); and you can send to it imageForm and get a 32 bits Form for the other 3 messages getForm:, getForm:ofSize:, getForm:ofSize:fill:.</div><div><br></div><div>Another option would be to add a message 'addIcon: name pathData: aString' that renders the icon with the given path data and stores a form in the forms dictionary, but you would be losing the vector graphics.</div><div><br></div><div>Cheers,</div><div>Luciano</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jun 26, 2026 at 10:35 PM Hilaire Fernandes <<a href="mailto:hfern@free.fr">hfern@free.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 25/06/2026 à 10:40, Luciano Notarfrancesco a écrit :<br>
> Yes, I'll share my widgets, I should make a new package independent <br>
> from my app. Anyway, feel free to extract and use/change anything from <br>
> my packages.<br>
<br>
Try to blend your widgets in the existing class categories of <br>
Cuis-Smalltalk-UI then maintain them from there. This is what I did for <br>
the DrGeo widgets<br>
<br>
<br>
> Regarding your experience of slow drawing of vectorized icons vs fast <br>
> drawing of bitmap icons, I think that's not the case any more. Vector <br>
> graphics works really fast for me. For example, in the tracker I have <br>
> this big grid of text, and all the empty cells are the same,<br>
<br>
Possibly. I did not count that at the first instantiation of the <br>
circular toolbar (it has many icons), the icons are loaded from svg <br>
file, then cached as Form at the wished size.<br>
<br>
<br>
> something like '-- --- -- --- ---'. Typically you might have 100-300 <br>
> empty cells that need to be redrawn several times per second, and I <br>
> thought calling drawString: for each empty cell was going to be slow, <br>
> so I made a Form for this and I called image:at: instead. But later on <br>
> I realized it was slower than actually drawing the string. Perhaps I <br>
> made some mistake, but anyways drawing all the strings is super fast <br>
> and I removed the form cache.<br>
<br>
Yeah, sometime we want to optimize to early.<br>
<br>
> About the dictionary iconName -> icon, at this time I think I prefer <br>
> to just specify the icon with the path data string and avoid the <br>
> global registry of icons, it's simpler, keeps everything local. But I <br>
> have very few, perhaps it's different for a project like yours with <br>
> lots of icons. I recommend you to add support for path data strings, <br>
> tho, I love it, it makes it super easy to browse icons on the web and <br>
> copy and paste to Cuis.<br>
<br>
Yes, that's handy.<br>
<br>
Will there but use to add your way of doing with IconMorph in the <br>
Cuis-Smalltalk-UI IconImporter class. The idea of this class is to cache <br>
the icon when it comes from file (PNG or SVG).<br>
<br>
Hilaire<br>
<br>
-- <br>
<a href="http://mamot.fr/@drgeo" rel="noreferrer" target="_blank">http://mamot.fr/@drgeo</a><br>
<br>
</blockquote></div>