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

Thu Jun 4 11:56:03 PDT 2026

Hi Milan,

On 2026-06-04 1:46 PM, Milan Lajtos via Cuis-dev wrote:
> 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.

Good. Please re read my last sentence above. In order for you to be able 
to improve Cuis (and not just fork it into a separate project), we need 
a sane communication. I hope we'll get there.

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

"non-existent" and "not 100%" are completely different things. This is a 
fresh Cuis image using the default font. I don't claim it is "100%" but 
it is not fair to say "non-existent" either.

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

Yes. Something like that can be done.

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

Good.

>
>> 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
>
>
>
-- 
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/131c8751/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: someemoji.jpg
Type: image/jpeg
Size: 159074 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260604/131c8751/attachment-0001.jpg>