add lifecycle figure

[elcritch]

No description provided.

[derek-v-s]

What does the preNode step refer to? And what's the condition were initialize is skipped? When the user has used onInit?

[elcritch]

What does the preNode step refer to?

The preNode step ensures a child node has been allocated and setup. If the node exists it just preps the node for drawing. It’s called whenever a child widget’s new block is called such as Rectangle.new “rect”: inside another draw method.

Maybe I could rename preNode and preDraw now that the design is settled? Initially I wasn’t sure what they’d do. Maybe call them something like createChildNode (preNode) and setupNodeDraw (preDraw).

And what's the condition were initialize is skipped? When the user has used onInit?

Both initialize and doInit are only called once after a node is first created (allocated). Then a node flag NfInitialized is set. Actually doInit is just an if block that checks that flag. :)

When a node is newly created (allocated) then any doInit blocks will run during the preDraw stage. After that any connected initialize methods will be called.

Finally the draw method for the node’s type will be called.

Thanks, I want to redraw the chart again to emphasize that these all occur whenever a node is refreshed.

[derek-v-s]

After reading this and having Gemini fill in a few more gaps for me, I think I'm starting to understand. And... WOW! I'm impressed by this system and the work you put into it! 😎

[derek-v-s]

Renaming preNode would probably help. Even more so would be some form of documentation stating that:

1. The code you write inside Widget.new "name": ... becomes a preDraw callback.
2. onInit: sections within it are special and their content is executed during the doInitialize phase (once per widget lifetime), along with Widget.initialize.
3. The rest of the code (direct property settings like fill this, ...) in your Widget.new block is executed every time this preDraw callback is called (which is right before the widget's own draw slot, as part of the doDraw signal).

Assuming that is accurate... ;-]

[derek-v-s]

The idea of separating user documentation from developer documentation popped into my mind again. This seems more developer oriented. Do you want to make the main README be user oriented? If yes, do you want to have the wiki be developer oriented? Or do you want that to also be part of the repository, as say a separate src/README? Maybe that and the Wiki could be mirrored.

Reasons for using the Wiki:

• easier to edit without needing to use git
• no commit log entries
• more structured than a README

Reasons for using a README:

• allows for local/offline documentation
• documentation travels with the source code

[derek-v-s]

See → /docs, jekyll, and github pages

[elcritch]

The idea of separating user documentation from developer documentation popped into my mind again. This seems more developer oriented. Do you want to make the main README be user oriented? If yes, do you want to have the wiki be developer oriented? Or do you want that to also be part of the repository, as say a separate src/README? Maybe that and the Wiki could be mirrored.

It depends if you mean developers using Figuro? Regular non-developer folks wouldn't be direct users of Figuro. Still ideally the diagram would be user oriented. Perhaps it's more advanced user oriented. It can be helpful to describe what the lifecycle of a basic widget is for most devs.

I'd generally agree on your other points. Though I'm still less focused on the wiki currently, as on finishing the core widgets and fixing inset shadows. I like glossy buttons. ;)

If you're game on helping making docs and organizing them I'm game! I'll probably have more brain space for it in a couple of weeks as well.

[derek-v-s]

By developer I meant someone like you or me, working on figuro. There is plenty of information that a developer could benefit from having documented, that the toolkit user does not need to know.

If I'm someone looking for a GUI toolkit to build my next app, this diagram might be too much information. Or it might not be, but at the same time, it's not what I need to see in an introduction, which is generally my idea of the purpose of a README. If I'm not convinced in the first couple of paragraphs, I'm never going to read the rest.

I'd make the README short but rich

• with an opening such as https://github.com/elcritch/figuro/wiki
• one quality example with inline comments
• a screenshot of that example
• information about installing
• and the rest is a table of contents / links pointing to more information / resources