Skip to content
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

Closed
Xeverous opened this issue Aug 30, 2020 · 4 comments
Closed

element::click #224

Xeverous opened this issue Aug 30, 2020 · 4 comments

Comments

@Xeverous
Copy link
Contributor

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 returns void
  • click returns element*

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 return bool with no impact on implementation.

lib/include/elements/element/button.hpp:256:      auto r = basic_latching_button<Base>::click(ctx, btn);
                                        257-      this->do_click(ctx, this->value(), was_selected);
                                        258-      return r;                             // forward
lib/include/elements/element/indirect.hpp:190:      return this->get().click(ctx, btn); // forward
lib/src/element/composite.cpp:70:               if (info.element->click(ectx, btn))     // used as bool
lib/src/element/composite.cpp:83:            if (e.click(ectx, btn))                    // used as bool
lib/src/element/popup.cpp:60:      auto r = floating_element::click(new_ctx, btn);
                          61-      if (btn.down && ((r == nullptr) || hit))             // used as bool
lib/src/element/port.cpp:318:      return port_element::click(ctx, btn);                // forward
lib/src/element/proxy.cpp:82:      auto r = subject().click(sctx, btn);
                          83-      restore_subject(sctx);
                          84-      return r;                                            // forward
@djowel djowel mentioned this issue Aug 31, 2020
15 tasks
@djowel
Copy link
Member

djowel commented Aug 31, 2020

Good point, actually. I will analyze and think about it some more. Added in the TODO list: #216

@djowel djowel mentioned this issue Aug 31, 2020
djowel added a commit that referenced this issue Aug 31, 2020
@djowel
Copy link
Member

djowel commented Aug 31, 2020

Implemented and pushed in develop.

6bc02ca

@djowel djowel closed this as completed Aug 31, 2020
@djowel
Copy link
Member

djowel commented Aug 31, 2020

For the first, is there any motivation behind it? Why not inform parent elements of dragging acceptance?

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.

@Xeverous
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants