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

Mousewheel does not allow tooltip to appear #100

Open
elanhickler opened this issue Apr 5, 2024 · 10 comments
Open

Mousewheel does not allow tooltip to appear #100

elanhickler opened this issue Apr 5, 2024 · 10 comments

Comments

@elanhickler
Copy link

ContinuousParamEditor.cpp mouseWheelMove calls onBeginEdit and onEndEdit in the same function so tooltip doesn't have a chance to appear.

@baconpaul
Copy link
Collaborator

This is one of the more tricky things. In shortcircuit I use a timer to keep tooltip up for a minimum time but I didn’t do thst in conduit.

@elanhickler
Copy link
Author

elanhickler commented Apr 5, 2024

proposed fix (this behavior works for me as far as I can tell):

void attachContinuousToParam(ContinuousParamEditor *comp,
                                 uint32_t pid)
    {
        auto source = std::make_unique<D2QContinuousParam>(editor, uic, pid);
        comp->setSource(source.get());

        comp->onBeginEdit = [this, w = juce::Component::SafePointer(comp), pid]() {
            uic.fromUiQ.push({module_t::FromUI::BEGIN_EDIT, pid, 1});
            if (w)
            {
                editor.openTooltip(pid, w, w->continuous()->getValue());
            }
        };
        comp->onEndEdit = [this, pid]() {
            uic.fromUiQ.push({module_t::FromUI::END_EDIT, pid, 1});
            //editor.closeTooltip(pid); /* Remove closing tooltip from onEndEdit */
        };
        comp->onIdleHover = [this, w = juce::Component::SafePointer(comp), pid]() {
            if (w)
            {
                editor.openTooltip(pid, w, w->continuous()->getValue());
            }
        };
        comp->onIdleHoverEnd = [this, pid]() {
            editor.closeTooltip(pid);
        };
        /* Add an std::function for mouse exit */
        comp->onMouseExit = [this, pid]() {
            editor.closeTooltip(pid);
        };

        continuousDataTargets[pid] = {comp, source.get()};
        continuousOwnedData[pid] = std::move(source);
    }
    ```

@baconpaul
Copy link
Collaborator

I think a better solution is to have a tooltip open counter and use a juce run later to do the close in on end edit

then the next begin would not double show

if thst doesn’t make sense I can expand if

@elanhickler
Copy link
Author

what about then just opening tooltip on mouse enter?

@baconpaul
Copy link
Collaborator

That's really annoying as a user. It pops up way too often when you move your mouse across the gui. The delayed open is there to avoid that.

@baconpaul
Copy link
Collaborator

Although if you want to do that in one of your UIs of course go ahead! It would solve this particular problem. Some UIs also have a tooltip area at the bottom the update on mouse enter.

@elanhickler
Copy link
Author

elanhickler commented Apr 5, 2024

Then I would suggest you're using tooltips wrong. What you want is a "display value" widget that just appears in a convenient place, for example, over the label of the widget, or the label of the widget changes to display value on any sort of edit. A tooltip is a delayed help text and shouldn't be about displaying value, since that should be easily seen immediately.

Not that you should take my suggestion, but it helps me realize what I should change about the code.

Edit: My older plugins had a single box two boxes for help text and value display and no tooltip popup function.

@baconpaul
Copy link
Collaborator

yeah so you can do exactly the same thing with this code. Just keep a weak reference to the display area and update the text on enter exit change.

surge and shortcircuit use 'name and value' tooltips (or 'name value and modulation' tooltips) and have forever. but that's definitely not the only thing you can or have to do!

@baconpaul
Copy link
Collaborator

WhatPTQDoes

I think the choice pianoteq makes is perhaps the best. Hover is a delayed help, drag changes the help to a widget near you which dismisses some short time after the drag, and if you stay over, you get the help back some time later.

But anyway the point is: lots of choices you can make here! We should have enough events in the jucegui code so you can, if combined with timers, do what you think is best for your ui!

@elanhickler
Copy link
Author

I edited the tooltip

image

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