>> Use undocumented GtkKeyHash > > Its unlikely that making Geany depend on undocumented internals of GTK will > be accepted.
It is almost an independent module, it doesn't seem to be interconnected with other GTK internals. If it'll ever be removed (I highly doubt it will), you can copy the latest available version and it'll continue to work locally. >> Add missing hotkeys to the AccelGroup and drop the custom hotkey handling in >> on_key_press_event. > >> Remake all hotkey handling using Accelerator Maps. > > These require the accelerator to have a menu item to map to No, they do not. Here's an example from [there](https://stackoverflow.com/a/19793067), tested on a hello world application without a menu: ``` GtkAccelGroup *accel_group = gtk_accel_group_new (); gtk_window_add_accel_group (GTK_WINDOW (window), accel_group); gtk_accel_group_connect (accel_group, GDK_KEY_Q, GDK_CONTROL_MASK, 0, g_cclosure_new_swap (G_CALLBACK (hello), window, NULL)); ``` > Also one of the contributors had a first look at accelerators and came upon > the stumbling block that they only allow one closure per binding, not sure if > they found any workaround to that. I don't get it, what is the problem here? Does current implementation allow to have multiple actions set for one hotkey? > Any of the above appear to require significant changes I agree about total remakes, but the approach with accelerators doesn't require many changes in my view. As for GtkKeyHash, it can even be integrated in the current architecture, the only things to do is to add hotkeys to it at the program start and keep it synchronized whenever user changes them. Then an easy lookup in the current key press event handler. >> I suggest to stop enabling-disabling cut/copy actions on the Edit menu >> opening ... visually the menu entries will be enabled all the time. > > Downgrading the UI Sorry, but who will really even notice that particular change? > in favour of a small number of users Are you serious? Surely you don't want to say there isn't many people who use non-Latin alphabet. But it is less likely they're able to report bugs in English, yet you already have two other opened issues about this. > You have not yet shown why the suggested workaround (rebind the problem keys > for the new keyboard layout and if you use both layouts have separate > configuration directories for each (-c option)) does not work If I understand you correctly, you suggest to create two independent configurations, and then run two program copies for working with each layout. You don't have an alternative layout yourself, do you? This "workaround" just isn't viable. Usually you switch layouts at runtime, this is a part of the working process: non-Latin documents can easily contain Latin abbreviations, programming languages are Latin, but the code can contain Unicode literals or comments in non-Latin, HTML code is especially highly mixed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1368#issuecomment-276582571
