With this release we are probably seeing the end of the alpha-cycle. I have made major improvements to how child widgets are added, handled and accessed. With that, the whole framework now works and behaves much the way I envisioned several years ago. Read on to know more.

Scaling (Picture by TheDigitalArtist@Pixabay)

First of all I must say that I’m quite happy with the pace of development I’ve kept the last few months, resulting in a release with two major improvements only two months after the previous one. So, let me tell you a little about these two improvements, starting with the easiest one.

R.I.P Interfaces

The Component/Interface system is essentially a framework within the framework. Components are reusable building blocks for widgets and Interfaces are used to expose parts of the components methods to the world outside the widget. I’ve never been fully pleased with the need for a separate Interface class, so I took a second hard look and found a better way.

The result is a lot of internal code cleanup and removal of a dozen unnecessary classes. For the user of the framework there isn’t much of a change except that the prefix of the classes has changed (CTextDisplay instead of ITextDisplay etc), unless you write your own widgets, which now should be a bit easier and cleaner.

Major slot-system refactoring

The concept of slots is unique to WonderGUI and has been a bit experimental. Essentially, a slot is a place to put a child widget in a container widget. Some containers have one or more fixed slots, restricting the number of children, while others dynamically allocate slots as needed. The purpose of the slot, except for holding a pointer to the child widget, is to provide easy access to all the parameters the container offers to control the layout and presentation of the child.

Previously you needed to call a method with a reference to the slot (index or interator) in order to manipulate it, but now the slot itself contains all the relevant methods. So, in order to hide the third child in a PackPanel you can now do:

  pWidget->slots[2].hide();

Very straight forward, isn’t it?

You can also do the same thing with an interator pointing at the slot:

  (*it).hide();

Please note that you need to precede the iterator with an asterisk and enclose it in parentheses. Otherwise you access methods provided by the iterator itself instead of the slot.

To access methods in the widget, you still use the -> operator as before:

  pWidget->slots[2]->id();

Using either -> or . depending on if you want to call the childs methods or the parents methods (for controlling the childs presentation) might need a little getting used to, but makes a lot of sense and makes things very smooth in the end.

The container still provides methods for changing several slots at once, so if you want to hide 5 children starting with child 3, you can still do this:

  pWidget->slots.hide( 2, 5 );         // Note, index starts at 0.

There are still a few tweaks and improvements to the slot system that didn’t make it into this release, but essentially it is now there.

Widget resizing improvements

Resizing individual widgets can easily create cascading effects in complex, dynamic layouts. This can result in deep, recursive calls that heavily tax the CPU.quickly get very CPU taxing.

Alpha 7 has had some minor, but important changes to how widgets request resize and how parents are expected to respond, allowing for far more efficient handling in the future.

Bugfixes and other minor changes

A few dozen bugs have been fixed all over the place, improving stability, consistency and performance. Documentation has also been improved in certain areas.

So, what’s next?

With this release, the last of the planned framework refactoring has been completed. A more comprehensive error handling framework will still need to be implemented, but that is not expected to cause any major API changes. I therefore expect the next release to be the first beta.

I plan to shift my focus towards the individual widgets, improving and updating the existing ones and adding new ones to make the framework complete. Beyond that I will spend much more time testing, debugging and writing documentation.