On 9/16/07, Gustav Broberg <broberg@...370...> wrote:
Thanks for all bug reports, comments and wishes regarding the dockable dialogs I've received in the last weeks! To sum it up, here's my todo list for the time to come:
Excellent list, thanks! Please let as know (and update the relnotes, blah blah blah) as soon as anything from this list is done :)
- Make all the functionality provided by dialog-events.cpp work with the new dialogs. Perhaps by moving it into the Dialog class. This will lead a bit of to code duplication as long as there are "old" dialogs around, which is bad, on the other hand it allows the code to be C++-ified, which is good.
Perhaps the most urgent issue is defocusing. Old dialogs were set up to pass focus to the editing window whenever Esc is pressed, or a button is clicked, or Enter is pressed in a spinbutton control. This ensures that the annoying sticking of focus in the dialog never happens, and yet is is possible to navigate the dialogs with keyboard. All these behaviors needs to be restored. Fortunately it's not too difficult: before, a function in dialog-events just looked up the parent window to which the dialog is transient and passed focus to it (which right now causes a warning because the parent window can't be found). Instead, you need to do the same thing as is now done for toolbar buttons and controls: they move focus to their desktop's canvas widget (although for dialogs, you will need to pass it to the _active_ desktop's canvas, not any fixed desktop's canvas).
This item is indeed rather urgent, because when I do and Esc or Ctrl+arrows and they don't work because the focus is stuck in the dialog it's very annoying.
- Allow dock to "start" from menu bar instead of toolbar (and thereby giving it more space), by adding an option in "options.dock".
Actually, I was talking about starting it right from the window header, i.e. cutting the menu bar as well as toolbars. And don't forget about cutting the palette as well.