Keyboard shortcuts without grabbing

[daniellandau]

It's been almost 4 years, I don't have the feeling that we'll actually implement a way of checking for conflicts. I suggest we instead drop grabbing the keyboard, so if there's already a global shortcut for something, then it just won't be passed to us in the dialog. I added a note in the dialog instructing the user to first disable shortcuts in GNOME Settings.

For some reason the pot/po updating commands wanted to update a bunch of line breaks. Is this something that goes back and forth, or a progress moves forward type of thing? If it's back and forth then I can minimize the diff to just the actually changed parts, but if it's just old vs new tools then maybe we can rip the bandaid and have the larger diff here.

[ferdnyc]

For some reason the pot/po updating commands wanted to update a bunch of line breaks. Is this something that goes back and forth, or a progress moves forward type of thing? If it's back and forth then I can minimize the diff to just the actually changed parts, but if it's just old vs new tools then maybe we can rip the bandaid and have the larger diff here.

Oh, I never run the PO updating tool. It has different ideas about line breaks than Crowdin, so they'll fight about that kind of stuff. It's enough to update just the .pot file. (Which you'll notice, itself, has no line-break differences, just updates to translatable texts.) Then that'll get picked up automatically by Crowdin and presented to the translators, whose translations will be submitted as diffs against the .po files.

If you check in that huge .po diff now, the next Crowdin update will end up being similarly huge as it puts everything back the way it wants it.

[ferdnyc]

So, here's the thing about shortcuts in general:

Google Chrome has somewhat-recently developed the ability to export global shortcuts to GNOME Shell. The shortcuts in question come from some extensions, and I know about this because of a bug: Chrome shows a dialog on startup, which seems to come from GNOME itself, not from Chrome, and if you "Cancel" that dialog instead of "Add"-ing it (even if you want to leave all of those shortcuts Disabled), it will be re-shown on every subsequent launch until you finally think to click "Add".

Here's the dialog that comes up, for me (as I said, the contents are based on the extensions installed — something it completely fails to make clear):

The reason I say it seems to be from GNOME is this: As that dialog indicates, the global keyboard combos in question are managed using gnome-control-center! The Chrome app has a "Global Shortcuts" entry in its listing:

Which, when clicked, brings up a very familiar-feeling dialog:

(The fact that dialog has different contents than the G-C-C one explains why I'm again getting it at every launch.)

...It seems like we should be able to get in on that same functionality, if we just know how. And then we presumably wouldn't need any sort of configuration interface, we'd just ask GNOME Shell to show our global-shortcuts dialog.

[ferdnyc]

(BTW, clicking the Pencil icon in either of those dialogs brings up a very familiar-looking modal, another sign this is being provided by GNOME and not Chrome:)

[ferdnyc]

RE: Translations, it would be great if we could configure the build system to only include the POT update command, but not the PO update command. I don't think there is one, but it might be worth a Meson feature request.

[daniellandau]

RE: Translations, it would be great if we could configure the build system to only include the POT update command, but not the PO update command. I don't think there is one, but it might be worth a Meson feature request.

A good start for that is changing the wiki to not recommend the PO update command. I'll do that right now

[daniellandau]

I'm not overly excited about looking into chrome internals to figure out a process, that IMO doesn't even feel less confusing than having to run conflict resolution manually.

[github-actions]

This pull request has conflicts, please resolve those so that the changes can be evaluated.

[github-actions]

All conflicts have been resolved, thanks!

[daniellandau]

@ferdnyc how about this one? I still feel like this is an improvement to the current situation and the solution from Chrome above doesn't look good IMO and it doesn't seem likely that anyone will implement that for GSConnect anytime soon.

[github-actions]

This pull request has conflicts, please resolve those so that the changes can be evaluated.