On Tue, Sep 11, 2007 at 12:20:21AM -0300, bulia byak wrote:
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
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
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
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
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
with resize handles when resizing is not possible? This is
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
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
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 :)