
On Thu, 5 Apr 2007 02:08:45 -0300 "bulia byak" <buliabyak@...400...> wrote:
On 4/4/07, Gustav Broberg <broberg@...370...> wrote:
So that's a good thing. I've uploaded a new patch which includes the stripped down gdl (svn head version) merged with the Inkscape tree. Linking gdl statically increases the 'inkscape' binary size with about 800 kB (total size is 51 MB) on my system.
Thanks! I just tried the new patch. First impressions:
- Overall, it works and is already usable!
Thanks for the review! I've uploaded an updated patch that address some of the issues.
- However, many dialogs require serious re-layout of many dialogs to
make them more vertical. For example, Align and Layers already fit nicely. Transform, less so. Trace bitmap looks ugly when in the dock - way too wide.
Yeah, I agree. I think Document Properties is a good candidate as well (it can be useful to have it in the dock in some situations).
- Can we assign default docked/undocked modes for specific dialogs?
For example Preferences, apart from being way too wide for the side dock, simply does not make much sense in the dock. It's not really interactive, i.e. you don't need to look at the canvas when you're working in it. Can we set it to be in its own floating dock by default?
Fixed. A state attribute per dialog is stored in preferences.xml (1=floating, 2=docked). The Inkscape and Document Preferences dialogs are in a floating state per default, the rest are docked. The state is saved back to the preferences file on change.
- Bug: when I place Preferences to the side dock but then delete it, I
can't squeeze the empty dock back - it still takes almost half of screen width
Fixed.
- Can we have some more prominent titles of panels stacked in the side
dock? Right now it's not easy to find where one panel ends and another begins.
Any ideas on how to make this clearer? I tried making the titles bold, but I didn't like the way it looked. I added the dialog icon next to the title in the latest patch, I think it made it slightly better, but not good enough...
- Can we make it remember what was in the side dock and restore that
configuration upon the next launch?
Yes, it would be nice. Too bad I had to strip away the layout manager part of GDL which would make it easy to serialize/build up the dock to/from xml. Just storing _what_ dialogs that are in the dock is easy -- storing their arrangement, position and state is a bit more complicated.
- Bug: floating docks show up in KDE's Alt-Tab list (floating dialogs
don't). Looks like GDL does not set the correct flags on the dock windows.
Fixed.
- Bug: defocusing fails. Clicking a button on a toolbar sends focus
back to the canvas so that keyboard shortcuts work. This fails with side-docked dialogs - they steal focus mercilessly.
Fixed.
- Why can't I squeeze the nonempty side dock all the way off, so it is
not visible at all? I think there should be an easy way to minimize it
- it's cumbersome to have to close all panels in it before you can
make it go away (and even then you can't do it, see bug above).
Show/Hide dialogs (F12) hides the dock, but I guess an extra shortcut for hiding just the dock (and not any floating dialogs) would make sense. And perhaps a button on the dock itself to collapse it.
- And of course, if we go with this patch, we'll need to convert the
rest of gtk dialogs to using Panel too. I think this can be done relatively easily - no need to gtkmmify all their widgets at once: just take the top-level widget, Glib::wrap it and place into a gtkmm container. Should work for the time being.
Ok, I'll take a look see if this is as easy as it sounds :)
I'm still not sure on how to solve the problems that arises when multiple document windows are open. The one-dialog-for-all-windows design doesn't really work when dialogs both can be docked and floating. What would happen to a dialog that is docked in one window when you open a new window? Letting it control both windows would be strange as it's attached to only one of them...
You could allow the user to have multiple instances of dialogs as long as they're docked in their parent window, but prevent the user from having two floating ones. I think this would be equally strange as the user suddenly wouldn't be able to drag dialogs from the dock (into a floating state) which one normally can.
Another way to solve it would be to make the whole dock a singleton that moves with the document that currently has the focus. But on the other hand I think it would be good to allow the user to have different dock layouts for each open window.
Inkscape's current dialog management is also a bit different. There's one DialogManager per document, the dialogs that have singleton behavior implement it "themselves". E.g. Transform and AlignDistribute are non-singleton, while e.g. Layers and UndoHistory make sure that they're only instantiated once.
It pretty much boils down to what the desired dialog behavior is...
Another remaining problem is what to do when docked dialogs go of screen (i.e. the dock becomes taller than its parent window). You could automatically force them on top of each other in a notebook, or perhaps iconify them to the dock-bar on the right. I removed the scroll pane I had before as it created more problems than it solved.
-- Gustav