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

[Milan Lajtos]

Hello Juan!
> 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.
> 
My aim is to improve Cuis – part of that is pointing out the bad parts while fixing them. If I don't know how to improve something, I tend not to criticize. The hard fact is that emoji support is currently non-existent – and that is okay! Maybe there is someone that is into emojis and will fix it. But without an explicit information that emoji/TTF support is not 100%, how can we know what is a problem?

"Obsolete the damn thing!" is a direct quote from Alan Kay about Smalltalk.

The video has an explicit "May 2026" badge, and comments are open. My understanding of things will improve, which is a great segue to...

> 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.
> 

I read up on the scaling problem. From what I read, I assume that the your intention is to have UI that has dimensions based on the font size. So when you increase the base font size, the UI scales with that. And font size takes `hostOSScaleFactor` already into account.

Which means to create a rect around the text, e.g. a button, you are setting the padding that has some fraction of line height, which is some multiply of font size. This becomes tangled pretty fast.

The more direct approach is to factor out the font size. That way you can use points (logical pixels) for the size of UI (including the font size) and have independent "zoom factor" that can be user-definable. And then the system would compute size of 1pt as `hostOSScaleFactor * zoomFactor` in physical pixels.

This is just describing what is sometimes called "density-independent pixel" (dp on Android), or "effective pixel" (epx on Windows UWP). On Apple platforms it is just called "point". The independent zoom factor corrects for inability to know physical dimensions of the screen and viewing distance. So you can tune the base font size to be ~0.33°.

> 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.
> 
Keeping the API small is great! Blend modes are complementary to alpha blending. When I was designing semi-transparent menus, I wanted to increase the contrast against background, while keeping the opacity intact. Why blend modes are useful: https://www.makingsoftware.com/chapters/blending-modes

Gradient fills (linear, radial, mesh, etc.) are ubiquitous in visual design. :)

> 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.
> 
Oh, the filter width is configurable! I am gonna play with it.. Thank you for the pointer!

> Most likely this is a bug in your code. Read the 'Note:' in class comment of BoxMorph. Read the comments at #submorphsMightProtrude.
> 
Will take a look, thank you.

> 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.
> 
Thank you. I might pick some of these up when I can't go further without them.

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


Milan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260604/3d1ec8f7/attachment.htm>