[Cuis-dev] Fwd: Blueprint – May 2026 update

[Juan Vuletich]

Hi Milan,

(inline)

>
> Hello Juan,
>
> thank you for your kind words. Live demo is always the best showcase 
> of some work. Though I will do better job at narration next time. 
> Personal target = zero filler words. :)

If you ask me, filler words are OK. Not everyone needs to be an absolute 
pro at presentations.

What I think is more important, though, is to be careful with the 
assertions made. Youtube keeps videos for a long time, way long after 
any context is lost. Talk that suggest Cuis not having usability, not 
supporting emoji, calling it "the damn thing", etc. will be taken 
literally by many. The best place to be harsh is here. Being polite is 
welcome, but if someone is not polite in the mail list, they will get an 
appropriate answer, that will also be part of the thread in the archive. 
No harm done then. But in media where context and responses may not be 
available, and may reach a wider uninformed audience, it is best to be 
careful with words.


>
> One thing that really bugs me (and I can't seem to find a definitive 
> answer) is the `DisplayScreen hostOSScaleFactor` usage. Since I am 
> designing in Figma, all pixel-sized values (extents, insets, stroke 
> widths, corner radii, gaps, padding, font size, line height, etc.) 
> have to be scaled by that factor. Example:
>
> ```smalltalk
> initialize
>     | s |
>     super initialize.
>     s := DisplayScreen hostOSScaleFactor.
>     cellSize := 64 * s.
>     cornerRadius := 16 * s.
>     padding := 8 * s.
>     ...
> ```
> This feels very, very wrong. I would expect `world scale` (or some 
> other approach) to do that automatically. Hm, I'll try that.

Well, of course the root problem here is that we don't have any 
indication of the real size of the pixels we're given. So we should 
improve, but we don't have real guarantees of what "ten pixels" really 
mean. For instance, set Cuis to Full Screen and the compare `Display 
extent` with whatever the OS says about display resolution, and with the 
phisical specs of the display. Apple made a big mess here. And AFAIK no 
desktop OS has a good api to query what's the actual size of a pixel.

In any case, using #hostOSScaleFactor seems reasonable. One way is do 
what you did. Another one is to scale your morphs, perhaps when opening. 
Another is what most Cuis tools do, call `FontFamily defaultPointSize` 
to adapt size of elements to user preference. Scaling the whole world is 
possible too, although we generally prefer to size elements with 
`FontFamily defaultPointSize`, and drawing a scale = 1. This gives best 
drawing performance.


> —
>
> Thank you for fixing the switched hyphen and dash!

Thanks for bringing up the issue! The fix will be useful to many.


> —
>
> Gradients and blend modes: I found that blend modes are available only 
> via BitBlt, not Vector Engine. Are gradients and blend modes something 
> you think would be useful?

I tried to keep the API small and relevant, and expand it as needs 
arise. I think that blend modes are not really necesary if we handle 
transparency of stroke and fill colors correctly. Do we have a use case 
for a "blend mode" feature?

WRT gradients, something similar happens. They are part of the SVG 
standard, but they make everything look like it is over 20 years old and 
they are not very used nowadays. Is there any actual need for them? I 
think having textures would be much more useful and interesting.


>
> —
>
> I am not going to comment on rasterizer output as I haven't understood 
> the pre-filtering paper yet.

No real need to read the paper, although it is good to read it. All you 
need is to render the same SVG file with Cuis and any other renderer and 
compare.

The filter widh used is configurable. Edit 
VectorEngineWithPluginWholePixel >> #defaultAntiAliasingWidth, then 
resize the main Cuis window for the change to take effect. Instead of 
1.6, something like 4 will be much smoother. Try 1.2. It still won't be 
too pixelated, but it will be closer to what other renderers do. 1.0 
will be still crispier, but pixellation starts to be quite visible.

Play with the VectorEngine 'experiments' class side methods.

If you're really interested in this stuff, after a quick read of the 
paper you can start hacking VectorEngineSmalltalk. I promise you'll have 
a lot of fun.


> —
>
> I think code for `spanBottom` has a bug:
>
> ```smalltalk
> !VectorEnginePlugin methodsFor: 'accessing' stamp: 'jmv 3/10/2021 
> 10:53:54'!
> spanBottom
> self
> primitive: 'primSpanBottom'
> parameters: #().
>
> ^(spanBottom + auxStrokeWidthDilatedHalf) asInteger asOop: 
> SmallInteger.! !
> ```
>
> Compare that to `spanRight`:
>
> ```smalltalk
> !VectorEnginePlugin methodsFor: 'accessing' stamp: 'jmv 4/6/2021 
> 16:13:38'!
> spanRight
> self
> primitive: 'primSpanRight'
> parameters: #().
>
> "Make room not just for updated mask, but also edges (hence, +1)"
> ^(spanRight + auxStrokeWidthDilatedHalf + subPixelDelta) asInteger +1 
> asOop: SmallInteger.! !
> ```
>
> Bottom edge (the anti-aliased pixels) of the Dock was being cut off, 
> and I traced it to that method. I can't really tell if "+1" in 
> `spanBottom` is intentional omission or not.

Most likely this is a bug in your code. Read the 'Note:' in class 
comment of BoxMorph. Read the comments at #submorphsMightProtrude.


> —
>
> I think that is a lot of questions for today, thank you for taking the 
> interest.

A few further notes:

- Font subtitution: Yes. We need this. If someone volunteers to work on 
this they will have by full support.

- Shadows and Vector Feathering. If someone is interested enough to work 
on it, it could be done.

For other issues mentioned in your video, you may bring them up here 
anytime.


>
> —
>
> The main contribution of Blueprint should be non-code in nature. 
> Rather, to show that software revolution is happening (code agents) 
> and Smalltalk is the ideal vehicle for it. I put together this short 
> guide – 
> https://gist.github.com/mlajtos/e6f86323507ed30877b35f9f1f64fb37 – to 
> bootstrap the Claude Code – Cuis bridge, so anyone can leverage this. 
> (Please report any issues you have with it.) I bet real Smalltalker 
> can do wonders with it! Think cheap massive refactorings, automatic 
> Smalltalk to Slang translation, recovering borked images, easy 
> enriching Smalltalk class environment – new data structures, 
> algorithms, systems, etc.
>
> For hot-air balloon sky is the limit. Smalltalk with code agent is 
> more akin to space-faring rocket. Please adjust your ambitions. :)

I'm sure many people will have a lot of fun with this. Kudos.

Cheers,

-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260604/c42a1fe4/attachment-0001.htm>