Apply hover class to triggering menu link

just the feature I was looking for. Thanks... Works well...

I was able to apply this patch to D6 as well, tested fine for me.

Did Didn't try running patch, just added code manually FYI.

I'll review this and #1045578: Leave parent menu item "hover" active this weekend and will commit the code that works the best.

BTW, nice to see Bonnier using this module :)

I think this is a better patch :)

@DamienMcKenna, do you have an idea which of these patches (#1 or #6) will be committed? I figure that I may as well be testing my site with the one that will be in the production release. Thanks.

Does anyone have further comment on these patches, specifically whether one is preferred over the other?
It doesn't look like either is going to be committed. :(

#1 worked for me.

#6 removed the active state of menu items which were already active (but changing the affected class from "active" to "hover" made #6 work correctly in my situation). Should the affected class in #6 be "hover" rather than "active"?

"hover" would be the correct term to use. I'll be reviewing this issue this week.

I agree with #10 and #11, that "hover" is clearly the semantic behavior being implemented here, however replacing "active" with "hover" in patch #6 is redundant information, since the "qtip-hover" class is already there.

I would just stick with "qtip-hover" as the default hover class, and make the hover-state class name(s) extendible/overridable either through the admin UI, or through custom styles in menu_minipanels_styles.js in your own theme or module.

Also, I'm not sure we need the hover state to apply to the parent item (per patch in #6) either, which just makes the code more complicated. We can use the qtip.options.activator to find the element to which we should apply the hover state.

Patch provided.

Was having issues using shorthand $ in the default callback, and tho I'm not entirely sure why, here is a re-roll that uses the longhand form, that didn't have any issues.

@jwilson3: the $ shorthand won't work because it's outside of the (function($) {})(jQuery); bit.

yep, good point. Would it make sense to move the closing line of the jQuery -> $ mapping section to the absolute bottom of the file?

@jwilson3: try it locally first, I don't believe it worked when I tried BICBW.

Patch in #13 updated with changes from #15; worked fine for me here.

Ugh, forgot to strip out sites/all/modules/contrib... from the patch,... here's a cleaner one.

A few changes:

• The additional indentation changes from jwilson3's patches have been skipped.
• I added some extra validation to ensure the $target object exists.
• The jQuery selector style from Amitaibu was used as it's much cleaner than relying upon another object.
• The class is assigned to the link itself rather than the parent "li" tag.
• The API.txt docs were updated accordingly.

This patch is for D7, a D6 patch is on the way.

I added a "Tips" section to the README.txt file which mentions the "qtip-hover" class that's added to the menu item. I've also included a patch for D6.

Thanks to everyone who contributed to working out the best solution for this, the patches from #20 have been committed.

Anyone participating on this issue should definitely update to the latest release candidate and use the qtip-hover class! It rocks, however, I've just filed a follow-up related issue that I'm experiencing on sites where I'm using the qtip-hover.

Please checkout #1425046: Qtip-hover state is sticking. Your feedback is appreciated.

In reference to #20, can u explain what below line means:-

drupal_add_js(drupal_get_path('module', 'mymodule_styles') . '/menu_minipanels_styles.js', array('scope' => 'footer'));

does it mean, one new module to be added? am i write? If yes then wat are the content of the new module?

Regards

That line by itself means a while lot of nothing and is out of context. It is part of the API.txt, if you want to implement your own qtip settings, you need to put them inside a javascript file in a custom module that implements hook_menu_minipanels_style ("mymodule" is used as an example implementation).

Thanks jwilson3,

So that means while simply applying the patch we should ignore :

* Implements hook_menu_minipanels_style().
  */
 function mymodule_menu_minipanels_style($menu_config) {
-  drupal_add_js(drupal_get_path('module', 'puam_styles') . '/menu_minipanels_styles.js', array('scope' => 'footer'));
+  drupal_add_js(drupal_get_path('module', 'mymodule_styles') . '/menu_minipanels_styles.js', array('scope' => 'footer'));
 }
 ?>
 

Hi there..

Is this module ready to use, i mean, if i download the latest dev; do i need to apply the patch from #20 or it is already applied to the code.

I am asking this, becoz i applied the patch to the menu_minipanels.js but no luck. After going thru a number of times, #20 looks to me confusing and i think i m missing something interesting.

Plz help....

Hi,
this feature would also be great in the 7.x-2.x version.