I have now committed the patch [1],[2] I've been working on for quite some time. It gives Inkscape a dock panel right of the canvas on which dialogs can be docked. A part of an external library, GDL, has been included in the tree with this patch, this had to be done as GDL isn't widely available and the fact it demanded some Inkscape specific customizations. The good thing is that this implies that Inkscape's list of dependencies remains unchanged.
The design of the dialog system allows the new dockable dialog behavior to exist along side the old floating dialogs behavior. If the old behavior is preferred, one can select it under Inkscape Preferences > Windows > Dialog behavior.
Know issues -----------
* It doesn't work well with multiple open documents. Fixing it requires a bit of rewrite of the current dialog manager. I'll focus on doing this before the code freeze.
* Resizing in-dock dialogs can be cumbersome. More specifically, one won't be able to expand a dialog placed in the dock unless all dialogs beneath it are expanded in advance. Fixing this requires some changes in GDL, I've got it somewhat working, but decided that it's still too flaky to commit in its current state.
* Remembered positions of dockable floating dialogs is inexact. For me (using Metacity), I'm not able to get the exact position of dockable floating dialogs, the values I get are off by an unpredictable number of pixels. Could be related to the problems described here: http://www.gtk.org/api/2.6/gtk/GtkWindow.html#gtk-window-get-position
* Compiler warnings. Including GDL in the tree introduced a lot of compiler warnings. They're not serious, but it looks bad...
Note that this change only applies to gtkmm:ified dialogs, i.e. dialogs that subclass UI::Dialog. I've gtkmm:ified "Fill & Stroke" and with this change, that version is now default. Dialogs left to be gtkmm:ified are the "XML Editor", "Tiled Clones", "Object Properties" (though it's about to be removed/replaced IIRC), "Text and Font". The "Find" dialog has been gtkmm:ified by Johan but is disabled by default as it needs testing (please help).
Now let's hope I didn't break something important... ;)
1.https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1688508... 2.http://www.nabble.com/-PATCH--Dockable-dialogs%2C-and-some-concerns...-tf346...
-- Gustav
On Wed, Aug 29, 2007 at 11:27:12PM +0200, Gustav Broberg wrote:
I have now committed the patch [1],[2] I've been working on for quite some time. It gives Inkscape a dock panel right of the canvas on which dialogs can be docked. A part of an external library, GDL, has been included in the tree with this patch, this had to be done as GDL isn't widely available and the fact it demanded some Inkscape specific customizations. The good thing is that this implies that Inkscape's list of dependencies remains unchanged.
The design of the dialog system allows the new dockable dialog behavior to exist along side the old floating dialogs behavior.
This is excellent news! :-)
Good work, I'm looking forward to playing with this.
Bryce
Note that this change only applies to gtkmm:ified dialogs, i.e. dialogs that subclass UI::Dialog. I've gtkmm:ified "Fill & Stroke" and with this change, that version is now default. Dialogs left to be gtkmm:ified are the "XML Editor", "Tiled Clones", "Object Properties" (though it's about to be removed/replaced IIRC), "Text and Font". The "Find" dialog has been gtkmm:ified by Johan but is disabled by default as it needs testing (please help).
Now let's hope I didn't break something important... ;)
1.https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1688508... 2.http://www.nabble.com/-PATCH--Dockable-dialogs%2C-and-some-concerns...-tf346...
-- Gustav
On Wed, 29 Aug 2007 23:27:12 +0200, Gustav Broberg <broberg@...370...> wrote:
- It doesn't work well with multiple open documents. Fixing it requires a bit of rewrite of the current dialog manager. I'll focus on doing this before the code freeze.
Have you looked at JonCruz's "Panel" infrastructure, which (if I understand correctly) was really intended to provide the framework for this? I don't know how far he actually got, but the original idea was that Dialog was mainly for the toplevel windows, and Panels the (eventually) dockable bits that can inhabit them or be docked in the main window.
-mental
On Wed, 29 Aug 2007 16:00:25 -0700 MenTaLguY <mental@...3...> wrote:
On Wed, 29 Aug 2007 23:27:12 +0200, Gustav Broberg <broberg@...370...> wrote:
- It doesn't work well with multiple open documents. Fixing it requires a bit of rewrite of the current dialog manager. I'll
focus on doing this before the code freeze.
Have you looked at JonCruz's "Panel" infrastructure, which (if I understand correctly) was really intended to provide the framework for this? I don't know how far he actually got, but the original idea was that Dialog was mainly for the toplevel windows, and Panels the (eventually) dockable bits that can inhabit them or be docked in the main window.
Yes, I looked at it briefly when I started, but I couldn't quite see its goals and how it fitted into my idea of what I wanted to achieve.
From your description though, it sounds like something I should have
considered to extend.
Jon, could you perhaps take a look at the changes I've committed and see if it could be changed to adapt your Panel infrastructure? I'm definitely willing to do changes in my design as I'm not too excited about it... The fact that I wanted to keep the "old" floating behavior as an option, and that I wanted to keep the changes of the current dialogs to a minimum, complicated the design. I apologize for not discussing the design with you, Jon, until now...
-- Gustav
On Aug 30, 2007, at 11:46 AM, Gustav Broberg wrote:
Jon, could you perhaps take a look at the changes I've committed and see if it could be changed to adapt your Panel infrastructure? I'm definitely willing to do changes in my design as I'm not too excited about it... The fact that I wanted to keep the "old" floating behavior as an option, and that I wanted to keep the changes of the current dialogs to a minimum, complicated the design. I apologize for not discussing the design with you, Jon, until now...
Certainly. I've had a bit of Real Life distracting me too much, but am settling back in now.
Besides, remember that our credo is "patch first, ask questions later". :-)
As long as you don't mind doing a little extra work, things might go well. I find for myself that once I first implement something I then can finally get a better idea of what needs to go on. And then I can get things coded better on a second pass.
Sometimes a second pass takes throwing prior work away and starting over. Sometimes it is just refactoring the first pass.
Of course, at the moment I thing it's really my turn to get some good coding work in. I've got to catch up with you now. :-)
Gustav Broberg wrote:
Sent: woensdag 29 augustus 2007 23:27
I have now committed the patch [1],[2] I've been working on for quite some time. It gives Inkscape a dock panel right of the canvas on which dialogs can be docked.
Nice! But on Windows, dialogs that are not docked no longer stay on top :(
Thanks, Johan
On Thu, 30 Aug 2007 01:13:26 +0200 <J.B.C.Engelen@...1578...> wrote:
Gustav Broberg wrote:
Sent: woensdag 29 augustus 2007 23:27
I have now committed the patch [1],[2] I've been working on for quite some time. It gives Inkscape a dock panel right of the canvas on which dialogs can be docked.
Nice! But on Windows, dialogs that are not docked no longer stay on top :(
Ok, just to make sure I get it right: you have "Dialog behavior" set to "Dockable" and the "Dialogs stay on top (experimental!)" set to true?
I'll look into it as soon as I manage to setup an emulator with Windows (is anyone
Gustav Broberg wrote:
I'll look into it as soon as I manage to setup an emulator with Windows (is anyone
See this link to learn how to set up a virtual machine that can run Linux, or whatever you like:
http://www.freesoftwaremagazine.com/articles/using_virtualbox_to_run_ubuntu
Regards, Asger Ottar Alstrup
I really like the way it is but feel frustratd in two things : 1. having long name in vertical tabs is very hard. Once i've lauch "Fill & stroke" (which is a bit longer in french), it take more than the half of the height. Would it be possible to have a 'icon only' mode 2. Shortcut are displayed in tab. When doing it, it expands, but doing it again don't retract. 3. Space again. This reveals that some windows are two large. ie it takes quite 40% of my screen width, which is quite unusable to draw on the canevas. I don't know if it is possible to manage themes like gimp have (for which i use a really tiny UI), or if a double clic on the dock border could close it on right, in order to be able to have as max space as possible to draw.
cheers
pygmee
On Thu, 30 Aug 2007 21:41:05 +0200 Asger Ottar Alstrup <asger@...1802...> wrote:
Gustav Broberg wrote:
I'll look into it as soon as I manage to setup an emulator with Windows (is anyone
See this link to learn how to set up a virtual machine that can run Linux, or whatever you like:
http://www.freesoftwaremagazine.com/articles/using_virtualbox_to_run_ubuntu
Thanks for the tip, worked like a charm!
The dialogs-on-top problem should be fixed now, btw.
-- Gustav
Gustav, Congratulations on this great patch!!
It has already started to help me not get dialogs confused when i have different whole instances of inkscape open.
dialog designs may now need a little more hacking to get their min/max-width under control. I remember the gimp guys went through this same process when docks were introduces also (lots of quirky bugs)
Congrats and thanks again mate!
- Andy
On 9/4/07, Gustav Broberg <broberg@...370...> wrote:
On Thu, 30 Aug 2007 21:41:05 +0200 Asger Ottar Alstrup <asger@...1802...> wrote:
Gustav Broberg wrote:
I'll look into it as soon as I manage to setup an emulator with Windows (is anyone
See this link to learn how to set up a virtual machine that can run Linux, or whatever you like:
http://www.freesoftwaremagazine.com/articles/using_virtualbox_to_run_ubuntu
Thanks for the tip, worked like a charm!
The dialogs-on-top problem should be fixed now, btw.
-- Gustav
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Yah for real! This is quite cool...immediate productivity boost and totally great...I'm serious, everything I wanted from Inkscape when I joined on is now done...what is next? Hopefully SVG tiny compliance and then SVG 1.1 compliance so we can bump up the inkscape numbers...I'm super eager to take advantage of all these cool features to get inkscape out there to the masses, which our pre-1.0 numbering effects (yes, its totally true)...
Cheers!
Jon
On Tue, 2007-09-04 at 10:55 +1000, Andy Fitzsimon wrote:
Gustav, Congratulations on this great patch!!
It has already started to help me not get dialogs confused when i have different whole instances of inkscape open.
dialog designs may now need a little more hacking to get their min/max-width under control. I remember the gimp guys went through this same process when docks were introduces also (lots of quirky bugs)
Congrats and thanks again mate!
- Andy
On 9/4/07, Gustav Broberg <broberg@...370...> wrote:
On Thu, 30 Aug 2007 21:41:05 +0200 Asger Ottar Alstrup <asger@...1802...> wrote:
Gustav Broberg wrote:
I'll look into it as soon as I manage to setup an emulator with Windows (is anyone
See this link to learn how to set up a virtual machine that can run Linux, or whatever you like:
http://www.freesoftwaremagazine.com/articles/using_virtualbox_to_run_ubuntu
Thanks for the tip, worked like a charm!
The dialogs-on-top problem should be fixed now, btw.
-- Gustav
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thank you! First comments/requests:
- When in the dock, each dialog has an Iconify button, which is good. But the icon of that button is difficult to guess. Can we change it?
- We really really need an "iconify all" button in the dock which would iconify all the dialogs there and shrink the dock. Is this possible to add?
- I think there's a little too many states of a dialog: it can be (1) expanded in a dock, (2) squeezed into a horizontal bar in the dock and (3) iconified into a vertical strip on the side of the dock. Unless I'm missing something, (2) really adds nothing for usability compared to (3), just confusion and visual noise. The (2) is bad for other reasons too: when there's at least one horizontal-barred dialog in the dock, all others get such bars too, even expanded ones - and often the bar corresponding to the expanded dialog is somewhere in the stack of such bars but not adjacent to the dialog itself, which is terribly confusing and annoying. I also couldn't find a way to reliably expand such a horizontal bar into full dialog _next to_ the other expanded dialog - it always insists on replacing that expanded dialog with a new one.
So my question is: can you please forbid the state (2) so that only (1) and (3) are possible? If there are too many expanded dialogs in the dock, the user can iconify some of them, otherwise the scrollbar works fine to access all of them.
Hello,
First, thanks a lot, Inkscape UI looks really clean with this. It is delightful.
On 2007-August-30 , at 04:32 , bulia byak wrote:
- When in the dock, each dialog has an Iconify button, which is good.
But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
- I think there's a little too many states of a dialog: it can be (1)
expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
and (3) iconified into a vertical strip on the side of the dock.
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
- There is a handle at the bottom of each dialog which allows to resize it vertically. but it does not work when there is an other dialog underneath. I don't think resizing them vertically is useful anyway. Could it be suppressed?
- when a dialog is docked alone, it usually takes the full height. This can give some very large (and not very nice) buttons/drop-down menus, such as the "relative to" menu in the align dialog. Can't buttons have a fixed height? I never quite understood why buttons had to be proportional to something in GTK. as long as text fit inside it's fine and resizing them looks ugly as soon as they are based on some pixmaps and given some 3d aspect.
Now, if this is to become the default for some dialogs (which would be great IMHO) it would be really nice to rework them so that they all have the same width and don't waste space when docked. And maybe to make them a little more compact if this is possible (but I know this has been worked on in the past so maybe all the compressing that was possible was already done). Currently it is difficult to have two of them open without scrolling on a not-so-small screen (1280x800).
Well, anyway, that's great.
JiHO --- http://jo.irisson.free.fr/
On 8/30/07, jiho <jo.irisson@...400...> wrote:
On 2007-August-30 , at 04:32 , bulia byak wrote:
- When in the dock, each dialog has an Iconify button, which is good.
But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
Agreed
- I think there's a little too many states of a dialog: it can be (1)
expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
I think horizontal bars start to appear when you open more dialogs than fits in the dock
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
can we find dockable dialogs now on SVN ?
bulia byak wrote:
On 8/30/07, jiho <jo.irisson@...400...> wrote:
On 2007-August-30 , at 04:32 , bulia byak wrote:
- When in the dock, each dialog has an Iconify button, which is good.
But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
Agreed
- I think there's a little too many states of a dialog: it can be (1)
expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
I think horizontal bars start to appear when you open more dialogs than fits in the dock
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
yes, I have to respond to ...myself - I just build inkscape from SVN but instead of make + sudo make install I typed just sudo make install after configure - and everything was ok - so no problem with docking - undocking.
Nemes Ioan Sorin wrote:
can we find dockable dialogs now on SVN ?
bulia byak wrote:
On 8/30/07, jiho <jo.irisson@...400...> wrote:
On 2007-August-30 , at 04:32 , bulia byak wrote:
- When in the dock, each dialog has an Iconify button, which is good.
But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
Agreed
- I think there's a little too many states of a dialog: it can be (1)
expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
I think horizontal bars start to appear when you open more dialogs than fits in the dock
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I'm getting unresolved references building on Windows:
Inkscape::UI::Dialog::Behavior::FloatingBehavior ... Ikscape::UI::Dialog::Behavior::DockBehavior ... Inkscape::UI::Widget::Dock::Dock ...
Thanks, Kent
lots of On 8/30/07, Nemes Ioan Sorin <nemes.sorin@...400...> wrote:
yes, I have to respond to ...myself - I just build inkscape from SVN but instead of make + sudo make install I typed just sudo make install after configure - and everything was ok - so no problem with docking - undocking.
Nemes Ioan Sorin wrote:
can we find dockable dialogs now on SVN ?
bulia byak wrote:
On 8/30/07, jiho <jo.irisson@...400...> wrote:
On 2007-August-30 , at 04:32 , bulia byak wrote:
- When in the dock, each dialog has an Iconify button, which is good.
But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
Agreed
- I think there's a little too many states of a dialog: it can be (1)
expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
I think horizontal bars start to appear when you open more dialogs than fits in the dock
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Kent Tenney wrote:
I'm getting unresolved references building on Windows:
Inkscape::UI::Dialog::Behavior::FloatingBehavior ... Ikscape::UI::Dialog::Behavior::DockBehavior ... Inkscape::UI::Widget::Dock::Dock ...
When large changes happen, first delete btool.dep, then run btool again.
I think that'll solve your problem, Johan
On 8/30/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
Kent Tenney wrote:
I'm getting unresolved references building on Windows:
Inkscape::UI::Dialog::Behavior::FloatingBehavior ... Ikscape::UI::Dialog::Behavior::DockBehavior ... Inkscape::UI::Widget::Dock::Dock ...
When large changes happen, first delete btool.dep, then run btool again.
Yes indeed! (the file is build.dep)
The dockables are great.
Thanks, Kent
I think that'll solve your problem, Johan
On Thu, 30 Aug 2007 04:21:18 -0300 "bulia byak" <buliabyak@...400...> wrote:
On 8/30/07, jiho <jo.irisson@...400...> wrote:
On 2007-August-30 , at 04:32 , bulia byak wrote:
Thanks for the feedback,
- When in the dock, each dialog has an Iconify button, which is
good. But the icon of that button is difficult to guess. Can we change it?
In addition it's the same icon that the configure menu for gimp's dialogs. So i personally expected a menu to open when clicking on it. Maybe just an arrow in the other direction (since it's where the dialog will be docked)?
Agreed
Done.
- I think there's a little too many states of a dialog: it can be
(1) expanded in a dock, (2) squeezed into a horizontal bar in the dock
how can this be done? I can't find how to do this. when I hide it it just disappears (I have r15930 maybe you already did what bulia suggested).
I think horizontal bars start to appear when you open more dialogs than fits in the dock
That's true, but you can also choose to dock any dialog this way, on "top" of another, by dragging and dropping it at the middle of the other one. GDL allows this arrangement to be displayed as notebook with buttons or tabs (http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png).
Having used the dockable interface for quite some time I now find myself arranging dialogs this way all the time (though I agree it can be confusing at first).
What it provides is a way creating groups of dialogs taking up minimum space in the dock. I often have two groups in the dock consisting of two or three dialogs each (I seldom use more than half a dozen dialogs during one session). Then I can easily switch between the dialogs (bringing the one, or the two I'm currently interested in to front) using only the keyboard. It's very predictable where the dialog will turn up as it keeps its place, and I tend to learn instinctively where each dialog is (i.e. in the top or the bottom half of the dock).
Iconified dialogs, as opposed to this kind of grouping, has the drawback that you have to make room on the dock for an iconified dialog you want to display. This can't be done using only the keyboard. An "Iconify all" bound to a shortcut would be a workaround, but might hide dialogs in the dock you still want to show.
That said, it would be easy for me prevent dialogs from being arranged in this mode all together (it's a just one line code change), but personally I'd like to at least keep it as an option. How about preventing them from being automatically arranged as groups when the dock is full, but still allow them to be arranged manually?
wasn't there something in gnome HIG against "vertical tabs" like this. KDE uses them extensively and I quite agree that this clutters the interfaces and is not really usable. I think docking it to a single icon would be enough for usability and better for our necks (even it I know what the dialog is, I always tend to bend my head and try reading the text, don't you?).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
What's the policy on adding "hidden" preferences for things like this? (I noticed that we already have a hidden "icononly" option for the toolbox.)
-- Gustav
On 9/5/07, Gustav Broberg <broberg@...370...> wrote:
That's true, but you can also choose to dock any dialog this way, on "top" of another, by dragging and dropping it at the middle of the other one. GDL allows this arrangement to be displayed as notebook with buttons or tabs (http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png).
To me, the main problem with it is that I cannot "expand" such a tab. If two dialogs are "tabbed" I can only alternate between them, but I cannot see both. That would be slightly more acceptable if they were indeed tabs as on your screenshot, but for me they are vertically stacked buttons which makes their behavior extremely counterintuitive.
That said, it would be easy for me prevent dialogs from being arranged in this mode all together (it's a just one line code change), but personally I'd like to at least keep it as an option. How about preventing them from being automatically arranged as groups when the dock is full, but still allow them to be arranged manually?
I think that might work. Unasked-for tabification is unpredictable and extremely annoying. If the accidental tabification by dragging a dialog on top of one another proves to also be a problem, we can indeed add a preference setting for that, off by default.
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
What's the policy on adding "hidden" preferences for things like this? (I noticed that we already have a hidden "icononly" option for the toolbox.)
I don't think there's much of a policy on this, except that you must document it (as everything else!) in release notes in detail.
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Can you make the title bars of dialogs in the dock use darker background, or at least bold text? Without it the title bars get lost visually.
I also propose to reconsider the position of the dock. Now it's on the right of the canvas but below the toolbars. I think it would make sense to expand it upwards so it would be on the right of all the toolbars and the menu bar, shortening them. The right end of the menu bar is always wasted anyway; as for the toolbars, all of them are now squeezable without any loss of functionality (a drop-down replaces those items that didn't fit). Similarly, I think the dock should be on the right of the palette at bottom - but still on top of the statusbar as now, because it's difficult to read statusbar messages when statusbar becomes too short. All this should give the dock a lot more vertical space which is valuable.
On Wed, 5 Sep 2007 11:38:21 -0300, "bulia byak" <buliabyak@...400...> wrote:
All this should give the dock a lot more vertical space which is valuable.
How about also a second docking area below the canvas, for those panels which require a lot of horizontal space (I think filters and XML both qualify).
-mental
On Sep 5, 2007, at 7:38 AM, bulia byak wrote:
I also propose to reconsider the position of the dock. Now it's on the right of the canvas but below the toolbars. I think it would make sense to expand it upwards so it would be on the right of all the toolbars and the menu bar, shortening them. The right end of the menu bar is always wasted anyway; as for the toolbars, all of them are now squeezable without any loss of functionality (a drop-down replaces those items that didn't fit). Similarly, I think the dock should be on the right of the palette at bottom - but still on top of the statusbar as now, because it's difficult to read statusbar messages when statusbar becomes too short. All this should give the dock a lot more vertical space which is valuable.
I personally like being in control of that myself. For many UI's, I end up arranging things differently than other users, so I hate to get locked into specific locations for things.
Eclipse, IntelliJ, DevStudio, etc, are just a few of them
On 9/5/07, Jon A. Cruz <jon@...18...> wrote:
I personally like being in control of that myself. For many UI's, I end up arranging things differently than other users, so I hate to get locked into specific locations for things.
First, sensible defaults, and only then, user customizability :)
On Wed, Sep 05, 2007 at 11:38:21AM -0300, bulia byak wrote:
On 9/5/07, Gustav Broberg <broberg@...370...> wrote:
That's true, but you can also choose to dock any dialog this way, on "top" of another, by dragging and dropping it at the middle of the other one. GDL allows this arrangement to be displayed as notebook with buttons or tabs (http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png).
To me, the main problem with it is that I cannot "expand" such a tab. If two dialogs are "tabbed" I can only alternate between them, but I cannot see both. That would be slightly more acceptable if they were indeed tabs as on your screenshot, but for me they are vertically stacked buttons which makes their behavior extremely counterintuitive.
Well, you can expand them by dragging the current one up or down and drop it on the group. The buttons will only be stacked vertically when there's not enough room for them on one row. I think that's more convenient than the standard gtk "tabbed" layout which will keep them on one long row and give you arrows to scroll the tab list.
One can now change to tabbed layout if it's preferred by setting "options.dock[switcherstyle]" to "4".
That said, it would be easy for me prevent dialogs from being arranged in this mode all together (it's a just one line code change), but personally I'd like to at least keep it as an option. How about preventing them from being automatically arranged as groups when the dock is full, but still allow them to be arranged manually?
I think that might work. Unasked-for tabification is unpredictable and extremely annoying. If the accidental tabification by dragging a dialog on top of one another proves to also be a problem, we can indeed add a preference setting for that, off by default.
Done, the new option is called "options.dock[cancenterdock]" (="1" by default).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
What's the policy on adding "hidden" preferences for things like this? (I noticed that we already have a hidden "icononly" option for the toolbox.)
I don't think there's much of a policy on this, except that you must document it (as everything else!) in release notes in detail.
Sure, I will. The new option is "options.dock[dockbarstyle]". Setting it to "0" will give you icons only.
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Don't blame me, blame GTK! :)
It turns out that F6 and F8 are captured by any gtk_paned for controlling focus by keyboard. Furthermore they are reserved by HIG for that purpose. See http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#standard... (A Gtk::HPaned is used for dividing the canvas and the dock, obviously.)
I tried to do an ugly hack around it by using something like gtk_binding_entry_remove (my_paned_binding_set, GDK_F6, NULL), but I couldn't get it working. Any ideas on how to solve this in a proper way? A custom signal handler re-emitting those signals? Is anyone using those key bindings for controlling a paned, btw?
[...]
I also propose to reconsider the position of the dock. Now it's on the right of the canvas but below the toolbars. I think it would make sense to expand it upwards so it would be on the right of all the toolbars and the menu bar, shortening them. The right end of the menu bar is always wasted anyway; as for the toolbars, all of them are now squeezable without any loss of functionality (a drop-down replaces those items that didn't fit). Similarly, I think the dock should be on the right of the palette at bottom - but still on top of the statusbar as now, because it's difficult to read statusbar messages when statusbar becomes too short. All this should give the dock a lot more vertical space which is valuable.
Hmm, perhaps. I actually had it like that in the beginning, but I thought it looked kind of strange, so I changed it... But, I'll consider it.
-- Gustav
On 9/6/07, Gustav Broberg <broberg@...370...> wrote:
Well, you can expand them by dragging the current one up or down and drop it on the group.
Yes, now I see it, but I first perceived than as some sort of iconified dialogs, and expected the buttons to expand when I click them.
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Don't blame me, blame GTK! :)
It turns out that F6 and F8 are captured by any gtk_paned for controlling focus by keyboard. Furthermore they are reserved by HIG for that purpose. See http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#standard... (A Gtk::HPaned is used for dividing the canvas and the dock, obviously.)
I remember we had exactly the same problem when Jon added the palette at bottom. Jon, can you explain how you fixed it eventually?
I also propose to reconsider the position of the dock. Now it's on the right of the canvas but below the toolbars. I think it would make sense to expand it upwards so it would be on the right of all the toolbars and the menu bar, shortening them. The right end of the menu bar is always wasted anyway; as for the toolbars, all of them are now squeezable without any loss of functionality (a drop-down replaces those items that didn't fit). Similarly, I think the dock should be on the right of the palette at bottom - but still on top of the statusbar as now, because it's difficult to read statusbar messages when statusbar becomes too short. All this should give the dock a lot more vertical space which is valuable.
Hmm, perhaps. I actually had it like that in the beginning, but I thought it looked kind of strange, so I changed it... But, I'll consider it.
If there will be those who prever wide toolbars and small dock, you can do this another user option :)
The next problem with docked windos is: keyboard focus. Before, when I press Ctrl+Shift+F, not only the dialog shows up but it also get focus, and I can at once navigate it with keys without even touching the mouse. Some of the dialogs, notably fill&stroke and export, were even optimized for this, with hot keys (underlined letters) for most widgets. Now this does not work unless I explicitly mouseclick in the dialog. Can you move focus to the docked dialog?
On Sep 6, 2007, at 2:02 PM, bulia byak wrote:
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Don't blame me, blame GTK! :)
It turns out that F6 and F8 are captured by any gtk_paned for controlling focus by keyboard. Furthermore they are reserved by HIG for that purpose. See http://developer.gnome.org/projects/gup/hig/2.0/input- keyboard.html#standard-shortcuts (A Gtk::HPaned is used for dividing the canvas and the dock, obviously.)
I remember we had exactly the same problem when Jon added the palette at bottom. Jon, can you explain how you fixed it eventually?
Yes.
That was exactly my problem. The solution was to not use that GTK+ widget.
Remember, that Inkscape is not a "GNOME" app under the GNOME charter or anything. We try to follow that when possible, but if it gets in the way of good UI, we want to go with good UI.
Keeping cross-platform is a lot of this. We want things to work well on Windows boxes and also on Macs. (I especially feel strongly about that latter one). :-)
so... the point is to not leave that GTK+ widget there during normal use. Split it some other way. Also... one option I looked into but had not implemented yet, was switching the widgets used as needed. That is, one could use something else normally, but then switch in an HPaned when the user explicitly switched to resize mode.
On Thu, 6 Sep 2007 19:01:18 -0700 "Jon A. Cruz" <jon@...18...> wrote:
On Sep 6, 2007, at 2:02 PM, bulia byak wrote:
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Don't blame me, blame GTK! :)
It turns out that F6 and F8 are captured by any gtk_paned for controlling focus by keyboard. Furthermore they are reserved by HIG for that purpose. See http://developer.gnome.org/projects/gup/hig/2.0/input- keyboard.html#standard-shortcuts (A Gtk::HPaned is used for dividing the canvas and the dock, obviously.)
I remember we had exactly the same problem when Jon added the palette at bottom. Jon, can you explain how you fixed it eventually?
Yes.
That was exactly my problem. The solution was to not use that GTK+ widget.
Remember, that Inkscape is not a "GNOME" app under the GNOME charter or anything. We try to follow that when possible, but if it gets in the way of good UI, we want to go with good UI.
Keeping cross-platform is a lot of this. We want things to work well on Windows boxes and also on Macs. (I especially feel strongly about that latter one). :-)
so... the point is to not leave that GTK+ widget there during normal use. Split it some other way.
Ok, but I still want it to the dock to be resizable. I think the paned is good except for the key bindings...
Also... one option I looked into but had not implemented yet, was switching the widgets used as needed. That is, one could use something else normally, but then switch in an HPaned when the user explicitly switched to resize mode.
I guess that could work, but it seems a bit complicated :/
I've managed to override the default signal handlers for the GtkPaned class that capture F6/F8, and by that allowing the signals to be passed on, like this:
g_signal_override_class_closure( g_signal_lookup("cycle_handle_focus", GTK_TYPE_PANED), GTK_TYPE_PANED, g_cclosure_new (G_CALLBACK (continue_emission_cb), NULL, NULL));
(where continue_emission_cb is an empty function returning FALSE.)
It seems to work. Are you aware of any drawbacks with using this method? (Except for its ugliness? ;)
Thanks for your help...
-- Gustav
On Thu, 30 Aug 2007 09:12:52 +0200 jiho <jo.irisson@...400...> wrote:
[...]
- There is a handle at the bottom of each dialog which allows to
resize it vertically. but it does not work when there is an other dialog underneath. I don't think resizing them vertically is useful anyway. Could it be suppressed?
I thinks it's useful for dialogs whose content grows vertically, like "Layers", "Filter Effects" and "Undo History". I'm working on making resizing work for non-bottom dialogs (see "Known issues" in the top mail).
[...] Now, if this is to become the default for some dialogs (which would be great IMHO) it would be really nice to rework them so that they all have the same width and don't waste space when docked. And maybe to make them a little more compact if this is possible (but I know this has been worked on in the past so maybe all the compressing that was possible was already done). Currently it is difficult to have two of them open without scrolling on a not-so-small screen (1280x800).
I fully agree and would really appreciate some dialog re-layouting help...
-- Gustav
One more thing that needs to be fixed: the dock steals F8 disabling the Text tool shortcut. I don't think we need any shortcut for activating the dock at all; most dialogs have their own shortcuts which bring them up in the dock. But maybe we should add a shortcut for iconifying the entire dock when that function is implemented.
Hey Gustav!
Thanks a lot for this great improvement! Of course I'll have some comments about it, but be assured that it's not criticizing what has been done but wishful thinking what will be done :)
I would love to see a general close button on the pane-divider or anywhere else. Minimizing each dialogue to make the pane disappear is rather cumbersome. Actually I don't really see a need for being able to minimize them at all, if not all at once.
Furthermore, I'd love to have a auto-hide mode for the pane, just like the panel has auto-hide. I am however aware that it might not be easy to get an event at the edge of the screen. Hopefully it's possible, though, because otherwise one has to hit such a narrow object.
Furthermore the moving around behaves a little strange, but I cannot really describe it. Sometimes it's divided, then I make both dialogues small and it's back undivided.
Furthermore it may be useful to do a redesign some dialogues to use less space.
That's it for now, I'll have a cup of tea :)
Take care!
David
On Wed, 2007-08-29 at 23:27 +0200, Gustav Broberg wrote:
I have now committed the patch [1],[2] I've been working on for quite some time. It gives Inkscape a dock panel right of the canvas on which dialogs can be docked. A part of an external library, GDL, has been included in the tree with this patch, this had to be done as GDL isn't widely available and the fact it demanded some Inkscape specific customizations. The good thing is that this implies that Inkscape's list of dependencies remains unchanged.
The design of the dialog system allows the new dockable dialog behavior to exist along side the old floating dialogs behavior. If the old behavior is preferred, one can select it under Inkscape Preferences > Windows > Dialog behavior.
Know issues
It doesn't work well with multiple open documents. Fixing it requires a bit of rewrite of the current dialog manager. I'll focus on doing this before the code freeze.
Resizing in-dock dialogs can be cumbersome. More specifically, one won't be able to expand a dialog placed in the dock unless all dialogs beneath it are expanded in advance. Fixing this requires some changes in GDL, I've got it somewhat working, but decided that it's still too flaky to commit in its current state.
Remembered positions of dockable floating dialogs is inexact. For me (using Metacity), I'm not able to get the exact position of dockable floating dialogs, the values I get are off by an unpredictable number of pixels. Could be related to the problems described here: http://www.gtk.org/api/2.6/gtk/GtkWindow.html#gtk-window-get-position
Compiler warnings. Including GDL in the tree introduced a lot of compiler warnings. They're not serious, but it looks bad...
Note that this change only applies to gtkmm:ified dialogs, i.e. dialogs that subclass UI::Dialog. I've gtkmm:ified "Fill & Stroke" and with this change, that version is now default. Dialogs left to be gtkmm:ified are the "XML Editor", "Tiled Clones", "Object Properties" (though it's about to be removed/replaced IIRC), "Text and Font". The "Find" dialog has been gtkmm:ified by Johan but is disabled by default as it needs testing (please help).
Now let's hope I didn't break something important... ;)
1.https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1688508... 2.http://www.nabble.com/-PATCH--Dockable-dialogs%2C-and-some-concerns...-tf346...
-- Gustav
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Gustav,
One more thing: if there are many dialogs in the dock and the dock scrolls vertically, and if I press a shortcut to open a dialog which is already open but scrolled away, can you make it autoscroll to show the activated dialog?
participants (14)
-
unknown＠example.com -
Andy Fitzsimon -
Asger Ottar Alstrup -
Bryce Harrington -
bulia byak -
David Christian Berg -
Gustav Broberg -
jiho -
Jon A. Cruz -
Jon Phillips -
Kent Tenney -
MenTaLguY -
Nemes Ioan Sorin -
radar.map35＠...8...