Hello everyone,
I plan on implementing a radial menu for CEGUI for use in my application. The new widget will be under the MIT/X license. Before I get underway, however, I have a question.
Currently, CEGUI widgets respond to mouse release events if the press was made inside them, even if the release occurs outside. For example, if I have two widgets "NewGame" and "LoadGame", and I click inside LoadGame, then I release inside NewGame, the mouse release handler for LoadGame is still called. Since I want my radial menu to do click-drag-release instead of click-release-move-click-release, this is an issue for me. Is this considered a bug or a piece of functionality that will be fixed/implemented in the next release, or do I need to seek an alternative implementation/use a hacked version of CEGUI?
Other than that, I'd be more than happy to include any features that are requested!
Thanks,
Rob Hoelz
Implementing a radial menu
Moderators: CEGUI MVP, CEGUI Team
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Hi,
I think the mouse release getting sent to the Window where the mouse was pressed even when the mouse is no longer over that window is dependent upon the widget (i.e. it's not a policy set on the Window class, but rather the individual widget sub-classes).
What you're seeing happens because most of the widgets 'capture' the input - this means that all inputs are directed towards that widget until the capture state is lost. This behaviour is by design and is required for correct functioning of the 'regular' buttons.
I think when making your own widget you should be able to get the behaviour you desire (perhaps by not capturing input, or maybe by forwarding input to children for a compund widget type).
Hope this info is useful
CE.
I think the mouse release getting sent to the Window where the mouse was pressed even when the mouse is no longer over that window is dependent upon the widget (i.e. it's not a policy set on the Window class, but rather the individual widget sub-classes).
What you're seeing happens because most of the widgets 'capture' the input - this means that all inputs are directed towards that widget until the capture state is lost. This behaviour is by design and is required for correct functioning of the 'regular' buttons.
I think when making your own widget you should be able to get the behaviour you desire (perhaps by not capturing input, or maybe by forwarding input to children for a compund widget type).
Hope this info is useful
CE.
Return to “CEGUI Library Development Discussion”
Who is online
Users browsing this forum: No registered users and 24 guests
