Some more progress on the RSA's GUI...
I've implemented a callback system such that every button (window) can have a
function assigned to it which gets called upon the action required, i.e. upon
pressing, releasing etc. a button for example. The mechanism is similar to
Qt's signal/slot (thx for the hint, Popstar) yet without requiring Q_OBJECT
and a preprocessor (moc). I've implemented a very rudimentary version of the
signal/slot mechanism using templates. So, for example, a window can have some
buttons with the button's signals linked to a function being part of the
window's (or any other) object. When the mouse is pressed/released/moved etc.
a message goes through the system. Since a button registers for mouse events,
a specialized event manager for a button is called handling the event while
calling/emitting any of the signals as required - calling the method linked
with it. That's pretty neat. It's fully dynamic, takes only some few bytes of
code, is easily extendable, and doesn't require a preprocessor. :+
Whereas most GUIs are static the goal of this one is to be dynamic, i.e. in
being able to change the behavior as well as the rendering all at runtime for
each individual element. So, for example, you are able to have a different
event handler for each button with each being different in its behavior. You
may copy one handler or extent another one. Similar with rendering; each
button can have its own way of rendering which can be shared, copied, or
extended. This is useful for indicating a possible change in state or when an
action takes place ... by more than just a change in color so to speak. So for
example a button may rotate in 3d while an action takes place, may change
shape, or may glow/pulse upon completion of a certain task, whatever. The
interesting part here is that each one can have its own way of rendering
whereas a uniform one can be chosen as well, as was done in the animation
below. Same holds for the client area, border etc. All can be changed at
runtime. For example, the highlighted border of a window having the focus is a
different rendering object altogether, yet only the color is changed here for
debugging reasons. The objects are changed if the window in question gets the
focus. Sure, I could have just hacked the color change in the non-focused
border as well, but this won't lead to the flexibility required.
With all these things said, the GUI shouldn't be tied to a specific program or
game (which would defeat the investment to begin with), yet can be made to
look like it upon changing the rendering behind. A future version will allow
to have arbitrary shaped curved/wrapped windows, buttons etc. But doing so
requires me to change the rasterizer in using a screen space approach (similar
to a Z-buffer rasterizer) and have some good spatially variant filters ready
for resampling and for preventing alias of the curved/wrapped windows when
being display. So a window may curve/bend/wobble depending on whatever you
want. :+ Anyhow, first things first!