Shirakumo / alloy

A new user interface protocol and toolkit implementation
https://shirakumo.github.io/alloy
zlib License
181 stars 12 forks source link

sliders loses focus while adjusting if mouse move out of the slider #4

Closed Inc0n closed 4 years ago

Inc0n commented 4 years ago

While unfocused the components gain focus correctly corresponding to the mouse movements.

However, the components focused, slider in this case, will loses focus if mouse moves out of the component region.

The current behaviour can be reproduced with the example code you given me in this issue. https://github.com/Shirakumo/alloy/issues/1#issuecomment-611354210

It will be better if the currently interacted components will not lose focus when mouse move out of it.

Shinmera commented 4 years ago

I did write logic to handle this, but it probably broke at some point.

Focus right now is busted anyway, several invariants are not upheld.

Inc0n commented 4 years ago

I did write logic to handle this, but it probably broke at some point.

could you tell me which files to look into

several invariants are not upheld.

What do you mean by that?

Shinmera commented 4 years ago

Should all be contained in components/slider.lisp

As for the invariant, see the logs

Inc0n commented 4 years ago

ahh i see thanks!

Inc0n commented 4 years ago

Hi it seems that the focus system works as intended:

all ancestors of a strongly focused element must be weakly focused. only one immediate child of a strongly focused element may be weakly focused. any other element must be unfocused.

The currently dragging slider will loses focus regardless of its state, and the focus will be given to the component under the mouse.

And to fix this, I would suggest to perhaps implement a new generic method for focus-element that is called whenever an element is going to lose focus, which by default will return t, indicate by default it gives up the focus. However, if under any other conditions that this element should not give up focus, it should override this method and return nil.

Would this be a reasonable fix for this issue?

Shinmera commented 4 years ago

It does not work as intended. It might in this case, but there are severe bugs about it around still.

There is no need to add additional functions. In order to allow this behaviour, the system is intended to proceed as follows: pointer events are first sent to the currently focused element. If this element declines to handle it, it is then sent to the root element, and bubbles upwards in the hierarchy. This should allow the currently focused element to capture pointer events outside of its region.

I'm not sure what part of that is broken now, but it did work properly like that at one point.

Inc0n commented 4 years ago

Some behaviour I observed: After commenting out (call-next-method) in handle for its T case And stopping it from setting the state to nil in (setf focus)

The original focused slider was able to retain strongly focused, while the hovered slider is focused as nil.

However, the hovered slider is still receiving mouse move event.

The intended behaviour was to bubble up to root element. But one thing to note for the program I used, that the 3 sliders (freq, phas, ampl) are elements of the same parent, (I assume so because they are all added to the same layout element) the code for the sliders and their relation in terms of focus.

Shinmera commented 4 years ago

The problem was indeed elsewhere, the GLFW backend did not follow the event protocol correctly.