-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Pinned Tooltip Windows #1345
Comments
I have this code checked into my project. imgui_set_tooltip() in gpuvis_utils.cpp Going to generalize it to handle more windows, but otherwise it's working great. Only issue I'm seeing is window z-order. I'll take a look at that at some point, but it's not that big deal right now. |
Mike, It looks like the property you need the most is to keep that window over the parent window at all times (even if the parent window is interacted with). But do you actually need inputs to go through? "All other events (mouse hovering, right clicking, etc go to window underneath).". I am surprised you want/need that, I'd find it odd to have a mouse click go through. Some thoughts.. A) It may be possible to introduce a specific type of window for this, e.g. using Child+Tooltip flag might be appropriate. B) A more generic solution, if we can ignore the inputs constraint, may boils down to the requirement that we want some form of finer control over the z-order. I've been reluctant to expose this just using absolute Z values because I think it'd be putting a lot of burden on the application. But perhaps expressed as a series of constraint (e.g. Window B always above Window A, or Window B stays between Z0 and Z1) it would be more flexible and appropriate. I haven't thought about it further than that for now. I'll try to mess around to see if A) is doable without too much trouble. |
It seems to work the hacky proof-of-concept patch below. Use in the context of the parent window.
If you want to give it a test. Let me know!
|
I tried your patch and it worked well but there are issues. One is the layout - appears to still be making room for the window. So if I draw graph, draw the "child tooltip", then draw the event list the tooltip shows up on top of the graph but there is space between graph and event list equal to height of tooltip. Also for my graph I'm checking if the mouse is over the window, has focus, and mouse click for panning, and it looks like I'd still need code to disable that cause right now clicking + moving tooltip window also pans the graph. Also played around with this feature a bit and I think you're right, I probably don't need inputs to go through to the below window. It's quite easy for me to get either behavior with the current tooltip windows though.
I think this is the real issue I need solved. I want the "real" tooltip to show up on top of the pinned tooltips, and I'd like the tooltip that's being moved to be on top, and both of these are at the whim of that qsort function. Maybe you could come up with what you think a good imgui quality API for this might look like and I could write some code for it and we iterate a bit? If you think that's useful, otherwise I'll hack something small in on my side. :) Thanks a ton Omar! |
FYI I realize this is essentially the behavior Win32 refer to as "Tool window". |
Yeah, this is really useful. Couple issues I think would need solving before it's a main line feature are z-order and widgets don't work. I wound up writing my own close button. Working great in gpuvis to display text right now though. |
FYI posting this as it is related (but different from the "pinned" tooltips), if people want multiple tooltips that you want to manually position it is possible to do:
The |
… This should not affect the patch used for #1345 as the RootWindow for Child+Tooltip window points to itself now.
… feature needs substancially more work but this is enough for simplest cases. (#1345)
I have applied the patch discussed here as an undocumented feature. I think the full feature is desirable down the line but the patch has severe limitation (namely that you won't have any z-order control if you have multiple windows with tooltip+child flags.). |
Got it merged into gpuvis. The only odd behavior is after I click on a pinned tooltip and move it, other tooltips don't pop up when I hover over the event list, etc. Kinda like the pinned tooltip took focus? Not a big deal though - I'm definitely gonna use your code to avoid the merge hassles. Thank you very much for getting this in Omar! |
Omar: As per ocornut/imgui#1345 > Got it merged into gpuvis. The only odd behavior is when I click on a pinned tooltip and move it, other tooltips don't pop up when I hover over the event list, etc. Kinda like the pinned tooltip took focus? Not a big deal though - I'm definitely gonna use your code to avoid the merge hassles. Thank you very much for getting this in Omar! Hmm indeed with the patch it is taking focus while previously it would pass focus to the parent window which happened to be the graph and event list. I think in void graph_info_t::init() You can replace mouse_pos = ImGui::IsRootWindowOrAnyChildFocused() ? with mouse_pos = ImGui::IsWindowHovered(ImGuiHoveredFlags_RootAndChildWindows) ? And in bool TraceWin::eventlist_handle_mouse() You can remove the test for ImGui::IsRootWindowOrAnyChildFocused() But I'm not really sure why those tests are there in the first place, there are a few custom focus-related code, might break something. Note that IsItemHovered(), IsWindowFocused(), IsWindowHovered() now have flags with more options, and they are replacing lots of the previous entry points static inline bool IsRootWindowOrAnyChildFocused() { return IsWindowFocused(ImGuiFocusedFlags_RootAndChildWindows); } (Technically obsolete but will redirect for a while. If you enable IMGUI_DISABLE_OBSOLETE_FUNCTIONS in imconfig.h you'll see them. Attached small patches to correct uses of obsolete stuff, apart from those two calls to IsRootWindowOrAnyChildFocused() above)
As alternative, you can set mouse position, than restore it.
` |
@rafaelkrause Please note you can use |
Is there a working example that works with most recent ImGui? I see here some patches, considering that topic is quite old I would prefer to check with you guys first what's the correct way to make a regular popup pinned (Context menu in this case)? Would be also good to add this to ImGui demo code. I see this in the code
could you please confirm how to use it? In ideal world I'd like to have a flag that displays a small "pin" icon available in the context menu e.g. in top-right corner to keep that popup always visible and moveable - thus, convert that to "tool window" as @ocornut mentioned. Note, I thought to add this myself, i.e. whenever pin button is pressed to change that context menu into a regular window with Begin/End, however I guess there might be better way to do that after reading this topic. Thanks in advance. |
I would like windows with the following properties:
I'm planning on using them for "pinned tooltip" behavior like in the below picture. Hover over some event, hit a hotkey, that tooltip is now a "pinned tooltip" and you can view / compare to other events in the main tooltip. I also think these will be useful for displaying floating information about other things.
I've got this working using the code below (which pretty much abuses tooltips). I tried using popups and a few other techniques and couldn't get anything working.
The only issue I've got is the z-ordering, but I think I can get everything else working like I want without imgui changes.
My question would be: this ok? Is there a better way to accomplish this behavior?
Thanks!
The text was updated successfully, but these errors were encountered: