on-hover element

[Xeverous]

I would like to display some extra elements when user hovers over certain elements. There is already floating element which renders on top of everything else, but:

• I do not want to specify floating element size in the related factory. I want it to be whatever that the subject of the element is.
• What would be the best way to display such element only when the mourse is hovering over other elements?

[djowel]

Check out how menu creates a popup when clicked:

https://github.com/cycfi/elements/blob/master/lib/src/element/menu.cpp#L62-L99

You might use popup as-is, or take inspirations from it:

https://github.com/cycfi/elements/blob/master/lib/src/element/popup.cpp

[Xeverous]

BTW, looking how popup is implemented I realized there is a need to communicate with the view in order to enable/disable it's rendering (view_.add(shared_from_this())) - am I right? Apparently stuff like focus, z-index etc indeed requires root element communication.

[Xeverous]

Adding some things not to forget - there are still 2 things that block from having a good tooltip that follows the mouse:

• Only certain of entering/hovering/leaving events are reported for child elements, this is different depending on which composite they are in. This detail is not documented so I have no idea whether it is a bug or intended. IMO it should not be like this, I see no reason for not reporting these events for child elements.
• The hovering event is rarely reported. I can make something already that follows the mouse but it behaves on 2-5 FPS, lagging horribly behind cursor movements. For such thing to work, the mouse position definitely needs to be obtained and passed on every frame.

[djowel]

• This detail is not documented so I have no idea whether it is a bug or intended. IMO it should not be like this, I see no reason for not reporting these events for child elements.

I don't know what you are doing, and I am not sure if the docs will give you the details that you need. You are questioning a fundamental design decision that's been in place for years, only with superficial knowledge. The examples clearly show that hovering works (the menu, hovering over check boxes and radio buttons, etc. use that mechanism). I will not "fix" something that is not broken.

• The hovering event is rarely reported.

I don't think the cursor member function is designed for what you are trying to do. If you want to follow the mouse fast, you're better off with a post handler at 60fps, that tracks the cursor and draws something directly, instead of going through the hierarchy.

[Xeverous]

The examples clearly show that hovering works (the menu, hovering over check boxes and radio buttons, etc. use that mechanism). I will not "fix" something that is not broken.

???

[djowel]

Windows? I am not getting that. You know the drill. File an issue with specific instructions on how to repro. I am not getting that.

Regardless, you are confusing implementation and design. I am talking about design: "You are questioning a fundamental design decision that's been in place for years, only with superficial knowledge." You conveniently nit-picked a probably unrelated bug.

[Xeverous]

I am not getting that. You know the drill. File an issue with specific instructions on how to repro.

Yes, on Windows. Move the mouse slowly; changing window position may also affect the highlight updating behavior (perhaps related to some floating point position roundings)

I don't know what you are doing, and I am not sure if the docs will give you the details that you need. You are questioning a fundamental design decision that's been in place for years, only with superficial knowledge. The examples clearly show that hovering works (the menu, hovering over check boxes and radio buttons, etc. use that mechanism). I will not "fix" something that is not broken.

I'm questioning it because it's not documented. I have no idea how fundamental it is and what is intended and what is not. In your opinion - what is the correct approach to implement my desired behavior?

• low FPS for hover issue: fine, I can just poll for mouse position at 60 FPS. This is easy to achieve. Might even add an API for this
• no entering/leaving reported: I don't know what is intended for what element container (flow composite really differs in behavior), so - can you describe what approach should I take? My current solution (each flow element having own tooltip to enable/disable on hover event) does not work. Should I have 1 tooltip widget that all elements have a reference to so they can override it (using the fact if elements do not overlap then whatever that gets hover event is the only one)?

[djowel]

I am not getting that. You know the drill. File an issue with specific instructions on how to repro.

Yes, on Windows. Move the mouse slowly; changing window position may also affect the highlight updating behavior (perhaps related to some floating point position roundings)

Still not getting it. I see no reason why it should be different on Windows, but I'll try tomorrow. You might also want to update develop since I committed some traversal fixes related to menus (but unrelated to hovering!).

I don't know what you are doing, and I am not sure if the docs will give you the details that you need. You are questioning a fundamental design decision that's been in place for years, only with superficial knowledge. The examples clearly show that hovering works (the menu, hovering over check boxes and radio buttons, etc. use that mechanism). I will not "fix" something that is not broken.

I'm questioning it because it's not documented. I have no idea how fundamental it is and what is intended and what is not.

"Questioning" is putting it mildly, actually. "I see no reason for not reporting these events for child elements." Is more like an unfounded statement, again based on superficial information.

In your opinion - what is the correct approach to implement my desired behavior?

• low FPS for hover issue: fine, I can just poll for mouse position at 60 FPS. This is easy to achieve. Might even add an API for this
• no entering/leaving reported: I don't know what is intended for what element container (flow composite really differs in behavior), so - can you describe what approach should I take? My current solution (each flow element having own tooltip to enable/disable on hover event) does not work. Should I have 1 tooltip widget that all elements have a reference to so they can override it (using the fact if elements do not overlap then whatever that gets hover event is the only one)?

Let me get back to you on this.

[Xeverous]

So after 12bccf4 there is a tooltip elemenet, but it does not guuarantee that the tooltip will actually render on top of everything else.

My use case: I'm creating a preview of a sort of a game UI mod, and need to display some items. From how the game works, flow composite which I use for item elements is not strictly appropriate but it's closer than other tiling methods (mentioning flow because I noticed small differences in behavior).

Just like in the game, hovering over something displays its properties. Some hovers and other on-top-of effects are permanent, other follow the mouse. For some, I need a guuarantee that they will be the highest in Z axis (drawn latest). Because how the game UI works (it definitely has some layers) I think layer should be used here too - the tooltip would be placed in a layer that covers entire view. Given my previous failures in understanding elements API design, I have no idea how an API for such tooltip would look like or whether the library user should manually setup a second layer in view's content.

[djowel]

The examples clearly show that hovering works (the menu, hovering over check boxes and radio buttons, etc. use that mechanism). I will not "fix" something that is not broken.

???

Are you going to provide instructions on how to repro this? As I said, I can't repro this. Can anyone else also repro this one?

[redtide]

I am not getting that. You know the drill. File an issue with specific instructions on how to repro.

Yes, on Windows. Move the mouse slowly; changing window position may also affect the highlight updating behavior (perhaps related to some floating point position roundings)

I tried again following this but I can't reproduce that result, though I'm not sure I understand how. When the mouse should be moved slowly? Changing window position means that the menu is no more visible and then something changes before showing it again?

[djowel]

IDK. I need more info from @Xeverous. I, too, do not understand how this can happen. My best guess is that this happened in the middle of some code changes with #216, first item: "Layout example: menu not processing up/down arrows correctly" I was working on recently (before dab3308).

[Xeverous]

This thing is quite old, but I haven't reported it earlier.

How do I repro: move the window, open menu, move cursor slowly between options.

[djowel]

This thing is quite old, but I haven't reported it earlier.

How do I repro: move the window, open menu, move cursor slowly between options.

Does not repro, no matter how hard I try. You might want to try it again if that issue is "old". Is that is an old screenshot as well? Try again with the latest develop and the cursor-handling-overhaul branch.

[Xeverous]

This isn't an old screen, it has been made on a very recent develop.

Does not reproduce on cursor-handling-overhaul branch.

[djowel]

This isn't an old screen, it has been made on a very recent develop.

Does not reproduce on cursor-handling-overhaul branch.

As I mentioned above, my best guess is that this happened in the middle of some code changes with #216, first item: "Layout example: menu not processing up/down arrows correctly" I was working on recently (before dab3308).

We can't repro it on latest develop. Anyway, the point is rather moot if the cursor-handling-overhaul` branch is good.

[Xeverous]

This issue is labeled pending reply. I can no longer reproduce the highlight issue. If you are pending for my reply - then I think it can be closed.