I'm trying to use Fidget to build some stuf but I have great difficulty understanding how the layout is supposed to work. I looked at Figma, but I fail to match the concepts to Nim code...
From what I understand, you can specify a few things:
- box defines the bounding box (x, y, w, h) where the component will be drawn
- size seems to define width and height only, how does it differs from box with x and y set to 0 ?
- orgBox that seems a mystery to me
- constraints define horizontal and vertical constraints. Except for min that takes the size defined earlier, I don't understand how this works
- layout allows you to auto layout similar to a CSS flexbox (without the wrapping)
- layoutAlign for both horizontal and vertical alignment seems to make sense in the context of vertical and horizontal layouts, it probably does not need much explanation
- itemSpacing seems to put space between items in a layout
- horizontalPadding and verticalPadding seems to pad within a layout
Does anyone have any hints on what's orgBox, how does the constraints works and how size is different than box ?
Reading the code of the constraints:
- min: does the minimum, seems to keep the original size and position
- max: translate the component further of parent_box_size - parent_orgBox_size
- scale: scale the position and the size of the box of the parent_box_size / parent_orgBox_size factor
- stretch: resize the component by adding to it parent_box_size - parent_orgBox_size
- center: translate the component to the center of the parent box with an offset made of the component orgBox position added to half of the difference between the component orgBox and the parent orgBox
Everything seems related to this mysterious orgBox...
Thank you
Heya, I've been doing a lot of work with Fidget. Hopefully I can answer a few questions. Though I honestly still don't fully grasp the constraint system in general. As you say, it's like the raw computations for CSS flexbox.
In Fidgetty I've wrapped parts of the constraint system to automatically handle things like Vertical layouts. Those are mostly just helpers for layoutAlign which are pretty straightforward.
box defines the bounding box (x, y, w, h) where the component will be drawn > size seems to define width and height only, how does it differs from box with x and y set to 0 ? > orgBox that seems a mystery to me
The Fidget layout works on a relative layout model. The box call sets that relative position using the x/y parts and the size using w/h parts. For convenience size is literally just a convenience wrapper for box 0, 0, w, h since many widgets you just want to build off their base position but set their width & height.
Does anyone have any hints on what's orgBox, how does the constraints works and how size is different than box ?
orgBox sets the "original constraint box" as I understand it. The layout system uses the difference from the node's current box to the orgBox to adjust the layout based on the cMin/cMax/cStretch/etc functions. So effectively you "set" the original layout where a your node's are like say 25% from the top, then as box changes it'll retain that relative positioning (or min of that, or max, etc).
- min keeps the size and aligns the item to the start
- max keeps the size and aligns the item to the end (of a container which width is the parent box width added to the parent orgBox width and which height is the parent box height added to the parent orgBox height)
- center keeps the size and aligns to the center
- stretch keeps the distance specified between its box and the parent orgBox (beginning and end) and stretch the inner component, to the same size of the max above
- scale seems to move the component out of view, I cannot find it...
What seems really strange is that when you specify a box of 200, 200 and an orgbox of 400, 400, you get a container which size is 600, 600, that means that you are always overflowing the container... Even when not secifying orgBox, the stretch constraint overflows.
I don't use orgBox in user code. orgBox needs to be exported for templates to work though. You should not use orgBox in your code too.
Always use box to define your nodes. As process of laying out their box changes so I need to store the original box some place.
I think a lot of layout stuff in Fidget would make sense you try them in Figma first:
On first pass box = orgBox, but then compute layout might move or stretch the box to be some thing else based on new text, new parent, new child nodes ... etc. So box will no longer be orgBox.
Instead of defining left or right margin like you would in CSS, you simply define how your UI looks normally and some rules to apply when it stretches.
Instead of saying some thing like leftMargin = 50 (and layout system picks the x) you make it be located at x = 50 and set min constraint on the x so that it sticks to the edge.
Basically every node must have x,y,w,h defined then constraints are kind of attached to the edges on what to do if stuff stretches.
Fidget UI is meant to be drawn in a program like Figma first. Then constraints, layout are applied to it. It's not like almost everything else out there CSS/wxWidgets/etc...
Ah, the Figma origin makes sense for the constraints model. And that it's not really meant for manual usage.
It's definitely different than CSS/wxWidgets/etc. Reminds me somewhat of the old QT widget days where you'd draw your UI with an base size & position in the QT Designer and then use springs to say which way to stretch when the layout changed.
It's my belief that we can do better than making UIs in code. Thats why I strive for a UI based designer approach.
In 70s, we would draw graphics in code, but today we use image tools like Photoshop. In 80s, we would play sound in code, but now we use sound tools like Ableton. In 90s, we would render 3d objects in code too, but now we use 3d tools like Blender.
Its odd to me why we don't use 2d UI tools directly in development.
@elcritch I think it would have made more sense if I called them add "left sprint" or "left constraint" instead of cMin... I will think about this.
448 / 5 000 Résultats de traduction hello, I made a tui, we can code, but I immediately got down to making a designer, it simplifies a lot, and modifying the code is more understandable. Full of goodwill that emerges with interesting libs, but there is no "designer" and we have to spend a lot of time to swallow and get into the designer's head, even if it's clean code, and sometimes give up, because it becomes unproductive.
sorry my english
hello, I made a tui, we can code, but I immediately got down to making a designer, it simplifies a lot, and modifying the code is more understandable. Full of goodwill that emerges with interesting libs, but there is no "designer" and we have to spend a lot of time to swallow and get into the designer's head, even if it's clean code, and sometimes give up, because it becomes unproductive.
sorry my english
@mildred thanks for the descriptions of the constraints. It helped me.
The "no code" vision for UIs makes sense. I tend to think there's two categories of UIs: option a) polished UIs normally user facing and focused on making a polished UX for those end users and likely have multiple people working on it, or option b) one-off UIs or basic enterprise apps where a programmer just wants/needs a very simple way to make a good-enough UI with a few lines of code. Your vision seems to overlap more with option a, but I tend toward option b.
However I think Fidget has a large overlap with both! If the code looks more like data format like YAML or Figma code then it's possible to edit code _as data. It makes either case much easier to work with. It'd be even better if there was an easy path to go from quick-and-dirty prototype code to a polished UI hand crafted using Figma. In my experience most UI framework force one or the other since they're either closed widget systems or completely free form (either you get Qt Widgets or you get Qt QML and it's hard to mix).
@treeform if you figure out a mapping to spring like naming model that might work well! I also tried making an autoOrg template that stored the box rect on the first node render, but that didn't quite work. :/ Though I've been pondering a computedOrgLayout: type macro that'd handle computing the original "static" layout using basics like percent width of parent, or em's but only on the first layout.
If I understand correctly, you're saying a UI Designer makes it easier to modify someone else's UI.
I'd agree, though I'm hoping that composable widgets and the YAML like syntax would make it much easier.
Though I've been pondering if I could make an editor for Fidget/Fidgetty widgets that'd let you interactively edit the position, sizes, of nodes. Perhaps not let you add click handlers, but usually the hard part is just the UI layout IMHO. Another option would be to provide a nimscript wrapper that'd let you edit the code in real time and then compile the final version later.