Convert XML Editor to a dockable dialog

Patch to convert to a dockable dialog.
There are some issues with the XML dialog on Windows 7 unrelated to this patch (see bug #942475).

Just two quick comments after a quick test run with r11028+patch on OS X 10.7.2
- The window on the left with the "list of nodes" has a 'too wide' minimal width (at least for small screens, it would be nice to allow a smaller width - else the dialog is not really useful in docked state due to the dock consuming too much of the overall window width if one wants to have a somewhat normal view on the attributes and values)
The current minimal width of the node list in the docked dialog is also wider than in the old (floating) dialog.
- Minor detail: the dialog seems to use different (hard-coded?) gtk-settings for frames (and/or borders) of the tree list windows (nodes, attributes) - or different shadow types, I don't really know the details - than other docked (or floating) dialogs or the old version - any special reason?

- Sometimes I get an additional empty field in the dialog (see attached screenshot, bottom right)

Steps done for the screenshot:
1) delete/rename the preferences file
2) launch Inkscape without file argument (empty window)
3) open the test file from menu 'File > Open Recent' and select object
4) open 'XML Editor' dialog

(tested with 'Ambiance' theme (custom ~/.gtkrc-2.0) and default Raleigh (empty ~/.gtkrc-2.0))

@~suv thanks for testing, fixes in the attached patch

> The window on the left with the "list of nodes" has a 'too wide' minimal width
Yes true, this can now be resized much smaller

> minimal width of the node list in the docked dialog is also wider
I have reduced the minimum size here as well. The dialog still has a minimum size so that is looks ok when docked

> the dialog seems to use different gtk-settings for frames
Good spotting, i have fixed this to be consistent with the old dialog and other docked dialogs.

>Sometimes I get an additional empty field in the dialog
This should be fixed in this patch.

Testing with r11040 on OS X 10.7.2 I noticed this minor regression:
- 'Ctrl+Enter' to commit changes to the current attribute value no longer works (clicking on the 'Set' button does).
The message in the status bar of the dialog still displays the keyboard shortcut if one of the attributes is selected.

> - 'Ctrl+Enter' to commit changes to the current attribute value no longer works

Possibly this is due to an error on my side when trying to get '940715.v2.patch' to apply (it initially failed after yet another header file reorg, IIRC after revision 11030). Would you mind to provide an updated version of the patch against current trunk?

> The dialog still has a minimum size so that is looks ok when docked

Too bad that docked dialogs cannot optionally remember custom widths (adjusted to the current task/document) after closing and re-opening or minimizing and un-minimizing in the dock, or after toggling the visibility of the dock off and on again with <F12> ;-)

Probably a feature which would be addressed with a 'freeze/lock' or 'pin' option (related: bug #930235, bug #180302).

> - 'Ctrl+Enter' to commit changes to the current attribute value no longer works
You are correct, this does not work anymore. When dock/c++'ifying this dialog the ctrl+key press are not received anymore. I can't find any other dialog that has this working either.

>Too bad that docked dialogs cannot optionally remember custom widths
This is true, unfortunately there seems to be no way to set a preferred size for any docked dialog. We can set a minimum size, and the last preferred size is remembered for floating dialogs, but libgdl ignores this size for docked dialogs.

> When dock/c++'ifying this dialog the ctrl+key press are not received anymore.

That's very unfortunate, because when entering new values for an attribute, one usually lets go of the mouse and has both hands on the keyboard. Could you assign a mnemonic to the 'Set' button, so that it could at least be triggered with 'Alt+S' (or 'Alt+T' - unfortunately any of S,E and T will 'shadow' (or take over) one already in use in the main window for the main menu bar).

> unfortunately any of S,E and T will 'shadow' (or take over) one
> already in use in the main window for the main menu bar

Actually, it's the other way round: in docked dialogs, if an accelerator key is already defined in the main window, the same one will not work in the docked dialog, even if it has mouse focus: See bug #170765 comment #7-10.

-> none of the letters of 'Set' can be used for a keyboard accelerator :(

Another (for me major) regression with the dockable XML Editor dialog in Inkscape running under X11 on OS X:
The content of the attribute value field cannot no longer be passed on from Inkscape via the X11 clipboard to the native OS X pasteboard [1] without changing the X11 preferences for the clipboard to automatically update the pasteboard of the clipboard changes (this X11 setting _has_ to be reverted again to allow copy&pasting vector object inside Inkscape and between Inkscape documents as vector objects - see bug #307005, a placeholder report for the upstream bug in X11/Xquartz).

Personally, I rely heavily on this to copy&paste path data and other attributes from Inkscape into the web browser, email client or osx-native text editor (MacVim) - e.g. for bug triage, but for personal usage as well.

[1] used to work in two steps: 'Ctrl+C' (Inkscape -> X11 clipboard), 'Cmd+C' (X11 clipboard -> OS X pasteboard), see also <http://www.inkscapeforum.com/viewtopic.php?f=5&t=11527#p42552>

<speculation>
In Inkscape built with the native Quartz backend of GTK+ (still experimental), copying highlighted text with 'Cmd+C' from old floating dialogs as well as new dockable versions of the same dialogs and pasting it into native applications with 'Cmd+V' works ok (though the keyboard shortcut uses a different modifier than the normal 'Copy to clipboard' command inside Inkscape (Ctrl+V) and is not documented in the context menu). The clipboard support of the Quartz backend however has other problems (not implemented features, e.g. bug #546934) which makes 'use the Quartz backend' not really a valid solution to above issue.

The installation of GTK+ with the Quartz backend comes with a system gtk key theme (named 'Mac'), whereas the default GTK+ installation (via MacPorts) using the GTK+/X11 backend does not have such a default (system) key theme. Could this have an influence on how copy&paste works in either version of the dialogs (old floating ones and new dockable ones)?
</speculation>

<opinion>
The dockable XML Editor dialog seems to have lost two very useful features, making it (at least for me) much less usable than in the original (old) state, on top of not remembering any adjusted widths of the treelist windows inside the docked dialog (not even between two calls within the same session).

The clipboard issue also applies to the 'Text' tab in the new dockable 'Text and Font…' dialog, which until now was the only way on Mac OS X to get text content from Inkscape (X11) copy&pasted into native applications (no problems in the reverse direction). With the dockable dialog, this no longer works (but at least the old XML Editor remained as last resort).
</opinion>

> - 'Ctrl+Enter' to commit changes to the current attribute value no longer works
This should be fixed in the current patch

> from Inkscape via the X11 clipboard to the native OS X pasteboard
That is unfortunate, is there a bug tracking this seemingly application wide issue ?

>on top of not remembering any adjusted widths of the treelist windows inside the docked dialog
This would be a problem in all docked dialogs , not specifically the XML Editor ?

>> - 'Ctrl+Enter' to commit changes to the current attribute value no
>> longer works
> This should be fixed in the current patch

Thx - fix confirmed with r11049 + 940715.v3.patch :-)

>> from Inkscape via the X11 clipboard to the native OS X pasteboard
> That is unfortunate, is there a bug tracking this seemingly
> application wide issue ?

Sorry, it seems that I was wrong in my conclusions and the issue relates to yet another upstream bug/flakiness in XQuartz with regard to updating the OS X Pasteboard if the X11 CLIPBOARD or PRIMARY selection changes: after relaunching the X11 server + wm, it initially works ok to copy text from applications like xterm (PRIMARY), gedit (main window), evince (Properties dialog), Inkscape (text in toolbar entry boxes as well as old floating or new dockable dialogs) and paste it into OS X apps (e.g. MacVim) - using the two-steps copying (not the automatic syncing feature). At some point (possibly when the OS X Pasteboard has been used by other native apps) it stops working, either for all or for only some of the mentioned X11 apps.

I'll keep monitoring this and if I notice reproducible problems really due to changes in Inkscape's code only, I will file a new report with details.

At the moment, one workaround seems to be to quit all X11-based applications and to relaunch X11/XQuartz and all apps again.

>> on top of not remembering any adjusted widths of the treelist
>> windows inside the docked dialog
> This would be a problem in all docked dialogs , not specifically the
> XML Editor ?

Yes, as discussed earlier (comment #6-7). ISTM that it "affects" dialogs like 'Text and Fonts…' and 'XML Editor…' more than others.

I have made the overall default size a bit bigger (320 x 260 - about as wide as the Fill/Stoke dialog) so its more useable when docked. We should fix this problem with docked dialogs properly by modifying the libgdl code to restore docked dialog size, but this may have to wait until at 0.49

>> on top of not remembering any adjusted widths of the treelist windows inside the docked dialog
Its strange that F12 toggling when docked, the dialog height and tree divider positions are restored, but not the width ?!?

If there are no other issues, i would like to commit this to the trunk for wider testing. We can continue to tweak the sizes if necessary.

> If there are no other issues, i would like to commit this to the trunk
> for wider testing. We can continue to tweak the sizes if necessary.

Agreed.

Here's another minor question/detail about padding: the attribute fields (lower right) seem to use a wider (or additional) hard-coded border-width (padding?) - independent of the current desktop theme settings - and don't align with the scrolled window of the list of attributes above.

(attached screenshot r11064+940715.v4.patch, default theme settings (no custom nor system gtkrc), gtkparasite to visualize the widget tree)

Great work!

> We should fix this problem with docked
> dialogs properly by modifying the libgdl code to restore docked dialog size, but this may
> have to wait until at 0.49
Sounds like a useful enhancement, but we should really try to submit the patches to upstream GDL from now on, and backport them to our fork.

<off topic>
Just though I'd draw your attention to another separate issue with the XML dialog (bug #903676). The GtkCList API is deprecated, and causes build failure when compiled with CPPFLAGS+="-DGTK_DISABLE_DEPRECATED". If you're familiar with the code, would you be willing to take a look?
</off topic>

Committed to trunk r11065.

@~suv, the attribute name/value should align better with the attributes list in the commit.

@Alex
>GtkCList API ( (bug #903676)
You read my mind !
I've been working on the slightly easier GtkOptionMenu (bug #903676), but i will get to the GtkCList as well.

Great news (on both accounts)... thanks! My Gtk+ skills are somewhat lacking, so thanks for sorting it!