Un-hover delay

-1. I don't want to wait for the menus to show up. If this is implemented, please please please please please make it a configurable option.

I do agree that we do not really want to wait for the menu to show, but having a un-hover delay is a very interesting idea.

Right, a hover delay but only for the second dropdown level then, not the first one.

#1 is valid, but personally, I'd rather the menu pop up right when I want it instead of having a delay and just have to deal with that problem.

#2 is unfortunately a side effect of hover menus like this. You can't move your mouse right to the target, and that's generally accepted by everyone who has to interact with a menu like this. it's been an "issue" in admin_menu for years.

Like I said, if it's implemented, just make it a configurable option and everyone is happy.

Are you annoyed with current admin menu on D7 ? Cause it not, it seems that there is indeed a tiny delay (at lease on un-hover).

Yes, admin menu on D7 has delay on un-hover and and it helps a lot.

It might be worth to consider adopting hoverintent effect. I use it with admin menu and really like it.
#220100: Add support to detect hover intent (no dependencies added)

Huge +1 for hoverIntent.

I'm planning on writing a patch which integrates hoverIntent with this module. Should I add the JS file in this module or would you guys prefer to add in in the /libraries directory?

Well, it depends if you rely on an external library but I doubt it is necessary. Then a JS file seems good to me !

Following patch integrates hoverIntent (https://github.com/briancherne/jquery-hoverIntent) with Admin toolbar. I made the hole thing configurable so that people who don't want to use this, can disable it.

Also added an update hook for people who already have the module installed. This update hook will set hoverIntent enabled to "FALSE".

Patch still had a console.log() in it :(. Here's new one

Isn't it a bit of overload ? Setting a little hover by default may be enough, isn't it ? Don't sure people will wish to define their own delay...

One of the comments in this issue:

Like I said, if it's implemented, just make it a configurable option and everyone is happy.

...

The point of configurable option was to make happy those who don't like to wait for menu showing up. Hover intent offers a different approach which will not annoy people. See how admin menu works. There is no delay on opening new items at all.

The patch #12 (#13 is not applicable) does not make it work the same way

So you would just apply hover intent for everyone without the option to configure?

And in addition. Should I include hover intent in this module? Or should it be in /libraries?

Well yes I would say the simplest, the less code, the best... And to my mind a tiny JS should be just packaged into the module unless you rely on an external JS library which is not the case, isn't it ?

I'm using a little JS snippet from https://github.com/briancherne/jquery-hoverIntent. That's why I'm not sure if I should ad it in the module...

Well then we should indeed but it annoys me as I would love to keep it plug and play...

I agree, it should be plug and play, but this plugin does exactly what everyone wants... Maybe we can just use the JS code in this module and adjust it to our needs? This way we can keep in the module as opposed to including it as a library. Do you have a better solution?

No indeed, if it does the work, we cloud fork it and package it into admin toolbar.

Ok so let's recapitulate. Create new patch with:

• No configurable options
• Add hover intent lib in admin toolbar module
• Adjust library if necessary

Do we agree on this approach?

Yes we do !

Add hover intent lib in admin toolbar module

There is some copyright information in that plugin. Can we redistribute it under GPL license?

Unfortunately not...

So this means we cannot copy the library and add in in the module?

Well, apparently it is MIT licence

 * You may use hoverIntent under the terms of the MIT license. Basically that
 * means you are free to use hoverIntent as long as this header is left intact.
 * Copyright 2007, 2014 Brian Cherne

So we could include this even if keeping the file with the header and package it is indeed not a good Drupal practice...

I agree that including libraries in your module is not good practice, but this means we can't keep it plug and play? Any suggestions?
The current patch in #13 includes the "library" (imo code snippet) into the module

You could take a look at how Superfish or Nice Menus are including hoverIntent.

The Superfish module requires you to install the HoverIntent library. I think that we do not want to do that for Admin Toolbar module. It really should stay plug and play.

I think that we could use and package anyway your tiny js, keep the header and fork it (and explain it / link to this issue).

Ok. I'll post a new patch next week.

I found a little time. This is the new patch without all the options.
I have set the "hover out" delay to 500ms. Maybe you guys should check if the current settings of the script are ok, I can still change the "hover out" delay or the sensitivity when the "hover in" event is called.

This patch keeps the module plug and play btw :)

Anyone had time to review this patch?

Hello ! Patch seems good to me. I'll take some more time to run some more test and commit. If anyone else can also review, that would be great !

Just tested out. Seems still all right for me. I would just say that a delay of 250 is large enough and makes the menu more reactive.

Should I change the patch for the delay? Or will you just change it after applying the patch?

No, I will directly, don't worry.

Commited to dev ! Thanks !

Eme, you are aware that for some reason a test failed?

Well this is strange. I do not see why it would be related to this patch. I've posted another issue.

Hi @eme, you mentioned a delay of 250ms, but on the commit and the current release it's 500ms. 500ms is really annoying and the usability is worse than before. Can we change this please? I've tested 250ms and it feels much more better. Please find attached a quick patch.

Ciao
Ralf

Indeed. That's a mistake. Dev version is up-to-date with 250.

In attached file a record on how true hover intent should work. Unfortunately current implementation of this in Admin toolbar requires your to hover on desired menu item to open up. That is kind of annoying for some users.

We know it : it has been discussed here : #2908747: Add a config to disable the hoverintent functionality. We need a patch actually to implement.

@eme the point is that what currently Admin toolbar implements is not hoverintent at all. It is just hover without intent. If it was implemented as true hoverintent people would not ask for a way to disable it.