Proposed enhancements

[StevenChristy]

Greetings,

I've implemented a few changes I thought were useful for the SFGUI project. Specifically, I implemented a what I feel is a complete Enabled/Disabled state implementation, and made it possible to determine if a key/mouse event was consumed by SFGUI.

Disable/Enabled changes:
Using the existing INSENSITIVE state which appeared to be for that purpose, I made it so that disabling a container applies a new state called PARENT_INSENSITIVE to child controls recursively. The PARENT_INSENSITIVE's theme is mapped to INSENSITIVE such that whether a control's state is PARENT_INSENSITIVE or INSENSITIVE then it will be mapped to :INSENSITIVE for theme purposes. Helper functions were added IsEnabled() and Enabled(bool enabled) to the base widget. Further, PARENT_INSENSITIVE doesn't overwrite INSENSITIVE so disabling a parent container will apply the theme but will remain distinct from an explicitly disabled child control. Finally, the BREW built-in theme was modified providing a default styling for *:INSENSITIVE that simply renders disabled controls with gray text instead of white text.

HandleEvent changes:
HandleEvent was modified allow SFGUI to consume events while retaining maximum compatibility with old behaviour. HandleEvent now returns a bool result indicating whether or not the event was believed to be consumed. Internally this result doesn't drive the behaviour of SFGUI but it allows users of SFGUI to determine if the event has already been acted upon. Such as mouse clicks in a SFGUI window, or a key press with an ACTIVE Entry control.

Feel free to make further improvements or customizations as desired to incorporate these changes into the base project. Thank you.

[eXpl0it3r]

HandleEvent was modified allow SFGUI to consume events while retaining maximum compatibility with old behaviour. HandleEvent now returns a bool result indicating whether or not the event was believed to be consumed. Internally this result doesn't drive the behaviour of SFGUI but it allows users of SFGUI to determine if the event has already been acted upon. Such as mouse clicks in a SFGUI window, or a key press with an ACTIVE Entry control

Why were only some HandleXYZ functions modified to return a boolean? What exactly are the advantages of that?

[Cleroth]

Probably because they're the most used. Not being able to tell if an event was consumed by SFGUI is one of my biggest gripes with SFGUI. It basically makes it nearly unusable? I modified my version of SFGUI to do the same.

[eXpl0it3r]

Not being able to tell if an event was consumed by SFGUI is one of my biggest gripes with SFGUI.

And why is that?

[Cleroth]

Because then I can't handle my own events that happen outside of SFGUI (eg. like clicking in the world to move your character). Unless I'm missing something.

[eXpl0it3r]

So as in, if the event gets consumed the user had interacted with the UI and thus the game logic doesn't need to handle that event?

Guess that could make sense then.

[Cleroth]

Yes, if I handle all events it would basically process the UI and then click right 'through' it (and into the world).

[Cleroth]

One way some UI libs do it is to use a transparent canvas element that covers the entire screen (and is below all other UI elements). I think I tried to do this in SFGUI long ago. I think I either wasn't able to do it or there was just something wrong with it.

[StevenChristy]

Regarding the choice not to implement a return value for some handle functions because the return value only influenced whether the event was to be considered consumed by the user interface. Some events like mouse move are less obvious because the event doesn't necessarily get consumed and it may depend on the state of the application. For example, a click and drag may have been initiated outside the SFGUI in which case the move is processed by the logic that determines if a drag state is in effect we probably still want to see that drag action working even if the user has to drag the mouse over a portion of the ui. I think I also left mouse up unconsumed for that reason as well.

It is not perfect but was meant to be practical. I can think of a few scenarios where it would be less than ideal. Nothing too difficult to deal with though. Maybe it will help.

[victorlevasseur]

Having a bool return value to HandleEvent would definitely be a good idea (CEGUI does the same for example).

[vfjpl]

@TankOs What blocked you from merging this?