<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="font-size:-apple-system-body">Hello Juan!<br><blockquote type="cite"><div><p>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.</p></div></blockquote><div>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?</div><div><br></div><div>"Obsolete the damn thing!" is a direct quote from Alan Kay about Smalltalk.</div><div><br></div><div>The video has an explicit "May 2026" badge, and comments are open. My understanding of things will improve, which is a great segue to...</div><div><br></div><blockquote type="cite"><div><p>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.</p><p>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.</p></div></blockquote><div><br></div><div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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°.</div></div><br><blockquote type="cite"><div><p>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?</p><p>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.</p></div></blockquote><div style="font-size:-apple-system-body">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: <a href="https://www.makingsoftware.com/chapters/blending-modes">https://www.makingsoftware.com/chapters/blending-modes</a></div><div style="font-size:-apple-system-body"><br></div><div style="font-size:-apple-system-body">Gradient fills (linear, radial, mesh, etc.) are ubiquitous in visual design. :)</div><div style="font-size:-apple-system-body"><br></div><blockquote type="cite"><div><p>
</p>
<p>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.</p><p>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.</p><p>Play with the VectorEngine 'experiments' class side methods.</p><p>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.</p></div></blockquote><div style="font-size:-apple-system-body">Oh, the filter width is configurable! I am gonna play with it.. Thank you for the pointer!</div><div style="font-size:-apple-system-body"><br></div><blockquote type="cite"><div><p>Most likely this is a bug in your code. Read the 'Note:' in class
comment of BoxMorph. Read the comments at #submorphsMightProtrude.</p></div></blockquote><div style="font-size:-apple-system-body">Will take a look, thank you.</div><div style="font-size:-apple-system-body"><br></div><blockquote type="cite"><div><p>A few further notes:</p><p>- Font subtitution: Yes. We need this. If someone volunteers to
work on this they will have by full support.</p><p>- Shadows and Vector Feathering. If someone is interested enough
to work on it, it could be done.</p><p>For other issues mentioned in your video, you may bring them up
here anytime.</p></div></blockquote><div style="font-size:-apple-system-body">Thank you. I might pick some of these up when I can't go further without them.</div><div style="font-size:-apple-system-body"><br></div><blockquote type="cite"><div><blockquote type="cite" cite="mid:2f04f5df-9333-4ee6-8eee-c217e6932415@cuis.st"><div class="moz-forward-container">
</div>
</blockquote><p>I'm sure many people will have a lot of fun with this. Kudos.</p></div></blockquote>I hope so!</div><div style="font-size:-apple-system-body"><br></div><div style="font-size:-apple-system-body"><br></div><div style="font-size:-apple-system-body">Milan</div><div style="font-size:-apple-system-body"><br></div><br></body></html>