Working on keybindings editor #144
Replies: 4 comments 3 replies
-
Offtopic but related: I think it might be worth while (in the future) to replace the current text-files that are used for translations. While simple, they are less standard and likely will cause confusion among other contributors in the long run. I would maybe consider moving to gettext afterall. It also allows this project to use some other cool external tools for translations like https://docs.weblate.org/en/latest/ or others to make it easier to update translation strings. Anyway, just my thoughts :-) |
Beta Was this translation helpful? Give feedback.
-
Sounds like a great plan! Yes, splitting a big change like this up into muliple PRs makes it much easier for me to review it etc. 👍
Yes, correct. But you fixed that already anyway :) |
Beta Was this translation helpful? Give feedback.
-
@mbrlabs I have a small problem - multiple solutions, but I want to propose something that could be called a "scary change". ProblemFor the keybindings-dialog I was planning to implement a "press button to set shortcut" feature. The problem with that feature is that I, of course, do not know what keystrokes a user might press. Therefore, I need to suppress the shortcut detection application wide. My normal go-to solution for this is to filter events in the "Scary" (but cleanest) solutionI propose to switch the InputEvent-handling in Lorien Lines 116 to 133 in bc83fbe Should become.
This would switch input processing around and and to event-based input-event processing instead of _process-loop driven input event processing. I think that this is the suggested way to do things anyway according to the docs? I think this workaround for detecting if a modal UI element is open would also not be necessary anymore because of the order that event are processed in the event loop:
I did a quick check and everything seems to still work. However, I do not know if there are any deeper reasons to why input processing is done the way it is? If there is, there are a lot of other ways that I can implement to suppress input event processing for the keybindings editor, but I think the suggested change is the cleanest way forward... |
Beta Was this translation helpful? Give feedback.
-
I don't know if this is the case in your solution, but when I was playing with custom shortcuts I occur a problem with overlapping keybinds like Control+Z and Control+Shift+Z |
Beta Was this translation helpful? Give feedback.
-
As you (maintainers) asked for, I am opening this discussion here, so we can discus a bit more how this should be implemented.
First of all: I really really love to have found this application. Infinite canvas on Linux - I was looking for something like the Concepts app on Linux for ages! A very nice start and a good idea to use a game-engine for this!
Anyway, I found a problem that I started to tackle already mentioned in here: #134 . Without keybindings I cannot make use of my 12 custom buttons on my graphics tablet, making zooming and selecting tools unnecessarily cumbersome.
I am fairly familiar with Godot and cobbled something together yesterday already, but came to the conclusion that this will likely grow into a "big feature":
Problems
The keybindings editor right now is implemented in a quite simple way:
However, there are open issues:
If the keybindings are editable, this does not work anymore. I discuss my proposal for the solution to this below.
Solving keybinding lists in translation strings
There are multiple steps to this. First of all, editing keybindings should probably not require restarting the application. That would be very annoying. But the strings for tooltips (and menu items?) still should update, I think. I
grep
ped the codebase for use of the TranslationServer and I think the main reason why live-changing of the language does not work are a few instances where "tr()" is used manually, am I right?If that is the case, I could fix this by emitting a global-event that indicates that the translation table has updated and fix live-language switching that way.
Fixing live-language switching would then allow me to use the translation-engine itself to do some basic string interpolation and change, for example the toolbar translations to something like:
The
{{...}}
-bit would be a basic parser that allows Lorien to do some advanced string manipulations, similar to how Python's jinja2 library does it (but waaay simpler). I do not want to write a full-Domain Specific Language parser for this, but something simple with regexes. When keybindings update, I can then update the entire translation table and auto-update the keybinding lists and apply the new tooltips etc. that way.Plan (order of PRs I propose to get to this feature)
Create New File {{keybindings:ACTION_new_file}}
interpolation for the translation filesSplitting the work packages up like this should prevent a "mega PR" from happening...
Does that sound like a sound plan?
Kind regards,
Paul K.
Edit: Here my initial work https://github.com/MrApplejuice/Lorien/tree/keybindings
Beta Was this translation helpful? Give feedback.
All reactions