Wire shortcuts to gsettings

[WatchMkr]

To keep them aligned if users change defaults.

[mmstick]

@isantop Basically, you can achieve this by doing:

1. Have a Vec<gio::Settings> for storing all the schemas that the application uses,.
2. Have each keybinding define the index of the schema, and the &'static str of the key related to it
3. Create a glib channel for receiving UI events with glib::MainContext::channel()
4. Fetch the schemas[index].get_strv(key) to get an array of shortcuts from that keybinding
5. Watch setting.connect_changed(key, ...) so you can schedule an update to the UI if that key is changed.
6. But have each connected signal send that event to the sender of that glib channel
7. And then you can handle all events in the glib receiver

Might look something like this:

let (sender, receiver) = glib::MainContext::channel();

let schema1 = gio::Settings::new(schema_string);

let mut schemas = vec![schema1, schema2];

let mut shortcut_widgets = Vec::new();

// Program UI and store all keybinding widgets
// And connect schema change events

schemas[idx].connect_changed(key, {
    let sender = sender.clone();
    move || sender.send(UiEvent::Update(0, 0, key)
});

// At the very bottom of the application, receiver takes ownership of all widgets and schemas

receiver.attach(None, move |event| {
    match event {
        UiEvent::Update(schema_index, widget_index, key) => {
            let widget = shortcut_widgets[widget_index];
            let shortcuts = schemas[schema_index].get_strv(key);
            .. update GTK widget
        }
});

[ids1024]

The gsettings_focal branch now has an initial implementation of this, which responds immediately when a binding is changed in gsettings. (But it still needs some improvement to the style and the underlying implementation.)

This raises some questions. To begin with, consider this in the current interface:

How should this be mapped to gsettings? Fundamentally, "Swap Windows" here is four tile-swap-* gsettings keys, each with two values (for arrow keys and vi keys). I assume we don't want to expand this to fill 8 rows. But how should this handle custom bindings?

The current prototype doesn't handle these bindings yet, but here's another part:

Are we fine with adding + when displaying bindings like this? This is the style of the standard GtkShortcutLabel type. If we don't want that, I believe we'll need to duplicate its implementation, which is possible but a bit awkward.

[mmstick]

• We could show the primary shortcut, with the option to reveal secondary shortcuts
• Seems inevitable that we'll have to replace the generic shortcuts with the individual bindings

[ids1024]

Seems inevitable that we'll have to replace the generic shortcuts with the individual bindings

Yeah, perhaps. It does seem suboptimal to expand 1 row into 8 (4 shortcuts with 2 bindings each). I guess expanding it to 4 rows may be alright.

We could show the primary shortcut, with the option to reveal secondary shortcuts

Maybe. I suppose we could have something like a GtkRevealer so that clicking on a shortcut will expand it and show the other bindings. Not sure if that would be very intuitive.

@maria-komarova Any thoughts on this?

[maria-komarova]

Maybe. I suppose we could have something like a GtkRevealer so that clicking on a shortcut will expand it and show the other bindings. Not sure if that would be very intuitive.

Sorry, catching up to your conversation. What interface are we talking about? The dialog for Pop Shell shortcuts?

[maria-komarova]

Are we fine with adding + when displaying bindings like this? This is the style of the standard GtkShortcutLabel type. If we don't want that, I believe we'll need to duplicate its implementation, which is possible but a bit awkward.

Yes, it would be fine to align the styling here to the usual GtkShortcutLabel, as much as everyone wants to get away from that plus. That way there is more consistency.

We could show the primary shortcut, with the option to reveal secondary shortcuts

How would that look like? Would it be the information cloud that shows on hover?

[ids1024]

Sorry, catching up to your conversation. What interface are we talking about? The dialog for Pop Shell shortcuts?

Yep, the window with the title "Pop!_Shell Keyboard Shortcuts". Currently the shortcuts it displays are just hardcoded and it doesn't show if one has been changed.

How would that look like? Would it be the information cloud that shows on hover?

I'm imagining a GtkRevealer like the firmware manager uses. So clicking on the shortcut would expand it with a sliding animation showing the additional bindings. And then it can have the little icon showing there's something to expand only if there's another binding.

I'm not sure that's a particularly good solution.

[maria-komarova]

Looks like we need an updated design for that window. Give me till tomorrow, I'll try to give you the mockup.