Closed rafaelmardojai closed 2 years ago
I want to rework the whole DialectLangSelector, should I do it here or in a later PR?
In it's current state, it doesn't work at all, so maybe here XD
In it's current state, it doesn't work at all, so maybe here XD
Lol xd, you have to double click the rows for some reason btw.
Btw, I'm wasn't using the gtk/help-overlay.ui
machinery because we need to change translate shortcut dynamically
Ah, I think we can do that some other way, will look into it
I'll be busy today, but I'll fix the translation button shortcut tomorrow
In it's current state, it doesn't work at all, so maybe here XD
Should be working fine now.
I still don't sure how will work my rework of DialectLangSelector
, so better to work it on a separate branch latter.
As a minimum viable GTK4+Adwaita port this should be ready to merge. Any other improvements can be done in subsequent PRs.
You know if setting our custom shortcuts window with Gtk.ApplicationWindow.set_help_overlay
will also work? Or it will not change the accel on runtime?
It kinda will. It needs an instance of the window. So we would have to re-init it and call set_help_overlay
each time with the new instance, whenever the shortcuts change (i.e., translate accel change or live translation change). Also, set_help_overlay
doesn't set the Ctrl+?
shortcut, so we have to do that too.
Another way would be to make the shortcuts window a template, have a shortcuts.py
module which could update itself. Maybe by using visible
's notification signal, for example. And then hooking up an instance of this new class to set_help_overlay
. I was taking this approach but then realised it maybe a bit unnecessarily complex for our use case.
Right, I think we can leave it as is for now.
Port to GTK4 and use new libadwaita APIs.
I want to rework the whole
DialectLangSelector
, should I do it here or in a later PR?