-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
element::click #224
Comments
Good point, actually. I will analyze and think about it some more. Added in the TODO list: #216 |
Implemented and pushed in develop. |
Ah I missed your first item. Next time, please, one issue at a time. Anyway, it is of no consequence. There is no need to inform the parent elements of dragging acceptance. If you have a use-case for it, I'd like to know more. |
Generally, I would refrain from blocking information from child elements. This is a different topic, but composites do not forward some events if the child is outside click bounds - what if I want to make an element that reacts to mouse/keys regardless of its position? |
This is a bit werid to me:
All element event reaction functions return
bool
to indicate whether the event was handled or ignored, except 2:drag
returnsvoid
click
returnselement*
For the first, is there any motivation behind it? Why not inform parent elements of dragging acceptance?
For the second - isn't this redundant due to
element* hit_test(context const&, point)
? The are very few uses of the return value and currently all of them are either null pointer checks or forwards to the caller just because the function returns something. This means that the interface could be reduced to returnbool
with no impact on implementation.The text was updated successfully, but these errors were encountered: