How can the Scroll wheel be disabled for Menus?

Help
1

The scroll wheel has been causing unintentional changes to pop-up menu selections while scrolling windows. How can Gramps be hacked to disable Menu scrolling?

Some dialogs are very long and using the Scroll Wheel instead of the scrollbars very convenient.

However if the dialog contains pop-up menus, the menu GUI item can easily pass under the mouse pointer. When that happens, the mouse wheel starts changing the menu selection instead of the dialog content. And since this happens by accident, you might not recall the original setting to restore. And most Configuration/Settings dialogs do not have a cancel.

So I consider this “change menu with Scroll Wheel” GUI option to be an accident waiting to happen.

There is no Preferences option for Mouse Scroll Wheel behavior. So the hard-coding will need to be hacked… once the code is located.

Windows with Gramps 6.0.1 and Fedora with Gramps 5.2.2

2

I strongly suspect that this is a “feature” of the Gtk code, not something that is under control of Gramps. I browsed around in that morass of code for a while and I cannot offhand think of a way of overriding that “feature”. At least without recreating the Gtk menu popup out of more primative Gtk elements in our own code, and then modifying all the places in our code where menus are created to use our new method.

1 Like
3

The alternative for the Preferences tabs would be to add more tabs and eliminate the need for scroll windows. Or add left hand tabs under major top tabs ala the card views.

4

My big problem with the scroll wheel affecting drop-down menus is in FilterParams by @kku

Multi-stage Custom Filters can be quite long with all the GUI wrapping. So I tend to scroll up and down quite a few times. (First, determining the scope then discovering where there are repeated stages, then deep-diving into the specific Custom filter.) And inadvertently tweak settings during the scroll.

image
image900Ă—742 60.8 KB

(There is very little horizontal “safe space” to indicate the dialog while using the scroll wheel. And the scrollbar jumps too much… which makes it difficult to maintain your orientation within the scrolling content.

Fortunately, accidental tweaks can be undone with this tool (Change to another Filter selection and back. You would have to Save to apply the accidental changes.) But extensive Configurations (like FamilyTreeView by @ztlxltl or CardView by @cdhorn ) are more difficult to undo.

5

When I implemented the timeline mode dropdown menu for the panel timeline of my FamilyTreeView addon, this was really annoying. I decided to implement a workaround (see here) that propagates the scroll event to the parent ScrollWindow widget to not only prevent changing the dropdown selection, but also to be able to keep scrolling:

        mode_combo.connect("scroll-event", self.propagate_to_panel)

    # ...

    def propagate_to_panel(self, widget, event):
        Gtk.propagate_event(self.scroll_window, event)
        return True

I’m not sure if this is the best solution, but it works in this case, so it might be useful in other contexts (e.g. config window pages or the FilterParams addon).

1 Like
6

At the risk of causing a furore can I suggest that there is nothing wrong with the scroll wheel function it is the design of the screens in use. So say Preferences this should be a list of selectable items choices, each item having a tick box against it, some of the tick box’s would be mutually exclusive and some multi choice so that all the scroll wheel does is move the entire screen up or down as was the original intention.
Leave the mouse scroll alone and look at the design of the windows.
I know the drop down boxes make the overall window smaller but as this should be a rarely used function what does it matter.
phil

7

It is similar to the OS clipboarding’s Ctrl-C keybinding being highjacked for the Gramps Clipboard or the OS clipboard being flushed by the Links button in the Notes editor.

Interface that result in data loss (or interrupt standard cross-platform/cross-application workflows) deserve a bit more attention.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.