[Cuis-dev] Icons with path sequence in vector graphics

Thu Jun 25 01:25:49 PDT 2026

This one is a bit better (just changed an ugly line of code leftover from
experiments)

On Thu, Jun 25, 2026 at 3:16 PM Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> Hi Juan,
> Thanks for the detailed explanation of the rationale behind your design. I
> was considering using TTF icons, but then I thought it was going to be
> annoying to have to work with arbitrary code points instead of the actual
> fonts, or would require a global mapping name -> icon/codePoint that I also
> didn't like much, so I followed your suggestion of doing this instead of
> TTF fonts and now I see it's much cleaner and simpler.
>
> I'm still not sure, but at this point I feel that we don't really need the
> reified PathCommands (or perhaps they just belong to the SVG package), I'd
> prefer to use literal Float32Arrays directly if we added support for the
> rest of the commands. BTW, regarding #[], I'd like to suggest to change it
> to create Float32Arrays instead of Float64Arrays... apparently all the
> current use cases end up converting them to Float32Array anyway, and for
> that they use two syntactic suggars: #[] and the backtick, it would be
> simpler if #[] produced Float32Arrays instead...
>
> Here's an example of an IconMorph, not necessarily the best implementation
> but it shows the idea, you can test it like this:
>     IconMorph new pathData: 'M240-200h120v-240h240v240h120v-360L480-740
> 240-560v360Zm-80 80v-480l320-240 320 240v480H520v-240h-80v240H160Zm320-350Z'
>
> Cheers,
> Luciano
>
>
> On Wed, Jun 24, 2026 at 8:57 PM Juan Vuletich <juan at cuis.st> wrote:
>
>> Hi Luciano,
>> On 2026-06-24 9:12 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>
>> Got it, in a few lines of code I can fully convert path data in that
>> compact standard format to a list of PathCommands, and then I can just
>> compose with a transformation for a given height and position and draw it.
>> Works great!
>>
>> Good. Glad it works ok.
>>
>> Juan, perhaps we should extend VectorEngine>>pathSequence: to support all
>> commands? Or your idea is to convert other commands to this reduced subset
>> (like converting arcs to a list of bezier curves I guess, etc)?
>>
>> Let me tell a bit about my thoughts when originally writing this stuff.
>>
>> There's the choice between reifying the path elements vs just making them
>> calls. PathCommand is a reification of the canvas API. I wasn't sure
>> whether it would be the preferred way.
>>
>> Then, for things like #drawHandLarge I preferred to find a more
>> performant and memory efficient way to do it, even if less elegant.
>> Remember we're coming from BitBlt, where everything is very compact and
>> super fast. So I did #pathSequence:, packing everything in a (preferably
>> literal) FloatArray. But Arcs, like in
>> #arcCenterX:centerY:radiusX:radiusY:start:sweep:rotationCos:rotationSin:
>> need trigonometry, that is slower than basic arithmetic, so I left it out.
>> You can see in the comment at #pathSequence: that I was worried about
>> performance of trigonometric functions. I guess the cost of trigonometry is
>> dwarfed by the cost of the actual rendering. Maybe we should add them after
>> all.
>>
>> See #drawHandLarge. I found it rather easy to write the FloatArrays
>> manually. It is not really different from the SVG way. Still, I understand
>> that the icons font shows that we do need to support the SVG way, and not
>> just manually writing the FloatArrays. But backtick compile time
>> expressions may be used to turn the SVG like commands into literal
>> FloatArrays for performance. We get convenience and performance. If you do
>> this:
>>
>> - You'd leave out the geometry transformation of the literal FloatArray,
>> and apply it on each call (usually by giving each transformation its own
>> morph to hold it, or we could extend the canvas api if needed). This is of
>> course to build a single literal FloatArray for each widget.
>>
>> - I guess this could be done with little code taking advantage of
>> SVGPath>>#buildFromXml:defs: in the SVG package. But it would make this
>> code dependent on SVG. This also shows there are repeated ideas between
>> PathCommand and SVGPath. Some consolidation could be in order... Food for
>> thought.
>>
>> So, the choice is between your likely clean and nice code for turning the
>> SVG like spec into PathCommands, and a more complicated but potentially
>> more performance use of #pathSequence:. #pathSequence: may be worth it if
>> there is a large number of icons, and many are displayed at once.
>>
>> Still, turning them into #pathSequence: FloatArrays at compile time is
>> worth doing.
>>
>> In any case, your code for this will be useful in many other scenarios.
>> Please consider making it a separate package, part of SVG, or part of the
>> base Cuis image!
>>
>> Please keep the discussion going. This could lead to better code in base
>> Cuis and/or packages, not just your great app.
>>
>> Thanks,
>>
>> On Wed, Jun 24, 2026 at 2:27 PM Luciano Notarfrancesco <
>> luchiano at gmail.com> wrote:
>>
>>> I've been making my own buttons, knobs, pulldown lists, etc... all sorts
>>> of widgets. Some of them draw text, like the label on a button, and I'd
>>> like to add optional monochromatic icons. For the sake of simplicity, I'd
>>> like to just set the icon as path data, something like this:
>>>     M784-120 532-372q-30 24-69 38t-83 14q-109 0-184.5-75.5T120-580q0-109
>>> 75.5-184.5T380-840q109 0 184.5 75.5T640-580q0 44-14 83t-38 69l252 252-56
>>> 56ZM380-400q75 0 127.5-52.5T560-580q0-75-52.5-127.5T380-760q-75 0-127.5
>>> 52.5T200-580q0 75 52.5 127.5T380-400Z
>>>
>>> I got this from https://fonts.google.com/icons , there you can search
>>> the icons you like and click on the image of the icon to copy this path
>>> data to the clipboard.
>>>
>>> Then, say it is the icon for a button, the button morph can draw it
>>> scaled depending on the morph height, or on the line spacing of the font
>>> used for the label. Seems the simplest solution to me, and it would be just
>>> one or two lines of path data when creating the button.
>>>
>>> My question is, how do I represent this in Cuis? There is PathCommand
>>> and subclasses, but it's not used anywhere in the base image or packages, I
>>> didn't find any examples. There's also VectorCanvas>>pathSequence: in a
>>> different format, more limited (only supports commands M L C Q, I think).
>>>
>>> What's the correct path for this? What do you suggest?
>>>
>>> Thanks,
>>> Luciano
>>>
>>>
>> --
>> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260625/a23e5d52/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IconMorph.st
Type: application/octet-stream
Size: 2543 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260625/a23e5d52/attachment.obj>