This is something I really want to have supported properly in bWidgets. Blender doesn't support it at all right now, adding it would probably be a bit hacky.

• Layout system needs to consider dynamically sized widgets.
• The font interface needs to support queries to get the total multi-line font height.
• Add multi-line text editing box, with a fixed height and content scrolling.

Some C++ specific additions were recently made to the Blender code style

• Member variables at the top of classes.
• General class layout.
• Member variable _ suffix.
• Nested namespace syntax: namespace bWidgets::Something {} over namespace bWidgets { namespace Something {}}

Work on this is ongoing in the reconstruct-on-redraw branch.

After all I decided it's best for Blender/bWidgets to keep the declarative construction of layouts Blender currently uses. In such a design, buttons can be dynamically added like this:

if (some_condition == true) {
  create_button();
}

That is different from the more imperative layout creation, where the individual layout elements have to be permanently stored and you explicitly manage their state (e.g. hide/unhide). Doing so is quite complex, which is why modern frameworks use declarative construction where the UI code only represents the current state of the application (see React, Flutter, SwiftUI, etc.).

For the declarative layout creation to work, the entire layout has to be reconstructed on every redraw. bWidgets will have to make sure the state of individual widgets is kept over redraws, even if they are reconstructed. It's important that widgets can be unambiguously identified for this. Other toolkits do this with identifier names or such, I think we should keep doing what Blender is doing, which is identifying widgets by comparing the data they store. Edit: In fact, there may be better ways to do this. Needs more design work and experimentation.

• Reconstruct the screen-graph on every redraw. -- (35b385c)
• Add system to keep persistent widget references (as in, automatically updated when screen-graph is reconstructed), so state can be kept over redraws -- (a653c8e)
• Add some kind of identifier to widgets that don't refer to other data (e.g. scrollbars) that can be used for finding matching widgets across redraws.
• Keep state of persistent widgets over redraws.

Windows 10, VS2019

bwidgets/screen_graph/Iterators.h
bwidgets/screen_graph/Iterators.cc

demo\screen\DefaultStage.cc(135,1):error C2280: “bWidgets::bwScreenGraph::PreOrderIterator::PreOrderIterator(const bWidgets::bwScreenGraph::PreOrderIterator &)”

demo\screen\Stage.cc(159,1):error C2280: “bWidgets::bwScreenGraph::PreOrderIterator::PreOrderIterator(const bWidgets::bwScreenGraph::PreOrderIterator &)”

bWidgets currently doesn't support icon drawing.

There shouldn't be much involved on the bWidgets side, here's what we could do:

• Add a bwIcon class containing a bitmap
• Add something like bwWidget::setIcon()
• Add a bwPaintEngine::drawBitmap() to draw the icon bitmap

Would also be good to support drawing Blender icons in bWidgets, although I'm not too sure how that could work. Maybe just copy the .c files output by datatoc? Think we'd need PNG reading support then.

In Blender we support drawing different font sizes for different widgets. E.g. the default panel font size is 12 pt while the size for general widgets is 11pt. We could also support CSS font properties per widget then.

Of course, the font specific logic should not be within bWidgets. It should have some interfaces instead, for example:

• bwAbstractFontEngine
  Interface to manage font faces. We may not even need this to be in bWidgets itself.
• bwFont
  Base class for querying and manipulating font information (e.g. setting font size or calculating string width). Should probably be abstract too.
• bwDisplayText
  A simple data structure combining the final (encoded?) string to be drawn, a reference to the font to be used and decoration hints (e.g. underlines, accelerator key indicator, etc). Together with the painter that contains all remaining info (current color, boundaries, alignment, etc.), all information needed for drawing should be there.
  So the function for drawing text could look like this:
  bwPaintEngine::drawText(const bwPainter&, const bwDisplayText&)

Note that I don't intent do go crazy with Blender's font drawing capabilities. Every font variation to be drawn adds some costs (typically memory usage due to glyph texture caching). The plan is to get reasonable flexibility supported in the bWidgets code design, Blender can still dismiss that.

The following widget types need to be supported in bWidgets:

• Label
• Toggle button
• Check-box
• Radio button
• Number button
• Number slider
• Push button
• Tab
• Text field
• Menu button
• Pulldown button
• Menu background
• Color swatch (color buttons)
• RGB picker
• Vector/normal widget
• Background-box (see uiLayoutBox)
• Scrollbar
• List-item
• Progress bar
• Separator line
• Panels

There are a few things to be considered:

• Although basic drawing of the checked items is possible, they are not fully featured yet, e.g. scrollbars don't support frame indicators yet, icons aren't supported at all.
• How will menu items be handled? Just push buttons drawn in a different style (like transparent background, white text and such)?
• Pie menus will probably end up being an own widget type with a radial layout. Some buttons will be styled differently in these.
• Icon-only buttons (like the Blender icon in the Info Editor) will probably also just be variants of other widgets using a different style.
• In bWidgets, panels are regular widgets. In Blender they aren't so they will need special care. That means, we'll have to rewrite good chunks of the panel code to make it part of the regular widget pipeline through bWidgets.
• The usefulness of the vector/normal widget is arguable. We may want to get rid of it or replace it.

Style management is limited and needs rework. Each style currently needs its own class (deriving from bwStyle) and styles are registered statically, meaning their creation is hardcoded into bWidgets.

Requirements

• Uniquely identifiable styles
  Every style should be uniquely identifiable.
• Support custom styles
  It should be possible to define styles outside of bWidgets, independent from the builtin ones. That's crucial to support custom themes in Blender.
• Support both, style sheet based and hardcoded styles
  For performance reasons, it makes sense to keep the default Blender styles hardcoded in C/C++. So styles can't just be limited to be style sheet based.
• Manipulate all styles via style sheets
  All styles, even if hardcoded (as in, defined in C/C++) should allow manipulating their properties via style sheets. So even the default Blender theme could be adjusted with a CSS file.
  We can expect that many themes wouldn't be created from scratch, but based on existing (default) ones. So this should be heavy on performance.
• Support per-window DPI scaling
  In Blender it's possible to have different windows use a different DPI setting (AFAIK), bWidgets needs to account for this. It's a bit unclear how it will work (generally, widgets shouldn't care about the window they are drawn in), but probably we will manage this through styles. Blender would simply update the style-wide DPI setting before drawing.

Ideally, a style could completely override how a widget is drawn (e.g. switch from Blender style number buttons to more typical ones). Supporting this can be difficult however, so let's keep it a "nice to have" feature for now, not a requirement.

Although basic drawing of widgets works fine, there are some "extras" that still need to be supported:

• Widget emboss
  We may instead add general support for drop shadows. This can then be used for the emboss effect.
• Underlined characters (Accelerator Keys)
• Tinted background
  In Blender, colors of widgets may be tinted, e.g. when animated, driven or while multi-editing. This needs to be supported in bWidgets too.
  The best way to do this is probably through styles again. However, we can't just make this another state, since the regular states (normal, highlighted, sunken) still have to work while a widget is tinted. Thinking about it in CSS selectors, maybe make it a class? - bwNumberButton.animated::hovershould work, although you'd have set colors for all states and all possible tints. Or maybe keep it bwNumberButton.animated and extend CSS to support tinting the current value?
• Text shadows
  Drawing text with shadows should be supported, the current Blender theme system uses that.
• Separation between panel header and panel content
  There should be some visual separation between a header panel and its content, e.g. see https://ui.pablovazquez.art/.

When adding a style-property (bwStyleProperties::addBool(), bwStyleProperties::addFloat(), etc.), uniqueness of that property (based on its identifier) is not checked.

Issue is, the add functions return a reference to the added property, we can't just return nullptr on failure. I would really like to have something like bwOptional in bWidgets, behaving similar to the std::optional added in C++17. Then, the add functions could just return an bwOptional<bwStyleProperty&>.

The way data is manipulated after interactions in the demo application is quite ugly and not representable for how a normal application would do this. bWidgets was designed for a different approach. It's simply a bad/misleading demo.

Currently, for every widget that's supposed to modify data in some way, we have to add a new functor class (!), create an instance of it and assign it to bwWidget.apply_functor. However, most of these classes do very similar things which could be generalized with the help of a simple property system. Such an approach is much more like what bWidgets was designed for.

The following features are needed:

• Defining properties of different types (booleans, floats, enumerations, etc.).
• Setting min/max values of numeric type properties.
• Custom set and/or update callbacks for properties.
• Maybe useful to test tooltips in the future: Setting a description for each property.

So basically a quite simplified version of RNA.

Then we can add generic functor classes to manipulate these. Also, we can try how screen-graph builders specifically for such properties would work. This idea seems to have quite some potential.

There should be some kind of reusable system to edit text. That includes cursor navigation, cancelling, copy & paste, multi-line editing support, etc.