LV_EVENT_CLICKED not generated when it is supposed to be. #6123
Comments
|
I am now looking at this and I am thinking that "CLICKED" means a press and release has occurred. |
|
A Click is really a Press followed by a Release. Is there any issue with that? |
|
Docs should be updated to say that. I realized that after I made this issue but I left the issue because the docs need to be updated. PRESSED gets fired on mouse button down or touch CLICKED is redundant to RELEASED because you cannot have a RELEASED unless there was a PRESSED which infers CLICKED. If PRESSED and RELEASED can occur if any part of a widget is touched or clicked on and CLICKED only occurs on a part of the widget that is supposed to allow user interaction.. That would make sense, I don't think this is the case tho. As an example say we have a slider and the only part of the widget that has any kind of user interaction would be the knob and nothing else. If I clicked on the indicator there would be a PRESSED and RELEASED event but no CLICKED event. Now if touch the knob all 3 events would get fired. I know that the slider doesn't work like that but if it did work like that... Another example is an image. an image doesn't have any user control so it should never generate a CLICKED event if it is touched. It should generate the PRESSED and RELEASED events. CLICKED should only get fired if what is being touched has some kind of mechanics to it for user interaction. |
They are almost the same, but e.g. if you scroll a list, by dragging a button and release it, The user can attach any kind of events to the widgets, They can do something image click too. Why not? |
|
I get what you are saying. The documentation needs to be updated to explain the CLICKED event better. It needs to describe when the CLICKED event get fired. So when dragging no clicked event occurs only when it is a press and release with no position change. |
|
It should be a little more explicit. Something to the effect of "This event on differs from the RELEASED event in that it will not get triggered if anything was scrolled." This tells us that all aspects of the event will work the same as the RELEASED event except for not being triggered if scrolling occurred. I personally think this even should only get triggered if a user controllable part of a widget is what got clicked on. If a user wanted to react to an lv_image being clicked on they can use the RELEASED event for that purpose. Question tho. If there a function that can be used that takes an event as a parameter to determine if any scrolling has occurred? For the purposes of the I know that it would not be something you would want to change the behavior of but it does make more sense to have it function in this manner. It is something that the user would be able to use when using lv_obj_t as a container to build a kind of custom widget. It would allow them to react to user input that matters for all of the children in that container without having to target specific objects. Example: void event_cb(lv_event_t *e)
{
if (lv_obj_has_class(lv_event_get_target(e), lv_button_class)) {
// CLICKED EVENT OCCURRED
// If the CLICKED event only happened on things that were able to be interacted with by the user
// The above test would not need to take place.
}
}
lv_obj_t *create_widget(void)
{
lv_obj_t * container = lv_obj_create(lv_screen_active(NULL));
lv_obj_t *text = lv_label_create(container);
lv_obj_t *button = lv_button_create(container);
lv_obj_t *label = lv_label_create(button);
lv_obj_set_text(label, "BUTTON");
lv_obj_center(label);
lv_obj_center(button);
lv_obj_set_text(text, "THIS IS SOME TEXT");
lv_obj_align(text, LV_ALIGN_CENTER, 0, -25);
lv_obj_add_event_cb(container, &event_cb, LV_EVENT_CLICKED, NULL);
return container;
}
lv_obj_t *widget = create_widget(); |
|
The logic of the CLICKED event wasn't criticized so far, so wouldn't touch it now. You can use |
|
I know it was done how it was done a long time ago.. I know that LVGL tries to model it's behavio inline with what is seen in a web browser. Are there clicked events that get triggered when a user clicks on an object that isn't "clickable".... Even if that object has a callback registered to the clicked event?? Take a look at the DIV object. It is an HTML object, You can set it's size and apply styles to it. for all intents and purposes it is the equivalent of an |
|
It seems an |
|
I misread. a div element doesn't have the Let me try and attack this from a different angle... If I remove the LV_OBJ_FLAG_CLICKABLE flag from an object does it stop the following events from getting triggered??
or does it only stop only these events from occurring?
|
|
From the indev's point of view the object will be invisible. So none of the touch related events will be fired. |
|
Essentially what you are saying is if CLICKED gets disabled the PRESSED event which could be for the purposes of scrolling would not get triggered? |
|
True. Something is either touchable or not. |
|
I am going to have to run some tests to see what the behavior is. |
|
OK so if I clear the clickable flag I am not able to scroll. hover events stop, pressing a dragging stops. That is not correct. A click is defined as pressing and releasing without changing position. It has nothing to do with scrolling, or hovering or pressing and dragging. Those events should not stop when the CLICKABLE flag has been removed. |
|
I think the root of the confusion is bad naming of |
|
if it stops the object from being touchable at all then yes that is what it should be named. But there still should be a clickable flag so that say a button cannot be "click" but it can be touched, something like say scrolling. This would be a handy thing to use to control the scrolling of something like say a spinning list where the only thing you want to be clickable would be a button that is directly in the center. the rest that are visible you would unset the clickable flag so those buttons cannot be pressed but a user would still be able to do things like touch it to scroll or touch it to move it. It would be a good way for a user to disable the ability to press something but still allow the ability touch to move an icon or something along those lines. |
|
If we added the void button_click_event_cb(lv_event_t * e)
{
if(is_in_right_position(lv_event_get_target(e) == false) return;
printf("Clicked\n");
} |
|
The issue is when you turn off the clicking it turns off all interactions including hovering. All events stop not just the click event. if clicking gets turned off I should still be able to scroll as that is not a click. a click is defined as a press and release without any movement. Scrolling is a press and drag which means it is not a click. Clicking is the correct event name for what is occurring but it is like the parent event and all other events are a child of it so when the parent is disables the children also are disabled. It should not be that way. Click should be the parent of long click, double click, left click, right click, etc... It should not be the parent of click and drag or scroll up, down, left or right. Even tho the name click and drag infers a click is taking place that's not really what is happening. It should be called "press" and drag but that doesn't sound as good as click and drag. |
LVGL version
master branch
What happened?
I don't know if this is with just the slider or if it is with all widgets I have not looked into it that far.
I have created a slider and I am outputting all of the events that happen when that slider is running. The output seen here if from a single touch, hold and then release. Notice the alignment of the events specifically the CLICKED event
How to reproduce?
make a slider and attach an event callback with the "ALL" event and output the events.
The text was updated successfully, but these errors were encountered: