INTERACT FORUM
More => Old Versions => JRiver Media Center 26 for Windows => Topic started by: zybex on June 09, 2020, 11:34:17 am
-
Hi,
Is it possible to configure the popup delay before a tooltip is shown?
A few releases ago the tooltip popup time seems to have increased, and it's now quite slow, around 3 seconds. Also, after the tooltip is shown for a given movie and we move the mouse to the next one, it takes again 3 seconds of hovering for the next tooltip to show up. Since I don't use the Theater View and primarily browse using the tooltips, this is a bit annoying.
It would be nice if we could configure the delay (1 sec seems good for me), and also that if the popup is being shown and we move the mouse to another file, it would immediately show that one instead of resetting the timer.
Thanks,
Zybex
-
Agreed! I thought it was slow before and now it's just anxiety-inducing.
-
also that if the popup is being shown and we move the mouse to another file, it would immediately show that one instead of resetting the timer.
That would make it nearly impossible to click on a field in the file list to edit it, since you would have to move the pointer OUT of the file list just to dismiss the continuous tooltip. Very bad.
Configurable delay would be best. Many people thought it was too fast before, and it got in the way. There's no single time that works for everyone.
I think the configurable delay should also apply to the flyout menus on the tabs and file list panes. Those delays are ridiculously short and those menus constantly fly out when unwanted (they should really activate only with a click)
If they're averse to adding another option in the GUI, an editable line in Resource.xml would be fine.
-
That's what I'm asking for, a configurable delay.
The delay can be shorter on Thumbnail and Tiles view, and remain longer on Details view, to make field editing easier. Clicking on the tooltip also dismisses it, so it's fine to keep it up until the user clicks it or moves the mouse away.
-
This has been requested many times before. Jim has always rejected it because he doesn't want another option in the GUI.
So that's why I'm saying that making it configurable from resource.xml might be the best solution. It would give the user control, but without adding anything to the GUI, which perhaps would make it acceptable to implement.
I'm just hoping it will also apply to the fly-out menus on the tab and file list panes. Those are treacherous.
-
Whoa. I was trying to support your request in a way that would work for everyone and hopefully increase the chances of it getting approved. My mistake.
-
Here's the thread that apparently led to the change from 0.5 to 3 seconds:
https://yabb.jriver.com/interact/index.php/topic,122571.msg865510.html#msg865510
This is 6 times slower, and makes browsing the collection on the Thumbnail/Tiles views much more painful.
Matt/Jim, can you please reevaluate this and add a configurable option?
Thanks
Edit: Relevant XKCD (https://xkcd.com/1172/)
-
Bumping up this thread...
Can you please reevaluate this issue and make the delay configurable? Yes/No answer is fine.
Thanks!
-
Agree. For me, the current tooltip delay is too long to be usable. All family members who use JRiver have complained about this recent change so I've reverted to an older version to avoid it. Please reconsider a configurable option.
-
Tooltip is a wonderful (and for me) an important feature of MC, but I agree 3 seconds are much to long. I heavily support a configurable delay option.
Achim
-
Just noticed this thread as I was wondering why tooltips seemed broken of late, the lag of a 3s delay produces a really bad user experience. My recollection is that 0.5s was slightly annoyingly fast though so about 1s seems more reasonable. If I had to choose between 3 and 0.5 though then I would go with 0.5s
-
If I had to choose between 3 and 0.5 though then I would go with 0.5s
To each his own, I guess. When the tooltip delays were short, I found it to be unusable and always in the way, so they had to be disabled.
-
We're going to try 3/4 of a second.
-
We're going to try 3/4 of a second.
Much appreciated :)
A reg key or xml setting is off the table then?
-
An unchangeable 3/4 second? That's bad news. Back to disabled tooltips for me.
-
We're just trying to piss off the fewest people. Start a poll if you want Democracy. We'll consider it.
-
Poll added.
-
The setting is already there in the Options > Tree & View > List > Show track info tooltips. It just needs to be changed from a checkbox to a time.
MC still has to look up the setting. The settings still need to be saved to and looked up from the Registry.
A setting of 0 (zero) could mean don't show tooltips, and then a user could set the time to what they wanted, to one decimal place, maybe in half second increments.
The only issue with using time rather than a checkbox is what to do with the tooltip toggle. I suggest that should just turn tooltips off by setting it to zero, but not saving that setting to the Registry, and toggling it back on would read the setting again.
-
To each his own, I guess. When the tooltip delays were short, I found it to be unusable and always in the way, so they had to be disabled.
Too short a delay is annoying when you aren't looking for it
Too long a delay is annoying when you are looking for it
The latter is more painful/irritating in my view, i.e. not having something you want is worse than sometimes getting something you didn't want
-
We're just trying to piss off the fewest people. Start a poll if you want Democracy. We'll consider it.
This article may be of interest
https://www.nngroup.com/articles/timing-exposing-content/
I think the hover interaction section covers it and suggests a small increase in delay is a good move. The visual indicator that there is something to show may also be useful.
-
More importantly than the configurable argument, which I must confess draws me to it, what will be the default setting, since most users will just accept as being what happens with MC. You need to have a default setting which is generally acceptable to the vast majority and the ability to reset it to what you want.
-
Too short a delay is annoying when you aren't looking for it
Too long a delay is annoying when you are looking for it
The latter is more painful/irritating in my view, i.e. not having something you want is worse than sometimes getting something you didn't want
I feel the opposite. Because it depends on your perspective: which is worse, a slight delay before you get what you want, or having something forced on you that you didn't want in the first place? I think the latter is worse.
Keep in mind, while the audio tooltips can be small, the movie tooltips can be HUGE. As in block half the UI huge. Having one of those pop up when you didn't want it is extremely annoying.
The situation is worse for people with trackpads. When using a trackpad you often have to pick up your finger to reposition, and this means you get unavoidable unintentional hovers. And that provokes things like tooltips with short timeouts, and also those flyout menus on the tabs, that have an even shorter delay; they fly open so fast it's hard to move your mouse away without them continually expanding. I'd love to be able to set those flyout menus to be click activated.
I think arguing about a default time is a trap. The IS no default time that satisfies everyone. I timed the old timeout at 1 sec, not 1/2 sec, by the way. Enforcing just one value just pisses half the people off, whether it's long or short.
Pretty much everyone seems to have been asking for configurable, but oh well.
-
Perhaps a right click show details would be the answer, then the toolip will only show if you want it.
-
I think arguing about a default time is a trap. The IS no default time that satisfies everyone. I timed the old timeout at 1 sec, not 1/2 sec, by the way. Enforcing just one value just pisses half the people off, whether it's long or short.
Agree, configurable would be best.
I measured 0.5 seconds on 26.0.66 and [almost] 3 seconds on 26.0.67. It's likely that they played with this value a bit and other versions might have different timings. It may also depend on the complexity of the tooltip, and the loading time for poster/thumbnails from a NAS or for local disk - so there's some variance. This is one more reason that a configurable time would be better.
-
FWIW, I completely agree that the current delay is far too long. I also agree that the previous delay (from MC25) was a bit too short. I think that 0.75-1 second might be Just Right (https://en.wikipedia.org/wiki/Goldilocks_principle).
I know the natural instinct of all of us power users is to Always Add a Configuration Option. However, this does increase development load (all of those config options have to be maintained and supported when any of the code "surrounding" the option is altered, tested to make sure they don't break, supported in backups, etc, etc, etc), so it is always a balancing act. Of course, MC is already a Power User's "dream" as-it-is and so already has a ton of configuration options for almost everything imaginable, and I don't know it really makes sense to die on this hill (https://youtu.be/Jln3mi0vfJU?t=15) to prevent Options Bloat (that ship has pretty well sailed).
But, just saying that maybe 0.75 seconds might feel "just right" and we all go away and an option is really not needed.
-
For something like this, I agree that an UI option is overkill.
However, it's just a constant - it's either hard coded or loaded from somewhere, the behavior around it doesn't change.
MC has many settings saved in the Registry, and many of them are not exposed on the UI - check out "HKCU\Software\JRiver\Media Center 26".
Things like this can easily be added there. Something like:
old code:
int tooltipDelay = 1000;new code:
int tooltipDelay = RegistryHelper::GetDWordValue(HKCU, "Properties\\Tooltip Delay", 1000);
If the setting doesn't exist (most users), it gets the default value of 1000ms.
Personally I would set it to 250ms.
-
As Rod points out, this function already has a GUI option: a checkbox. The checkbox must be read and saved like any other option. Changing it to a milliseconds entry field would not substantively increase any burden.
Further, the entire custom hotkey functionality of MC is read from an XML file, and has no GUI elements. So reading a tooltip time from such a file would present a problem?
-
We're just trying to piss off the fewest people.
Documenting this type of UI change in the release notes would be a welcome start. Thanks for considering.
-
Jim must be having fun seeing us discussing implementation details of a non-existent feature ;D
The XML seems to only contain key mappings and related info. The Registry contains a much larger variety of settings including some UI ones - so I feel this would fit best there.
There are in fact 2 settings:
- tooltip on/off (boolean)
- tooltip delay (int)
The first is exposed on the UI, the second is currently hard-coded. Changing the UI setting to an Int so that it can store the delay instead of just the on/off toggle is problematic because when users upgrade, the setting either contains 0 or 1. So now JRiver has to interpret that value - is 1 meant as 1ms, or is it a legacy value that needs to be replaced by some default like 750ms? It's doable, but not a clean break. Usually we don't change the datatype of existing settings because of these types of issues. Of course the new Int value can have both functions: a value of zero means OFF. But reusing the old value is not advisable.
Regardless, two settings would still need to exist - the UI toggle could remain the same (on/off), and the delay could then come from the registry/XML.
EDIT: plus, keeping the UI toggle and just adding the 2nd hidden setting is simpler as no UI changes have to be done. It's literally a 1-line code change.
-
Except that editing the XML file is an approved form of customization, and editing the registry is not. But who cares...
What Zybex said about setting migration when upgrading is nothing that can't be worked around.
JRiver has put out upgrades in the past that necessitated resetting or changing settings. Those are the breaks. It's a tempest in a teacup.
It's clear from everyone's comments and the poll that users overwhelmingly prefer a configurable option. We've made suggestions as to how this can be done with minimal impact regardless of the orientation of concerns about it. Anything beyond that is wasting our breath, since it's not our decision. It's up to JRiver.
-
Latest beta 26.0.93 changes the delay to 750ms. Feels much better, thanks for the change!
... though personally I really like it with FF 00 00 00 ... ;D