Thanks for all bug reports, comments and wishes regarding the dockable dialogs I've received in the last weeks! To sum it up, here's my todo list for the time to come:
TODO (in no specific order) ---------------------------
* Allow in-dock dialogs to be expanded even if there's no "slack". (I've got it kind of functional, but needs some more work).
* Force GtkPaned to pass on F6 and F8 (i.e. those shortcuts can't be used now when the dock is displayed).
* Make all the functionality provided by dialog-events.cpp work with the new dialogs. Perhaps by moving it into the Dialog class. This will lead a bit of to code duplication as long as there are "old" dialogs around, which is bad, on the other hand it allows the code to be C++-ified, which is good.
* Tackle the problems with dockable dialogs and multiple desktops, i.e. the Dialog manager redesign.
* Scroll dock to display docked dialogs when requested, and needed.
* Remove old, obsolete object-properties dialog (a.k.a "Fill & Stroke"). Add methods for setting a specific tab in the new F&S.
* Manage the Swatches dialog with the dialog manager, like any other dialog.
* Fix minor problem with switching focus directly to dialog docked in main window, when a floating dialog have focus. Also give focus to a dialog that is deiconified.
* Fix all GDL runtime warnings.
* Fix all GDL compile time warnings.
* See if anything can be done about the clashing mnemonic accelerators, i.e. allow them to be context sensitive for dialogs.
* Add any (if any) major, user visible problem from above that didn't get fixed to "Known problems" sections in the release notes.
Wish list (in no specific order) --------------------------------
* Add a "iconify/minimize all" button and bind a shortcut to it.
* Pan/zoom drawing depending on dock size, behavior toggled by the current "Zoom drawing if window size changes" button.
* Allow dock to "start" from menu bar instead of toolbar (and thereby giving it more space), by adding an option in "options.dock".
* Add another, horizontal, docking area. Potentially hard if we wan't dialogs to be dragged and dropped between the docks.
I might have missed something, please tell if there's something crucial that needs to be fixed before the code freeze that's not already on the TODO list.
-- Gustav
On 9/16/07, Gustav Broberg <broberg@...370...> wrote:
Thanks for all bug reports, comments and wishes regarding the dockable dialogs I've received in the last weeks! To sum it up, here's my todo list for the time to come:
Excellent list, thanks! Please let as know (and update the relnotes, blah blah blah) as soon as anything from this list is done :)
- Make all the functionality provided by dialog-events.cpp work with the new dialogs. Perhaps by moving it into the Dialog class. This will lead a bit of to code duplication as long as there are "old" dialogs around, which is bad, on the other hand it allows the code to be C++-ified, which is good.
Perhaps the most urgent issue is defocusing. Old dialogs were set up to pass focus to the editing window whenever Esc is pressed, or a button is clicked, or Enter is pressed in a spinbutton control. This ensures that the annoying sticking of focus in the dialog never happens, and yet is is possible to navigate the dialogs with keyboard. All these behaviors needs to be restored. Fortunately it's not too difficult: before, a function in dialog-events just looked up the parent window to which the dialog is transient and passed focus to it (which right now causes a warning because the parent window can't be found). Instead, you need to do the same thing as is now done for toolbar buttons and controls: they move focus to their desktop's canvas widget (although for dialogs, you will need to pass it to the _active_ desktop's canvas, not any fixed desktop's canvas).
This item is indeed rather urgent, because when I do and Esc or Ctrl+arrows and they don't work because the focus is stuck in the dialog it's very annoying.
- Allow dock to "start" from menu bar instead of toolbar (and thereby giving it more space), by adding an option in "options.dock".
Actually, I was talking about starting it right from the window header, i.e. cutting the menu bar as well as toolbars. And don't forget about cutting the palette as well.
On 9/16/07, bulia byak <buliabyak@...400...> wrote:
Perhaps the most urgent issue is defocusing.
One more thing I forgot: there was special code (which I wrote, but it was long ago so I don't remember where it is off-hand) which passes the shortcuts that are not consumed by the dialog to the active desktop. This allowed e.g. to press +/- to zoom canvas when your fill&stroke has focus (and mouse is over it), without defocusing it. This also needs to be restored for docked dialogs.
On Sep 16, 2007, at 8:48 AM, Gustav Broberg wrote:
- Manage the Swatches dialog with the dialog manager, like any other dialog.
I think this one pulls up a key issue.
We want to get away from the concept of "Dialogs" since we really are trying not to have them.
Instead we have "panels" that might be embedded or might be floated in a dialog. That's why the swatches dialog was using that instead of hooking directly into dialog widgets. The idea is to encapsulate things so that they are container agnostic. If something is needed to function properly, it can just be added to the Panel API.
That also will get a lot of common code moved into a single Dialog- that-holds-a-Panel class, and remove a lot of redundancy.
Again, a "Dialog" should be a "top level window that can float around" where as a "Panel" should be a "container of a set of things for a common purpose".
On Sun, Sep 16, 2007 at 06:44:53PM -0700, Jon A. Cruz wrote:
On Sep 16, 2007, at 8:48 AM, Gustav Broberg wrote:
- Manage the Swatches dialog with the dialog manager, like any other dialog.
I think this one pulls up a key issue.
We want to get away from the concept of "Dialogs" since we really are trying not to have them.
Instead we have "panels" that might be embedded or might be floated in a dialog. That's why the swatches dialog was using that instead of hooking directly into dialog widgets. The idea is to encapsulate things so that they are container agnostic. If something is needed to function properly, it can just be added to the Panel API.
That also will get a lot of common code moved into a single Dialog-that-holds-a-Panel class, and remove a lot of redundancy.
I like that plan, let's go ahead with it.
So basically, the current "dialogs" will subclass Panel instead. All code in the "dialogs", now panels, that assumes a Gtk::Dialog like base class will be rewritten (or Panel will be extended to satisfy their needs when it makes sense).
The Dialog-that-holds-a-Panel class would replace the current Dialog class, i.e. be just like Dialog but get its content by adding a Panel (?). The DialogManager would handle the new Dialogs in the same way as it handles the current ones. This design would also allow Dialog to be rewritten as template class with its behavior as argument, as opposed to the current clunky one-behavior-instance-per-dialog solution (which also gives lots of duplicated API:s).
My only concern is the possibility of squeezing this in before the upcoming release, I think my current to do list will take pretty much all of my available time :/
-- Gustav
On Tue, 18 Sep 2007 00:20:49 +0200, Gustav Broberg <broberg@...370...> wrote:
My only concern is the possibility of squeezing this in before the upcoming release, I think my current to do list will take pretty much all of my available time :/
Personally, I'd consider the current state of the panels a release-blocker; it's really cool, but we really need it working all the way before we can do a release.
-mental
On 9/17/07, MenTaLguY <mental@...3...> wrote:
Personally, I'd consider the current state of the panels a release-blocker; it's really cool, but we really need it working all the way before we can do a release.
What exactly in the current state of "panels" (you mean docked dialogs) is so bad in your opinion?
On Mon, 2007-09-17 at 21:24 -0300, bulia byak wrote:
What exactly in the current state of "panels" (you mean docked dialogs) is so bad in your opinion?
I need to try with a fresh build, but the last time I tried (recently) there were issues like dialogs coming up as dockable panels sometimes and regular panels others (e.g. between the various methods of invoking fill and stroke), and also undocked panels not playing nicely between multiple document windows.
-mental
On 9/17/07, MenTaLguY <mental@...3...> wrote:
On Mon, 2007-09-17 at 21:24 -0300, bulia byak wrote:
What exactly in the current state of "panels" (you mean docked dialogs) is so bad in your opinion?
I need to try with a fresh build, but the last time I tried (recently) there were issues like dialogs coming up as dockable panels sometimes and regular panels others (e.g. between the various methods of invoking fill and stroke),
Yes, it's a known problem on Gustav's todo list.
and also undocked panels not playing nicely between multiple document windows.
Intuitively, this indeed should be a problem. But it would help if you could list some specific issues that you faced.
On Mon, 2007-09-17 at 23:02 -0400, bulia byak wrote:
Intuitively, this indeed should be a problem. But it would help if you could list some specific issues that you faced.
Well, the most obvious is that you can undock e.g. a fill and stroke dialog from every document window, at which point you have many identical dialogs with no indication of which one belongs to which document. Nor do undocked panels go away when their parent document is closed. It is very frustrating (and also space-consuming).
As far as I can tell, the only way to keep this under control is to share a single undocked instance between documents, with the traditional "current document" behavior for dialogs.
Alternately, we could get rid of undocking.
-mental
On 9/18/07, MenTaLguY <mental@...3...> wrote:
Well, the most obvious is that you can undock e.g. a fill and stroke dialog from every document window, at which point you have many identical dialogs with no indication of which one belongs to which document. Nor do undocked panels go away when their parent document is closed. It is very frustrating (and also space-consuming).
Yes, it's weird, but not really incorrect, so long as all undocked ones correctly track and reflect the selection in the active desktop (which they hopefully do without interfering with each other).
As far as I can tell, the only way to keep this under control is to share a single undocked instance between documents, with the traditional "current document" behavior for dialogs.
Forcing that would be nice, yes.
Alternately, we could get rid of undocking.
That I would really like to avoid.
On Tue, 2007-09-18 at 00:14 -0400, bulia byak wrote:
On 9/18/07, MenTaLguY <mental@...3...> wrote:
Well, the most obvious is that you can undock e.g. a fill and stroke dialog from every document window, at which point you have many identical dialogs with no indication of which one belongs to which document. Nor do undocked panels go away when their parent document
is
closed. It is very frustrating (and also space-consuming).
Yes, it's weird, but not really incorrect, so long as all undocked ones correctly track and reflect the selection in the active desktop (which they hopefully do without interfering with each other).
I think a per-document dialog remaining open when its owning document has been closed is clearly incorrect. It's bad enough that you can't tell them apart otherwise.
As far as I can tell, the only way to keep this under control is to
share a single undocked instance between documents, with the
traditional
"current document" behavior for dialogs.
Forcing that would be nice, yes.
It would be my preferred solution as well.
-mental
On 9/18/07, MenTaLguY <mental@...3...> wrote:
I think a per-document dialog remaining open when its owning document has been closed is clearly incorrect.
But in what way are they per-document? They behave just as they did when they were not dockable, and were "shared". Even when a dialog is docked it is currently (I believe) still reflecting the selection of the active desktop, not "its" desktop. That behavior of docked dialogs is perhaps more troublesome.
On 2007-September-18 , at 04:50 , MenTaLguY wrote:
On Mon, 2007-09-17 at 21:24 -0300, bulia byak wrote:
What exactly in the current state of "panels" (you mean docked dialogs) is so bad in your opinion?
I need to try with a fresh build, but the last time I tried (recently) there were issues like dialogs coming up as dockable panels sometimes and regular panels others (e.g. between the various methods of invoking fill and stroke),
I can confirm this: clicking on the F & S indicator at the bottom of the window opens an undocked F & S dialog (even when one is already open in the dock).
and also undocked panels not playing nicely between multiple document windows.
I think having one dialog per window is the most natural behavior, particularly now they can dock. Furthermore, I think it is probably the best one overall, provided those dialog follow their parent window (are raised or lowered with the window, are closed when the parent window is closed). Indeed, I have always found the "one dialog for all windows" behavior both unintuitive and not practical. Here are some use cases of Inkscape with multiple windows and F&S dialog to illustrate my point: - multiple Inkscape windows on a large monitor or on two monitors: having one F&S dialog means that one usually has to move it around when switching windows. Indeed it is usually nice to have it not too far from your drawing area... unless you have divergent strabismus of course, but that's probably an isolated use case ;) - multiple Inkscape windows on multiple virtual desktops (probably the most common use case on Linux and possible on OS X). Depending on how good your window manager is, and how much aware it is of multiple desktops, a unique F&S dialog can be a problem. Indeed, on my system at least, it always stays at the same place and so, when it is opened on one desktop, it does not show on the others. - multiple windows on one, regular sized, desktop (the most common on Windows). In this case, Inkscape windows are used sequentially in time and having one or several F&S dialogs does not matter, as long as only one dialog is raised with one Inkscape window. Overall, having one dialog per window is the best choice IMHO. It is both simple, intuitive and functional. The only drawback is a little more clutter on the desktop if one is not careful but hiding dialogs on unfocused windows would solve this elegantly.
A last issue with docked dialogs: multiple windows in one Inkscape instance can't open several Document Properties dialogs. When one is open, the other windows cannot open it, trying to do so gives the focus to the window where the dialog is open. Worst, when the window in which it was open in the first place is closed, the other window still cannot open it, making the UI appear unresponsive.
Other than that, docked dialogs are nice. ;)
JiHO --- http://jo.irisson.free.fr/
Hi, Mental.
I've added some basic documentation on the Alt-key mapping in both the FAQ and 0.46 release notes (user interface), if you'd like to give them a once-over.
Has the current code been updated to have
<group id="mapalt" value="1" />
installed into the default preferences.xml file? I couldn't work out how to do this myself.
Thomas
On Tue, 18 Sep 2007 01:47:57 -0400 MenTaLguY <mental@...3...> wrote:
On Tue, 2007-09-18 at 00:14 -0400, bulia byak wrote:
On 9/18/07, MenTaLguY <mental@...3...> wrote:
[...]
I think a per-document dialog remaining open when its owning document has been closed is clearly incorrect. It's bad enough that you can't tell them apart otherwise.
As far as I can tell, the only way to keep this under control is to
share a single undocked instance between documents, with the
traditional
"current document" behavior for dialogs.
Forcing that would be nice, yes.
It would be my preferred solution as well.
And how would that be forced? Say that document A has a F&S docked, and there's a shared, floating F&S opened by document B. Would A's docked F&S be "locked" (impossible to drag) in its dock to prevent two floating F&S dialogs? That behavior sounds kind of awkward to me :/
-- Gustav
On 9/18/07, Thomas Worthington <tww@...1737...> wrote:
I've added some basic documentation on the Alt-key mapping in both the FAQ and 0.46 release notes (user interface), if you'd like to give them a once-over.
Why is the 1 to 5 range? Are these scan codes? On my system xkeycaps shows Alt keys to have 40 and 73, other relevant keys have similar large numbers. I didn't find a key which would have a code of 2 or 3 or 4 or 5.
Has the current code been updated to have
<group id="mapalt" value="1" />
installed into the default preferences.xml file? I couldn't work out how to do this myself.
You just need to add this to preferences-skeleton.h.
On Tue, 18 Sep 2007 17:18:50 +0100, bulia byak <buliabyak@...400...> wrote:
On 9/18/07, Thomas Worthington <tww@...1737...> wrote:
I've added some basic documentation on the Alt-key mapping in both the FAQ and 0.46 release notes (user interface), if you'd like to give them a once-over.
Why is the 1 to 5 range? Are these scan codes? On my system xkeycaps shows Alt keys to have 40 and 73, other relevant keys have similar large numbers. I didn't find a key which would have a code of 2 or 3 or 4 or 5.
No, they're the number (Mod1 to Mod5) that appears beside "modifers:" when you mouse over the key on xkeycaps. The range is 1-5 because that's the only values GDK and X support (GDK_MOD1_MASK to GDK_MOD5_MASK in GDK).
I shall rework the text to make this clearer.
Thomas
participants (6)
-
bulia byak -
Gustav Broberg -
jiho -
Jon A. Cruz -
MenTaLguY -
Thomas Worthington