On Tue, Sep 11, 2007 at 12:20:21AM -0300, bulia byak wrote:
Hi Gustav,
some glitches and questions as of rev 16035:
Sorry for the silence, I've been pretty busy this week :(
Docked dialogs don't scroll to be visible when I call them, if the dock contains many dialogs scrolled down. Is this fixable?
Probably, haven't look into it yet, though.
Hightlighting the title of the dialog which was just called by a shortcut is nice, but it does little else - the keyboard focus is still not in the dialog. Or at least, I can't use Tab to travel between widgets in the dialog as I was able in the dialog as a top-level window - Tab works to select object on canvas no matter what.
Yeah, I wasn't finished :) Being able to focus a container doesn't imply that you automatically can tab between its descendants, but I've committed changes that adds handling of this.
On the other hand, the accelerator keys (underlined in labels) work indiscriminately across all dialogs and all UI in general. For example, select an object, open fill&stroke and switch to HSL tab, then press Alt+H. The first time, the Help menu is opened; the second time, focus jumps to the H field in the dialog. This is a really bad problem - few people use accelerators in dialogs but many call menus by Alt+letter, so this needs to be fixed somehow. Is it possible to limit the scope of the accelerators to the dialog only, so that they only work when some widget in the dialog has focus?
I'm afraid that's trickier. Looking at the GTK source, the way I guess it works is that each GtkWindow stores a hash table with all mnemonics accelerators (=Alt accelerators) used by its containing widgets. When a mnemonic accelerator is invoked it pulls out a list with all widgets that match that mnemonic accelerator, and gives focus to one of them by round-robin that list. I can't see that GTK provides any way of changing that behavior for a specific context.
There's probably some very intrusive hack around this, like catching Alt+key events in docked dialogs and loop through all its descendants to see if there's a match, but it's not going to be pretty... :(
By the way, if I can highlight the dialog with its shortcut, it would be logical if it was also highlighted when I click some widget in it, or just click on its title bar. Is this feasible?
Clicking on the title bar or any focusable widget in the dialog now highlights it.
Press Ctrl+Shift+W - the swatches dialog pops up. Press it again and you get "** Message: Failed to find an existing dialog". Works with other dialogs but not this one.
Oh, yeah, it's a Panel rather than a Dialog -- its dialog behavior is provided by a PanelDialog wrapper. There's a FIXME from 2005 suggesting this to be handled by the Dialog Manager instead, and that's probably what I'll do.
Is it possible to not show the separators between dialogs in the dock with resize handles when resizing is not possible? This is misleading.
My goal is to make resizing (always) possible. But in case I fail to do so, I'll change its appearance (at least by making the handle ungrabable and inactive).
Open several dialogs, then open fill&stroke, iconify it, then restore. It works but I get in the console:
(inkscape:3948): GLib-GObject-WARNING **: value "-313" of type `gint' is invalid or out of range for property `preferred-height' of type `gint'
Now that you've replaced them, can you remove the obsolete fill&stroke code from src/dialogs? Note that the selected-style.cpp calls sp_object_properties_fill and sp_object_properties_stroke, which open the old (non-gtkmm) dialog and switch to the corresponding tab. Can you provide similar accessor functions for the gtkmm docked dialog and replace these calls?
Yes, will do.
Btw, thanks for filling in the release notes for me (I know it's really my job), it's appreciated :)
-- Gustav