double click, long tap, and friction

dvui does not currently have built-in support for double-click, double-tap, or long-tap. My current thinking is that those interaction patterns are generally worse than the alternatives.

The general advantage of these is to have a second way to interact with a widget besides a normal click/tap. Otherwise you need a separate widget, or the widget be modal, or change depending on zoom level, or some other redesign.

The downsides are poor discoverability and accessibility. I’ve personally had the experience of trying to double-click or long-tap something, nothing happens, and I’m left unsure if it doesn’t exist or if I did the interaction wrong.

I’ve watched people with slight hand shakiness try to long-tap repeatedly but only ever get a touch-drag.

This is why dvui’s textLayout and textEntry widgets provide a modal touch interface. A single tap transitions between normal mode and selection mode.

They do have mouse-only 2-click word select and 3-click line select. Those are features that are useful to some while not requiring use by all.

How much should my opinions shape dvui’s design?

On one hand dvui must serve its users (developers) in providing the UI features they need and want.

On the other hand dvui should serve its users by making it easier to build good UIs than bad ones. Nobody wants a button that by default only responds to a triple-click.

My strategy is to make requested features possible, but use my experience to guide developers by making some features easier to use than others.

We see a similar strategy in Zig design, where the core team uses “friction” to guide developers - some patterns are intentionally left more awkward to use than others to discorage their use while not preventing it outright.

min_size_content is not the minimum

If the parent does not have enough space, child widgets get less than their min size.

What about max_size_content - can a widget get more?

Yes - if that widget is expanded, it can be larger than max_size_content.

min_size_content and max_size_content are both constraints imposed on the minimum size that dvui saves for each widget from frame to frame.

Why min_size_content?

To make it clear that padding/border/margin is added on top of that.

Why not just min_size?

This is an example of naming tension in API design.

When you want a widget to be larger than its minimum size (but not expanded):

.{ .min_size_content = .{ .w = 100, .h = 50 } }

We could make it shorter and easier to remember by using just min_size, but then you have to remember (or lookup) if that already includes padding/border/margin.

So min_size_content costs more characters but makes reading the code (especially for people new to DVUI) slightly easier.

Hard to know which way to go, but I think about stuff like this a lot.