Skip to content

Conversation

fixerer
Copy link

@fixerer fixerer commented Sep 16, 2025

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.

…g#149)

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.
Copy link
Collaborator

@Kirottu Kirottu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

fixerer commented Sep 17, 2025

"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
Copy link
Collaborator

Kirottu commented Sep 17, 2025

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
Copy link
Author

fixerer commented Sep 17, 2025

Something like this instead?

@fixerer fixerer force-pushed the make-matches-click-selectable branch from 29d8543 to d6db78a Compare September 18, 2025 12:56
Copy link
Collaborator

@Kirottu Kirottu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Select,
Up,
Down,
Nop,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point of having a Nop action?

pub enum PluginBoxOutput {
MatchesLoaded,
RowSelected(<PluginBox as FactoryComponent>::Index),
MouseAction(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

MouseAction {
    button: MouseButton,
    ...
}

.find(|mousebind| mousebind.button == button)
{
// Potentially select row
match action {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants