Hi @mantielero, good question and points. It's useful to have others comment as I don't know what's unclear to others.
Now that the widget model is mostly stable I'll probably start documenting it. It's a bit different from many GUI libraries but it still uses common patterns used in them all. > It is clear that widget needs to inherit from Figuro. But what is mainRect's > purpose and why is of type Figuro. Yes, all widgets must inherit from `Figuro` or existing subtypes like `StatefulFiguro[T]`. The UI is made up of `Figuro` nodes that represent basic UI elements. `Figuro` nodes have a standard `draw` slot that will automatically be connected. Widgets can declare their own `draw` slots which is where their layout is done. The `mainRect` is just a leftover while I was figuring things out. > I see that hasHovered will be true when EventKind is Enter. I think some > brackets would help the readability to more unexperienced programmers like me. Sure, I'll make it simpler. Note that I still consider Figuro to be in "development" phase and you'll need to be willing to dig in a bit as there's little documentation or often finished code. :) > Do slots need to have special signature? It looks like the first argument is > self: NewWidgetType, but I don't understand for instance kind: EventKind in > hover. Yep, signals and slots are typed. Slots take a `Figuro` object as the first argument with the rest of the arguments matching the signal you want to connect it to. > What is the purpose of refresh(self)? Is it always needed? If so, could slot > pragma take care of that? The purpose of `refresh` is for slots to notify the UI frontend to redraw the node passed to it. This will end up calling the `draw` slot for the given widget. It can't be done automatically since slots could do other things than update the UI. Note that Figuro is now event driven. Drawing only occurs when `refresh` is called. Events like `hover` and `click` occur before the draw stage. If you don't call `refresh` then you effectively ignore the event and the widget won't be re-drawn. > Where are rectangle, box, cornerRadius, fill, darken, spin coming from? From > pixie? button: it creates 5 buttons. What does captures do? There are a few default "widgets" like `rectangle` and `text`. `rectangle` is meant for generic rectangles similar to `div` in HTML. They're just plain `Figuro` nodes though. All the APIs that can be called directly like `box` and `cornerRadius` are part of Figuro and can be found at [figuro/ui/api.nim’](https://github.com/elcritch/figuro/blob/2e146694a58a340ab41829a22b9fcde9bf1d80a6/figuro/ui/apis.nim). APIs on colors like `darken` and `spin` come from [Chroma](https://github.com/treeform/chroma). Pixie isn't really exposed directly. > Regarding connect, I would state its signature: Agent, signal, Agent, slot. > By the way, current and self are not the same? Good idea. Nope `self` is a convention for the argument to the `draw` slot. The `current` variable is implicit to each widget used in the `draw` slot. > connect(main, onDraw, main, Main.draw): I understand that Figuro provides the > signal onDraw that with connect to the slot draw that we just defined. The `draw` doesn't need to be manually connected anymore. I just haven't cleaned them up quite yet. > connect(main, onTick, main, Main.tick): where is onTick defined? The signals used by Figuro are defined in [common/nodes/ui.nim](https://github.com/elcritch/figuro/blob/2e146694a58a340ab41829a22b9fcde9bf1d80a6/figuro/common/nodes/ui.nim#L98). The default slots are defined right after them. Any of the slots defined for a widget will automatically be connected using a compile time check. That's how `draw` and `hover` are connected in the examples. Generally custom slots will only be needed for custom logic when using a widget, like in `tclick.nim`. > It is not clear to me where is the appropriate place to connect. Could those > two connection be done before the instantiation? `connect` needs to be used on an object instance. Think of them as runtime connected methods but with static types.
