Make clicking on a match select it on close-on-click (Fixes #149)

[fixerer]

Modify PluginMatch box to handle GestureClick and claim the event, manually selecting the row. Then also output a Clicked event, which is passed on to the main app events.
On this event, if close-on-click is true, do perform the Select action, picking the item and running its result.

This changes the behaviour (for close-on-click=true) on clicking menu items, selecting them instead of just closing the application.

[Kirottu]

The idea seems sound, but I wonder if this should be the default behavior even without close_on_click set. And if there would be a way to make mouse bindings configurable in a way similar to how keybinds work now.

[fixerer]

"And if there would be a way to make mouse bindings configurable in a way similar to how keybinds work now."

Yea this would probably be best - would probably want another action for "PickRow" as well, to mark a row as currently selected.

Binding the mouse buttons as keybinds did not work (even when they were accepted as correctly spelled).
It is possible however to look at the controller gesture and match gesture.current_button() against gtk::gdk::BUTTON_PRIMARY/SECONDARY and handle binding this way perhaps.

[Kirottu]

Yeah it won't work through the existing keybind config, it would require it's own config entry. This would probably mean having another action type for mouse stuff (something like MouseAction), that will have the relevant actions that can be used. These actions could then be used wherever mouse input is captured.

[fixerer]

Something like this instead?

[Kirottu]

This branch needs to be rebased since master has changed a lot with the provider branch being merged.

[Kirottu]

What's the point of having a Nop action?

[Kirottu]

This is complex enough where it could be structified in the enum, as in:

MouseAction {
    button: MouseButton,
    ...
}

[Kirottu]

This kind of preprocessing of actions feels a bit ugly, I'd prefer if there was a general enum for mouse actions/events as a part of AppMsg, so that the mouse bindings could be extended to be the way close on click works is that it's just a mouse binding. And maybe deprecating that option as well.

In practice the mouse action part of AppMsg would contain all the different kinds of mouse actions/events that different callbacks will produce, and then the handler for the mouse actions specifically can do the required preprocessing before sending another action, if necessary/applicable.