Currently, if I go to custom commands, type a nice long command and click ok, I lose my custom command and have to go back and type it in again. I have to hit enter first in the command field, then click ok. Ok should save the contents of the custom command field that has focus and hasn't been saved yet.
I'm afraid thats a GTK-ism that we don't control, the signal to Geany from the entry field isn't sent until you enter the command, just exiting the dialog doesn't do it.
I remember when fixing the numbered bookmarks that keypresses in general can be captured, so a little bit of binding of save to any keypress when you have focus on the text box might do the job. I'll try to find a gtk program with auto updating search, see how someone else handles making events happen without the gtk baked lose focus event.
Actually its slightly more subtle, 1) custom commands is a Gtk tree view, not a simple entry, more complicated 2) the cell renderer doesn't fire the edited signal until enter, so the value isn't copied into the underlying store until then, so when the dialog is closed the value in the store is unchanged and thats what is saved.
But the same thing happens for plain GTK entrys eg in the build commands dialog, without an enter or moving to another entry the edited value isn't saved to be available for the application to read when the dialog is "OK"ed.
For the ugly solution that doesn't involve waiting on gtk, could we do some manual keypress captures and maintain our own copy of the store, so semi reimplement it to make this work? Or we could petition some changes to tree view upstream, anything that happens if we went that route would probably happen in gtk 4 though and I think geany hasn't jumped over yet
Well, I don't know what others think, but as far as I'm concerned, no, reimplementing your toolkit isn't sensible. Perhaps there is a better solution somewhere, but somebodys got to find it.
I might also just throw out the possibility of removing or reducing the number of places that need Ok-ing, its not the way most current UIs seem to work, maybe we are fighting the toolkit by keeping that paradigm.
Hmmm, the thought above prompted me to see what the HIG says (brand new one for GTK3/4). It says entrys should accept the text on activate and _focus loss_ (my italics) so maybe all that is needed is to listen for that and treat it as activate?
(Sorry for the bitty response, but it wasn't a contiguous thought process :-)
I believe it is already bound to a lose focus event because I can make it save by doing things other than hitting enter, like clicking random things. Just doesn't seem to think it's losing focus when I hit esc or the ok button. Actually, I think gtk has switch focus calls, could try see if calling one of those still invokes the lose focus. If it does, we could switch focus to some unused, hidden if possible, widget to force the update before closing the dialog, a little hacky
github-comments@lists.geany.org