
Hi Gustav,
some glitches and questions as of rev 16035:
Docked dialogs don't scroll to be visible when I call them, if the dock contains many dialogs scrolled down. Is this fixable?
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.
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?
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?
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.
Is it possible to not show the separators between dialogs in the dock with resize handles when resizing is not possible? This is misleading.
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?

Hello,
On 2007-September-11 , at 05:20 , bulia byak wrote:
some glitches and questions as of rev 16035:
I have also noticed some glitches with the document properties dialog: if several documents are opened in the same instance of Inkscape, opening this dialog works once and then does not work in all the other documents, even if the document in which it was first opened is closed.
I would also be very nice if opening a dialog could resize and pan the canvas so that the same drawing area is visible. I always find myself zooming out and panning to get to where I was after I open the first dialog, that the dock appears and eats 20% of the drawing area. Doing the same when the width of the dock increases (because a wider dialog was open) would also be nice. I don't know what would be preferable when reducing dialogs to the right of the dock or hiding them completely (with F12). Maybe the resize/pan behaviour on dialog opening could be toggled by the same toggle that decides the resize canvas on window resize behaviour? (however it does not pan currently, which makes is much less usable that what it could be).
So there seem to be some work left for these dockable dialogs but be assured that this is for the greater good: they are amazing!
JiHO --- http://jo.irisson.free.fr/

Hi all,
I just noticed that double clicking on the stroke/fill thing in the left bottom gives the old GTK-style FillStroke dialog (which cannot dock for example), but ctrl+shift+f gives the dockable gtkmm dialog. Can someone please remove the gtk-style dialog and all references to it?
Thanks! Johan

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

On 9/16/07, Gustav Broberg <broberg@...370...> wrote:
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.
Thanks, now tabbing works correct in the active (highlighted) dialog, thanks
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... :(
If this is not fixed somehow, I'm afraid we'll have to remove all the mnemonics from dialogs :(
participants (4)
-
unknown@example.com
-
bulia byak
-
Gustav Broberg
-
jiho