Fwd: [Branch ~inkscape.dev/inkscape/trunk] Rev 13262: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one.
I want this feature back (for both dialogs).
-------- Original Message -------- Subject: [Branch ~inkscape.dev/inkscape/trunk] Rev 13262: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one. Date: Fri, 04 Apr 2014 13:18:26 -0000 From: noreply@...1881... Reply-To: noreply@...1881... To: ~suv <snip>
------------------------------------------------------------ revno: 13262 committer: Martin Owens <doctormo@...400...> branch nick: trunk timestamp: Fri 2014-04-04 15:16:22 +0200 message: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one. modified: src/ui/dialog/dialog-manager.cpp
On Fri, 2014-04-04 at 15:39 +0200, su_v wrote:
I want this feature back (for both dialogs).
The dialog is broken as a window. I've spent hours and hours going through the code to find why gtk decides to resize the windows to 0. And it's a wonderful race condition too.
Since all users will by default see the dialogs as windows, the best I can do is add an option to make those docks instead of windows separately.
Is this a suitable option for you?
Martin,
On 2014-04-04 18:22 +0100, Martin Owens wrote:
On Fri, 2014-04-04 at 15:39 +0200, su_v wrote:
I want this feature back (for both dialogs).
The dialog is broken as a window. I've spent hours and hours going through the code to find why gtk decides to resize the windows to 0. And it's a wonderful race condition too.
What is resized to '0'? Is there a bug report about it?
AFAIK there had been no related issues reported with the (by default) docked XML Editor in trunk, nor with the (by default) detached (but dockable) preferences window (besides the known ones about the initial small size (with new prefs) and the center position taken from the pointer position on last close, as described in my earlier mail).
On Ubuntu, under Unity, the custom minimalistic scrollbars (did) affect many of Inkscape's dialogs (where AFAIU the minimal size of scrollbar elements often determine a minimal size for the initial layout of the parent widget) - not sure if this plays a role in the bug you attempted to fix (it does affect the the initial small size of the preferences dialog more than on systems with 'regular' gtk scrollbars; even as newly enforced floating dialog (tested with r13264 on Ubuntu 13.10)).
For me the prior state (both dialogs dockable, XML Editor by default docked in the main dock of the document window) worked ok, the current state removed that and enforces a broken state (see below).
Since all users will by default see the dialogs as windows,
I don't understand what you mean by this.
The default with Inkscape trunk (with fresh prefs) before your commit in r13262 was the docked status in the main dock of the document window, for all dockable dialogs - except for the preferences dialog and the document properties dialog, which each opened docked in a separate floating dock (but both could be docked in the main window too if the user preferred).
After r13262, the XML Editor and the Preferences window are exceptions which ignore the user preferences setting (Dockable or Floating) for dialog behavior (they are always floating dialogs, and cannot be docked, like many of the old dialogs in current stable).
the best I can do is add an option to make those docks instead of windows separately.
Is this a suitable option for you?
I don't even know what your commit attempted to fix or work around, so I can't tell this either.
My issues are: 1) All dialogs which support docking should respect the preferences setting for dialog behavior (Dockable | Floating).
2) The broken behavior of detached (docked in a floating dock) and floating (not dockable) dialogs with multiple document windows should be fixed:
Did you attempt to use the now enforced floating XML Editor with several documents opened from within the same Inkscape process?
If relying on a single XML Editor dialog reflecting the content of any document window which currently has the focus, then it fails at some point because the window levels don't match anymore (the active XML Editor is below the active window coument, or the not-active document window is above the active one).
If the XML editor dialog is opened for each document window separately and brought to the front with 'Shift+Ctrl+X', the data still seems to get mirrored, and the display levels of the dialog windows and document windows are still wrong (associated with the wrong document window).
With your newly enforced maximized default document window state in r13263, this results easily in the situation where the XML Editor displays an object selected in document 2, but the maximized document window behind the XML Editor is actually document 1 (with a different selection).
With the XML Editor as dockable and actually docked dialog (default), none of this happened (only drawback was that it frequently required a manual resizing of the frames widths).
participants (2)
-
Martin Owens
-
su_v