Discussion:
[PATCH] Dockable dialogs, and some concerns...
(too old to reply)
Gustav Broberg
2007-03-26 17:20:49 UTC
Permalink
Hi all,

I've been busy with work since the release of 0.45, but now I have
finally found some time to spend on Inkscape again... :)

I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
http://sourceforge.net/tracker/index.php?func=detail&aid=1688508&group_id=93438&atid=604308

The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
about:
Loading Image...
Loading Image...

To compile you'll need gdl >= 0.6.1, the latest version is available
here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2

Gdl is a fairly small UI library developed for IDE:s such as
Anjuta. The main thing it provides is a set of components to build
dockable interfaces.

I realize that it would be better to do this without an additional
library, but right now I think gdl is the best option assuming that we
want a dockable interface.

The pros of using gdl, as I see it, are:

* It provides a lot for free. Dockable items (dialogs in this case)
can be attached and detached to docks, iconified to dock bars and
docked to each other as separate floating groups. Furthermore they
can be stacked as notebook tabs, and complete layouts can be
saved/restored from disk (I haven't got that one working, though).
It would require a major amount of work to reproduce the docking
functionality found in gdl.

* It's still actively developed. Inkscape could benefit from the new
functionality added to gdl.

...and the cons:

* It's yet another library, with all the problems that brings. The
availability could be an issue. Distributions that provide Anjuta
or Screem should have gdl in their repos as well. Merging gdl into
Inkscape's tree is probably a bad idea...

* I haven't tried it on win32 or Mac OS X, so I'm not sure about the
compatibility. It used to require some gnome only libraries, but it
doesn't anymore from what I know.

* It's a C library. There is a C++ wrapper called gdlmm, but it
hasn't been worked on since 2005, and I'm not sure how
complete/stable it is.

The only alternative to gdl that I know of is CurlyAnkles. It has the
same issues with availability and compatibility as gdl, but is less
mature (I'm not aware of any project that uses it yet). On the
positive side it provides other widgets that could improve Inkscape's
interface.

As for the design I've chosen to keep the current UI::Dialog::Dialog
hierarchy as opposed to extending UI::Widget::Panel, which I guess was
planned to be the root class of everything dockable (?). The main
reasons for this were that I wanted to keep the old dialog behavior as
an option and also that I wanted to avoid rewriting the code of the
current dialogs.

The way I did this was to break out much of the functionality of
Dialog::Dialog into the implementations of an interface
Dialog::Behavior. The implementations that extends it are
FloatingBehavior (the current dialog behavior) and DockBehavior. Each
dialog is instantiated with a behavior and the DialogManager handles
them the same way as before, regardless of behavior.

The Dialog::Behavior interface covers most of the functionality of
Gtk::Dialog. FloatingBehavior is just a proxy for a real Gtk::Dialog
(just as before), while DockBehavior tries to emulate the dialog
functionality on a GdlDockItem. This allows all the current dialogs
(under UI::Dialog) to be dockable without rewriting them.

A global preference "options.dialogtype" controls what the kind of
dialogs to create (0 = old/floating, 1 = new/dock).

It's still a work in progress, and I'd be glad to get feedback on the
design, etc. (The class naming could probably be more
accurate/consistent, for instance.)

There's a bunch of known bugs, but I'm not experiencing any major ones
right now. I've probably broken something that used to work with the
floating dialogs, though.

Please note that this patch only works for the GKmm:ified dialogs
under UI::Dialog, so dialogs such as Fill&Stroke and the XML editor
won't be dockable.

If there's an interest in working on this, I could create a branch,
otherwise I'll just drop patches as I proceed. (I intend to continue
to keep it up to date even if there's no plan to merge it -- Inkscape
is pretty much unusable without it for me when using my primary window
manager :)

I'll be on the IRC channel in a near future if anybody would like to
discuss this further...

--
Gustav
Kees Cook
2007-03-26 17:41:54 UTC
Permalink
Post by Gustav Broberg
* It's yet another library, with all the problems that brings. The
availability could be an issue. Distributions that provide Anjuta
or Screem should have gdl in their repos as well. Merging gdl into
Inkscape's tree is probably a bad idea...
libgdl is available on Debian, and all releases of Ubuntu. Based on the
fact that it's in Ubuntu's "main" repo, I would guess most (if not all)
distros have it, so I don't think this should be much of a "con". :)
--
Kees Cook @outflux.net
jiho
2007-03-26 17:42:19 UTC
Permalink
Post by Gustav Broberg
I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
[...]
The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
I love it!
Post by Gustav Broberg
To compile you'll need gdl >= 0.6.1, the latest version is available
here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2
[...]
Post by Gustav Broberg
* I haven't tried it on win32 or Mac OS X, so I'm not sure about the
compatibility. It used to require some gnome only libraries, but it
doesn't anymore from what I know.
gdl 0.7.2 is available on Mac OS X via DarwinPorts so it should not
be a problem to get it. On the other hand, it still requires many
gnome packages to be installed (gnome-session, gnome-desktop,
nautilus, metacity, evolution-data-server etc.). Basically it
requires to install the whole gnome desktop and it may be a bit
overkill just to have dockable windows... too bad.

JiHO
---
http://jo.irisson.free.fr/
Alexandre Prokoudine
2007-03-26 17:51:46 UTC
Permalink
Post by Gustav Broberg
Hi all,
I've been busy with work since the release of 0.45, but now I have
finally found some time to spend on Inkscape again... :)
I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
It looks cool, but fals building on current SVN with gdl 0.6.1:

./cxxtest -Wall -Wformat-security -W -Wpointer-arith -Wcast-align
-Wsign-compare -Woverloaded-virtual -Wswitch -D_FORTIFY_SOURCE=2
-Wno-unused-parameter -g -O2 -MT application/editor.o -MD -MP -MF
"application/.deps/editor.Tpo" \
-c -o application/editor.o `test -f 'application/editor.cpp'
|| echo './'`application/editor.cpp; \
then mv -f "application/.deps/editor.Tpo"
"application/.deps/editor.Po"; \
else rm -f "application/.deps/editor.Tpo"; exit 1; \
fi
./ui/widget/dock.h:51: error: ISO C++ forbids declaration of
'GdlDockBar' with no type
./ui/widget/dock.h:51: error: expected ';' before '*' token

Previously we discussed using CurlyAnkles for docking, which means far
less dependencies.

http://curlyankles.sourceforge.net/widgets_docking.html

Did you have a chance looking at it?

Alexandre
Alexandre Prokoudine
2007-03-26 17:54:11 UTC
Permalink
Post by Alexandre Prokoudine
Previously we discussed using CurlyAnkles for docking, which means far
less dependencies.
Forget this part of email, please :)

Alexandre
Gustav Broberg
2007-03-26 18:26:28 UTC
Permalink
On Mon, 26 Mar 2007 21:51:46 +0400
"Alexandre Prokoudine"
Post by Gustav Broberg
Hi all,
I've been busy with work since the release of 0.45, but now I have
finally found some time to spend on Inkscape again... :)
I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
[...]
Hmm, turns out gdl.h doesn't include everything needed prior to 0.7
(probably because the dockbar which holds iconified dock items wasn't
considered stable :/). I've uploaded a new version to the tracker which
should compile.

--
Gustav
bulia byak
2007-03-26 18:07:49 UTC
Permalink
Post by Gustav Broberg
The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
This is an extremely desirable change. It turns Inkscape from a clunky
and messy Gimp lookalike into a clean, modern-looking application. I'm
all for it.

However, I foresee one problem. Currently all of our dialogs are built
around the "one dialog serves all open windows" concept. Making them
dock to the editing window seems to switch them to the "each window
has its own dialog" paradigm. This therefore may not be as
straightforward, because in each dialog we will also need to find and
fix code which (1) assumes there's always only one copy of the dialog
and (2) switches its state and display when a new window gets focus,
and (3) applies the changes in dialog to the currently active window.

Gustav, have you looked into these problems at all? I suspect the
severity of the required changes varies from dialog to dialog, but at
least for Fill&Stroke it's going to be rather major (although it
hasn't even been ported to GTKmm and Dialog class yet, as are many
other dialogs).
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Bryce Harrington
2007-03-26 18:24:07 UTC
Permalink
Post by bulia byak
Post by Gustav Broberg
The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
This is an extremely desirable change. It turns Inkscape from a clunky
and messy Gimp lookalike into a clean, modern-looking application. I'm
all for it.
However, I foresee one problem. Currently all of our dialogs are built
around the "one dialog serves all open windows" concept. Making them
dock to the editing window seems to switch them to the "each window
has its own dialog" paradigm. This therefore may not be as
straightforward, because in each dialog we will also need to find and
fix code which (1) assumes there's always only one copy of the dialog
and (2) switches its state and display when a new window gets focus,
and (3) applies the changes in dialog to the currently active window.
I think this may not be a showstopper. Currently, the dialogs use the
ACTIVE_DOCUMENT macro or similar to get the currently active document,
and adjust themselves accordingly.

But for the gtkmm'd dialogs, it would be straightforward to refactor
them to use a routine in the dialog manager to get the document (and/or
desktop) instead. The dialog manager is currently treated as a
singleton, but I think it should not be difficult to switch it to be
attached to a specific desktop/document.

Where things could get tricky is if the user docks some dialogs but
leaves others undocked. Perhaps there should be a global dialog
manager, plus ones that are attached to specific desktops. Sorting out
the message handling could be a bit tricky, but not overly so.

Bryce
bulia byak
2007-03-26 18:25:29 UTC
Permalink
Post by bulia byak
However, I foresee one problem. Currently all of our dialogs are built
around the "one dialog serves all open windows" concept. Making them
dock to the editing window seems to switch them to the "each window
has its own dialog" paradigm. This therefore may not be as
straightforward, because in each dialog we will also need to find and
fix code which (1) assumes there's always only one copy of the dialog
and (2) switches its state and display when a new window gets focus,
and (3) applies the changes in dialog to the currently active window.
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents. I personally would
welcome this, although I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Bryce Harrington
2007-03-26 18:32:32 UTC
Permalink
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents. I personally would
welcome this, although I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
I'm fairly certain that abandoning separate windows would meet with a
great deal of criticism. Recalling some of the SDI/MDI debates from
early on the project I'm fairly certain there are strong feelings on
this topic. ;-)

Bryce
Adib Taraben
2007-03-26 20:03:45 UTC
Permalink
I have a dual monitor setup on my desk. I prefer to maximize the main
window on one monitor and have the tools also on the other.

I do not want to minimize the effective canvas size by other childs.

just my 2 cents,

Adib.
---
Post by Bryce Harrington
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents. I personally would
welcome this, although I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
I'm fairly certain that abandoning separate windows would meet with a
great deal of criticism. Recalling some of the SDI/MDI debates from
early on the project I'm fairly certain there are strong feelings on
this topic. ;-)
Bryce
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Gail Banaszkiewicz
2007-03-26 18:34:58 UTC
Permalink
Post by bulia byak
I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
Personally I have always preferred the model where there is one
encompassing program window, and then sub windows contained within it.
I can't stand millions of separate windows (i.e. GIMP). The taskbar
only shows one item for the program instead of one for each document
open. If the tabs you are talking about could be "minimized" (using the
term loosely) you could achieve the side-by-side behavior.

Here is a screen shot showing what I mean:
Loading Image...

Just something to keep in the back of your mind...

As a side note, I am highly in favor of docking things. The reason is
the same as why I like the model mentioned above: I like things to be
organized and organizable! I hope you can get dockers working well for
all OS's without too much hassle.

Gail
Jon A. Cruz
2007-03-26 19:58:35 UTC
Permalink
Post by Gail Banaszkiewicz
Personally I have always preferred the model where there is one
encompassing program window, and then sub windows contained within it.
I can't stand millions of separate windows (i.e. GIMP). The taskbar
only shows one item for the program instead of one for each document
open. If the tabs you are talking about could be
"minimized" (using the
term loosely) you could achieve the side-by-side behavior.
http://gbanaszk.oasis.nexus.carleton.ca/SummerOfCode/
docsSideBySide.png
Hi Gail,

What you are describing there is classic MDI, and was officially
deprecated on Windows back when Microsoft first introduced Windows 95.

There had been reasons for it back in the days before cooperative
multitasking, but for the most part MDI itself was deprecated for
very good, solid reasons.

Catch me on Jabber some time and I'm sure I'll be able to discuss my
viewpoint in more detail. :-)
Gail Banaszkiewicz
2007-03-26 20:58:11 UTC
Permalink
I only show the windows side my side to say that it is possible. Tabs
would make me happier in the end, like how Dreamweaver works (at least
in MX 2004, my latest version). I just personally hate having multiple
items on the task bar for one piece of software - I find it irritating.
Probably has a lot to do with using Windows more than Linux and not
having multiple desktops. Or maybe I'm just old school.

I'm wing-tip on IRC btw :)
Post by Jon A. Cruz
What you are describing there is classic MDI, and was officially
deprecated on Windows back when Microsoft first introduced Windows 95.
Jon A. Cruz
2007-03-26 21:06:53 UTC
Permalink
Post by Gail Banaszkiewicz
I only show the windows side my side to say that it is possible. Tabs
would make me happier in the end, like how Dreamweaver works (at least
in MX 2004, my latest version). I just personally hate having
multiple
items on the task bar for one piece of software - I find it
irritating.
Probably has a lot to do with using Windows more than Linux and not
having multiple desktops. Or maybe I'm just old school.
Oh, that's a completely separate item.

Tabbed work is a slight difference, but then if you only care about
multiple items, Windows provides for having those collapsed. Also,
additionally windows can be flagged to not show up as top level.
Alan Horkan
2007-03-26 22:06:16 UTC
Permalink
Post by Gail Banaszkiewicz
Post by bulia byak
I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
Personally I have always preferred the model where there is one
encompassing program window, and then sub windows contained within it.
I can't stand millions of separate windows (i.e. GIMP). The taskbar
only shows one item for the program instead of one for each document
open. If the tabs you are talking about could be "minimized" (using the
term loosely) you could achieve the side-by-side behavior.
http://gbanaszk.oasis.nexus.carleton.ca/SummerOfCode/docsSideBySide.png
That screenshot is a classic example of Multiple Document Interface (MDI).
Microsoft Word abandoned this approach in about 2000 (if I recall
correctly, possibly earlier) as the concept of a single document per
window was/is considered easier for users to grasp. You might recall
marketing and to a lesser extent usability* are strengths of Microsoft,
love them or loathe them.

(Boring explanation to follow to hopefully avoid ambiguity in the
disctussion:

What the GNU Image Manipulation Program (GIMP) does is very specifically a
Controlled Single Document Interface (CSDI), where the toolbox acts as the
main control window.

Applications ported from the Macintosh to Windows often use a Controlled
Single Document Interface but more often the Menu bar window acts as the
main control window.

Inkscapes uses a Single Document Interface much closer to what the rest of
Gnome users.)

Hope that helps
--
Alan

* Usability but in the sense of sticky and easy to get into usability if
not real long term usability and effienciency in many cases.
Juan Miguel Ramirez
2007-03-26 22:12:33 UTC
Permalink
Only a few words :P :
I think the best option about "to dock or not dock" is to let the user
choose between them. That's IMHO the best decision.
Gail Banaszkiewicz
2007-03-26 22:18:04 UTC
Permalink
I'm pretty sure I already got schooled on this ;)
Post by Alan Horkan
That screenshot is a classic example of Multiple Document Interface (MDI).
Microsoft Word abandoned this approach in about 2000 (if I recall
correctly, possibly earlier) as the concept of a single document per
window was/is considered easier for users to grasp.
Alan Horkan
2007-03-26 22:25:52 UTC
Permalink
Subject: Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
I'm pretty sure I already got schooled on this ;)
Apologies. Difficult to read the whole thread before replying.

Almost pointed out how the people praising the GIMP or Sodipodi and the
many undocked windows were usually using multi head setups or at least
lots of virtual deskspaces but again that consideration has already been
mentioned.

Eagerly awaiting comment from Bulia on how he thinks a Tabbed interface
can coexist with the need to show multiple pages (not yet in SVG but
already in PDF and OpenDocument Draw).
--
Alan
Bryce Harrington
2007-03-27 00:02:38 UTC
Permalink
Post by Alan Horkan
Eagerly awaiting comment from Bulia on how he thinks a Tabbed interface
can coexist with the need to show multiple pages (not yet in SVG but
already in PDF and OpenDocument Draw).
Well, multi-page could be achieved entirely in-canvas, like
a word processor, PDF viewer, or scribus does it, in which case it
wouldn't be using a tab UI.

Draw doesn't use tabs for pages, but rather a sidebar selector. That
may be a handy approach for navigating some kinds of multi-page drawings
such as presentations or a website layout, but I'm not certain it'd be
the best general purpose way of nagivating multiple pages.

Scribus has an interesting approach that distinguishes between 'page'
and 'paper', allowing you to have multiple pages for a given piece of
paper (such as with a tri-fold brochure).

Anyway, it seems there's a number of approaches for handling multiple
pages that don't rely on tabs, so I would think that the multi-page
feature would not interfere with a choice of using tabs for
multi-document selection.

Bryce
Jon A. Cruz
2007-03-27 00:45:03 UTC
Permalink
Post by Bryce Harrington
Anyway, it seems there's a number of approaches for handling multiple
pages that don't rely on tabs, so I would think that the multi-page
feature would not interfere with a choice of using tabs for
multi-document selection.
I agree.

In all, I've seen that tabs work well for "documents" and not for
"pages".
Alan Horkan
2007-03-27 02:17:38 UTC
Permalink
Post by Jon A. Cruz
Post by Bryce Harrington
Anyway, it seems there's a number of approaches for handling multiple
pages that don't rely on tabs,
So something like a pages dialog as there is a layers dialog, or I suppose
things could end up rather resembling an Integrated development enviroment
like Anjuta?
Post by Jon A. Cruz
In all, I've seen that tabs work well for "documents" and not for
"pages".
The most "successful" use of tabs has been Firefox, a web browser, or to
put it another way a viewer rather than an editor. Integrated Development
Enviroments like Anjuta do have tabbed interfaces, do many other editing
applications offer tabbed interfaces such as these
Post by Jon A. Cruz
Post by Bryce Harrington
so I would think that the multi-page feature would not interfere with
a choice of using tabs for multi-document selection.
I see you are all pretty enthusiastic about using Tabs and having multiple
documents open at once. I would not be so enthusiastic, Tabbed MDI is
better than MDI but it still has many of the same problems of MDI. Aware
of the limitations the default case in applications like Firefox do a good
job keeping tabs out of the way of user who are less likely to benefit
from them (as opposed to gedit which has tabs for everyone, like it or
not).

While I'm sure most people here have many documents open at once, I really
wish I could show you the type of users who ask "where did my documents
go?" when they have more than one window open and the first window is
hidden obscured by the second.

I guess the stated goal of Inkscape wanting to attract "contributor users"
raises the bar quite high and implies usability in terms of efficiency for
frequent technical users over learnability for artists with less techincal
skills. Which is fair enough so long as it is clearly understood and
users (and evangelists) are expecting the learning curve.

Yeah I'm a big sceptic of Tabs and that puts me out of the mainstream.
Sure they get the job done but Window and document workflow management is
still a great big mess of a problem.
--
Alan
Bryce Harrington
2007-03-27 03:27:21 UTC
Permalink
Post by Alan Horkan
Post by Jon A. Cruz
Post by Bryce Harrington
Anyway, it seems there's a number of approaches for handling multiple
pages that don't rely on tabs,
So something like a pages dialog as there is a layers dialog, or I suppose
things could end up rather resembling an Integrated development enviroment
like Anjuta?
Well, like I think I said, I suspect the ideal approach would be for the
primary nagivation to be in-canvas. So instead of just seeing the
outline of a single page when you pull up Inkscape, you'd see several
adjacent page outlines, and would simply pan or scroll around to see
the other pages. An advantage of this approach would be to allow
non-linear page layouts, such as if you're doing a book with left/right
pages, or doing a large drawing or banner and want to print it out on
multiple smaller pieces of paper. For instance, imagine wanting to do a
full scale guitar drawing made up of six 8.5x11 sheets printed and
arranged in a 2x3 layout. Again, look at Scribus for a general idea.

Anyway, I don't know what the ideal approach is, but knowing the
"Inkscape way" to approach things like this is to do it as general as
possible, I think it's a good idea to not limit thinking to linear page
flows, but to open it up as much as possible. I'd love to see Inkscape
used for lite word processing and presentations, but really Inkscape's
strength is in creating drawings, so its page layout system really needs
to be designed to open maximum flexibility for that style of usage.

Of course, all of this discussion is moot until someone gets an itch to
actually implement multi-page support and goes ahead and does it. ;-)
Post by Alan Horkan
Post by Jon A. Cruz
In all, I've seen that tabs work well for "documents" and not for
"pages".
The most "successful" use of tabs has been Firefox, a web browser, or to
put it another way a viewer rather than an editor. Integrated Development
Enviroments like Anjuta do have tabbed interfaces, do many other editing
applications offer tabbed interfaces such as these
If it is decided to add a tabbed UI style to Inkscape, I do hope we
follow Firefox's approach of allowing *both* tabbed or separate windows.
While this makes for additional menu entries, I find sometimes it makes
sense to work with multiple tabs (like all documents related to one
project), and sometimes to work with independent windows. Usually I end
up with a mix of both. For drawings in Inkscape, I could easily imagine
heavy duty use benefitting from being able to mix both UI modes, or
switch between them as makes sense.

Something to keep in mind is that Inkscape differs from other
applications like Firefox in that it relies heavily on dialogs, so going
with firefox's approach of allowing *both* tabbed and non-tabbed windows
is not a trivial matter. But I think it can be done, given enough
code. ;-)
Post by Alan Horkan
Post by Jon A. Cruz
Post by Bryce Harrington
so I would think that the multi-page feature would not interfere with
a choice of using tabs for multi-document selection.
I see you are all pretty enthusiastic about using Tabs and having multiple
documents open at once. I would not be so enthusiastic, Tabbed MDI is
better than MDI but it still has many of the same problems of MDI.
Actually you misread me. I currently favor staying with the current SDI
style, dislike MDI, and am neutral with regards to a tabbed UI.
However, realistically I know that given the strong interest in a
multi-document UI, it's likely if someone codes it up with tabs, the
patch is going to be accepted. So in practicality I think an optional
tabbed UI could be the ideal compromise, especially if it doesn't
prohibit using it in an SDI style with floating dialogs.

(Honestly, I think given the size of our userbase, were we to switch to
a tabbed-only UI, we'd have a very vocal minority on our hands. We
would best introduce tabbed UI as an opt-in thing people can turn on ala
Firefox.)
Post by Alan Horkan
While I'm sure most people here have many documents open at once, I really
wish I could show you the type of users who ask "where did my documents
go?" when they have more than one window open and the first window is
hidden obscured by the second.
No need, I think we all have family members who have asked this exact
question. ;-)
Post by Alan Horkan
I guess the stated goal of Inkscape wanting to attract "contributor users"
raises the bar quite high and implies usability in terms of efficiency for
frequent technical users over learnability for artists with less techincal
skills. Which is fair enough so long as it is clearly understood and
users (and evangelists) are expecting the learning curve.
Correct. Also keep in mind the "where did my documents go?" question is
a computer system learning curve issue, not just an Inkscape-specific
issue. I'd guess the user would run into this problem with more generic
things like web browsers, email, system dialogs, and the likes.
Post by Alan Horkan
Yeah I'm a big sceptic of Tabs and that puts me out of the mainstream.
Sure they get the job done but Window and document workflow management is
still a great big mess of a problem.
IIRC, one of Jon Cruz' salient points is that window management (and, as
a consequence, document workflow management) is something we ought to
expect the _window manager_ to be solving. Addressing it at the
application layer through things like MDI is kludging around
inadequacies in window managers. And this is a whole other can of
worms. ;-)

So best I think we can do is make things as generic and flexible as
possible, and enable as many different workflows as possible.

Bryce
Pierre-Luc Auclair
2007-03-27 15:07:40 UTC
Permalink
Post by Bryce Harrington
Post by Alan Horkan
While I'm sure most people here have many documents open at once, I
really wish I could show you the type of users who ask "where did my
documents go?" when they have more than one window open and the first
window is hidden obscured by the second.
No need, I think we all have family members who have asked this exact
question. ;-)
I'm sorry but I really think this is a non-argument from an accessibility and
usability POV. This is almost assuming the user is too stupid to learn how a
specific application works. Anybody can be taught, and anybody who is able to
use Inkscape should be able to use it.

The analogy with MS Word is wrong as Word is a totally different kind of
application and targets different user bases. No to mention Word isn't
exactly the greatest example of UI usability (pre MSO2007).

IMO it is much less convenient to allow a non-controlled taskbar to handle the
arrangement of documents rather than managing them from within the program
itself.
MenTaLguY
2007-03-27 16:15:53 UTC
Permalink
Post by Pierre-Luc Auclair
Post by Bryce Harrington
Post by Alan Horkan
While I'm sure most people here have many documents open at once, I
really wish I could show you the type of users who ask "where did my
documents go?" when they have more than one window open and the first
window is hidden obscured by the second.
No need, I think we all have family members who have asked this exact
question. ;-)
I'm sorry but I really think this is a non-argument from an accessibility
and usability POV. This is almost assuming the user is too stupid to learn how
a specific application works. Anybody can be taught, and anybody who is able
to use Inkscape should be able to use it.
Hmm. By that same token, is it right to assume that such users can't be taught to use the standard window management in their environment? If they learn that skill, it transfers to (and from) other applications. One way or the other we are going to be violating the expectations of some inexperienced users, so given a choice I would prefer not to punish those who have begun to learn to use the standard window management facilities.

It's also not clear to me that whatever weird non-standard approach we implemented would be really easier to learn for such a user -- the taskbar is not the most convenient thing in the world, but showing a button per open window is pretty obvious, and (unlike a control in an application window) it cannot be hidden if a window is in the wrong place (e.g. partly offscreen).

For more advanced users, there are already customizable window managers which do things like group related windows into a single tabbed window. They will not be happy either, if we subvert that functionality by our own ersatz window management scheme.

-mental
Alan Horkan
2007-03-27 18:27:25 UTC
Permalink
Date: Mon, 26 Mar 2007 20:27:21 -0700
Cc: Inkscape is a vector graphics editor
Subject: Re: [Inkscape-devel] Multi-page UI (was: Dockable dialogs,
and some concerns...)
Post by Alan Horkan
Post by Bryce Harrington
Anyway, it seems there's a number of approaches for handling multiple
pages that don't rely on tabs,
So something like a pages dialog as there is a layers dialog, or I suppose
things could end up rather resembling an Integrated development enviroment
like Anjuta?
Well, like I think I said, I suspect the ideal approach would be for the
primary nagivation to be in-canvas. So instead of just seeing the
outline of a single page when you pull up Inkscape, you'd see several
adjacent page outlines, and would simply pan or scroll around to see
the other pages.
Laser printers can print very close to the edge of a page, home inkjet
printers dont even come close. The concept of page can get a bit weird
and surprising for users, and most people end up wasting a bunch of paper.

Maybe part of my difficulty with this is the existing page concept in
inskape on on hand has a sort of infinite canvas and then only part of
that is intended as a printable page. There is was a trick/habit in
Macromedia flash to use the off page areas as kind of a scap area (and it
is a habit I think inkscape users might be taking advantage of) but when
you go and put individual pages right beside each other that work habit is
not an option.

Users however (as can be seen from bug reports) are certainly expecting
the different kinds of layouts you speak of, some of which could be
handled simply by better print control fitting the drawing to the desired
pages, not necessarily needing to setup all that information in program in
advance.
Post by Alan Horkan
documents open at once. I would not be so enthusiastic, Tabbed MDI is
better than MDI but it still has many of the same problems of MDI.
Actually you misread me. I currently favor staying with the current SDI
style, dislike MDI, and am neutral with regards to a tabbed UI.
However, realistically I know that given the strong interest in a
multi-document UI, it's likely if someone codes it up with tabs, the
patch is going to be accepted. So in practicality I think an optional
tabbed UI could be the ideal compromise, especially if it doesn't
prohibit using it in an SDI style with floating dialogs.
(Honestly, I think given the size of our userbase, were we to switch to
a tabbed-only UI, we'd have a very vocal minority on our hands. We
would best introduce tabbed UI as an opt-in thing people can turn on ala
Firefox.)
Post by Alan Horkan
Yeah I'm a big sceptic of Tabs and that puts me out of the mainstream.
Sure they get the job done but Window and document workflow management is
still a great big mess of a problem.
IIRC, one of Jon Cruz' salient points is that window management (and, as
a consequence, document workflow management) is something we ought to
expect the _window manager_ to be solving.
Except unfortunately we have windows users, and to a lesser extent Mac and
Gnome users who aren't going to be tweaking things much eathier so
applicatoins cannot abdicate responsibility much as we might like to.
Addressing it at the application layer through things like MDI is
kludging around inadequacies in window managers. And this is a whole
other can of worms. ;-)
can open, worms everywhere.
So best I think we can do is make things as generic and flexible as
possible, and enable as many different workflows as possible.
... which without enough restraint gives us an airplane cockpit user
interface with a baffling number of choices. Realistically though I'd
guess Inkscape to err more on the side of providing the option (like KDE)
than leaving it out so users dont get confused or shoot themselves in the
foot (the Gnome approach, which I think anyone doing tech support will
thank you for, not yet a huge contstrain of inkscape but we have a fair
few Frequently Asked Questions).
--
Alan
Jon A. Cruz
2007-03-27 19:23:34 UTC
Permalink
Post by Alan Horkan
Post by Bryce Harrington
IIRC, one of Jon Cruz' salient points is that window management (and, as
a consequence, document workflow management) is something we ought to
expect the _window manager_ to be solving.
Except unfortunately we have windows users, and to a lesser extent Mac and
Gnome users who aren't going to be tweaking things much eathier so
applicatoins cannot abdicate responsibility much as we might like to.
No, those fall exactly under my main point.

Even in MS Windows there is a window manager. It just happens to be
spread out all over their code base, instead of being nicely layered
like on X11.

Anyway, the point is still very valid that we need to let the OS keep
its own way of doing things. In fact, many of the problem on Windows
and Macs come from points where GTK+ does things its own way. One
main point is dialogs and the task bar. Many of the end user
complaints and confusions we get are from too many of our windows
showing up in the taskbar. If only each main document did, things
would be nicer for Windows users. Then one would also be able to use
the collapse feature where the "documents" from a single app get
collapsed to a single button when a few are open.

So if when we are running on MS Windows we try to have the app do
things to allow the MS Windows window manager to do things they way
they work on that platform, then problems are reduced.


Additionally, if we hook into the standard OS provisions there, then
the power users who have add-ons to change behavior will get the
modified behavior from our app "for free". So both standard MS
Windows users and power MS Windows users win.
Bryce Harrington
2007-03-27 20:00:07 UTC
Permalink
Post by Alan Horkan
Post by Bryce Harrington
Well, like I think I said, I suspect the ideal approach would be for the
primary nagivation to be in-canvas. So instead of just seeing the
outline of a single page when you pull up Inkscape, you'd see several
adjacent page outlines, and would simply pan or scroll around to see
the other pages.
Laser printers can print very close to the edge of a page, home inkjet
printers dont even come close. The concept of page can get a bit weird
and surprising for users, and most people end up wasting a bunch of paper.
Obviously this is just another reason why distinguishing between "page"
and "paper" is important. With enough generality and flexibility, I
could specify my pages are 7.5"x10" (printable), while using 8.5"x11"
paper. My canvas would then be composed of several 7.5"x10" rectangles
side by side. It would be left to me to trim paper edges to compensate.

In an ideal amount of generality, the user could choose to see both page
and paper boundaries. Perhaps they are making a comic and wish to
balance the margin areas against the space between comic panes or
something.

However all of this is just one speculation, until someone codes. Point
is, doing the page management in-canvas opens a lot of potential and
flexibility that wouldn't be as easily achieved as if it were done
through UI widgetry. (much as I like UI widgetry)
Post by Alan Horkan
Maybe part of my difficulty with this is the existing page concept in
inskape on on hand has a sort of infinite canvas and then only part of
that is intended as a printable page. There is was a trick/habit in
Macromedia flash to use the off page areas as kind of a scap area (and it
is a habit I think inkscape users might be taking advantage of) but when
you go and put individual pages right beside each other that work habit is
not an option.
Sure it is. Your scrap area is just that area not currently defined by
any page boundaries.
Post by Alan Horkan
Users however (as can be seen from bug reports) are certainly expecting
the different kinds of layouts you speak of, some of which could be
handled simply by better print control fitting the drawing to the desired
pages, not necessarily needing to setup all that information in program in
advance.
Right. Also, notice the number of requests for printing at Kinko's or
other such print shops. A very poor way to solve the inkjet/laserjet
issue you mentioned earlier would be to automatically detect and set up
page and paper sizes based on the attached printer; if the document is
prepared and tested on a machine with an inkjet and then taken to a
place with a laserjet, the user could be very unhappy. I'm not sure
what the best solution to this particular workflow is, but the more
flexibility built into the program, the better. I would worry based on
how this works in other programs that an automatic UI widget based would
increase the chance of lousing up this particular usage model. At least
with the in-cavas approach, if the user is able to view both page and
paper boundaries, then hopefully it would be more visually evident
what's going on.
Post by Alan Horkan
Post by Bryce Harrington
IIRC, one of Jon Cruz' salient points is that window management (and, as
a consequence, document workflow management) is something we ought to
expect the _window manager_ to be solving.
Except unfortunately we have windows users, and to a lesser extent Mac and
Gnome users who aren't going to be tweaking things much eathier so
applicatoins cannot abdicate responsibility much as we might like to.
Not sure what your point here is. It's not a matter of tweaking. My
out-of-the-box Ubuntu Feisty GNOME system automatically groups windows.
I don't use Macs, but I understand they also have good window
grouping/management out of the box.

Also note I said "expect" rather than "rely on". Admittedly there are
LCD users and inferior windowing systems that don't meet this. But we
should not fall into the trap of designing for the LCD and ending up
crippling those on good systems. When you design for imaginary LCD
users, you run the risk of optimizing the program for users that don't
actually exist.
Post by Alan Horkan
Post by Bryce Harrington
So best I think we can do is make things as generic and flexible as
possible, and enable as many different workflows as possible.
... which without enough restraint gives us an airplane cockpit user
interface with a baffling number of choices. Realistically though I'd
guess Inkscape to err more on the side of providing the option (like KDE)
than leaving it out so users dont get confused or shoot themselves in the
foot (the Gnome approach, which I think anyone doing tech support will
thank you for, not yet a huge contstrain of inkscape but we have a fair
few Frequently Asked Questions).
My girlfriend is a 5th grade teacher and several of her students have
picked up Inkscape. I once talked to her about a simplified Inkscape
that would be more accessible for children. But she was emphatic that
5th graders are quite capable of learning adult tools, they just need
time to learn and experiment. They're not cowards and they won't be
scared by a powerful UI.

The things that are important for neophyte users are the same things
that are important to any user: That the program is rock solid stable,
well documented, has a well-thought-out UI that doesn't get in your way,
and can be used for a large variety of tasks.

Further, as I've pointed out before, our principle userbase is not
neophytes or the occasional user, but rather the heavy/power users who
are likely to become contributors. Where neophytes and occasional users
are important is that every heavy/power Inkscape user starts off as one
of those. We don't need to dumb down the interface or disable a lot of
flexibility for neophytes; we just need to avoid scaring them off right
away, give them a good experience, and pack enough generality and power
that they can grow with the program. We're going after the
Visio/Illustrator crowd, not the MS Paint crowd.

A comment from just a few minutes ago on IRC:

What happens is, the inside of the line is filled. What I am drawing
freehand, say, is a circle. So, I end up with wha looks like a donut
oh, crap. I am wrong.
Stupid me; ignore me.
I was forgetting to join the endnodes
sorry :/
this program is effing BRILLIANT

A little confusion at first, but a lot of love moments later. ;-)

Bryce
Alan Horkan
2007-03-27 22:59:36 UTC
Permalink
Post by Bryce Harrington
Obviously this is just another reason why distinguishing between "page"
and "paper" is important. With enough generality and flexibility, I
could specify my pages are 7.5"x10" (printable), while using 8.5"x11"
paper. My canvas would then be composed of several 7.5"x10" rectangles
side by side. It would be left to me to trim paper edges to compensate.
Post by Alan Horkan
Maybe part of my difficulty with this is the existing page concept in
inskape on on hand has a sort of infinite canvas and then only part of
that is intended as a printable page. There is was a trick/habit in
Macromedia flash to use the off page areas as kind of a scap area (and it
is a habit I think inkscape users might be taking advantage of) but when
you go and put individual pages right beside each other that work habit is
not an option.
Sure it is. Your scrap area is just that area not currently defined by
any page boundaries.
Post by Alan Horkan
Users however (as can be seen from bug reports) are certainly expecting
the different kinds of layouts you speak of, some of which could be
handled simply by better print control fitting the drawing to the desired
pages, not necessarily needing to setup all that information in program in
advance.
Right. Also, notice the number of requests for printing at Kinko's or
other such print shops. A very poor way to solve the inkjet/laserjet
My point was not try to do too much in inkscape, the alternative being to
push for GtkPrint.
Post by Bryce Harrington
Post by Alan Horkan
Post by Bryce Harrington
So best I think we can do is make things as generic and flexible as
possible, and enable as many different workflows as possible.
... which without enough restraint gives us an airplane cockpit user
interface with a baffling number of choices. Realistically though I'd
guess Inkscape to err more on the side of providing the option (like KDE)
than leaving it out so users dont get confused or shoot themselves in the
foot (the Gnome approach, which I think anyone doing tech support will
thank you for, not yet a huge contstrain of inkscape but we have a fair
few Frequently Asked Questions).
My girlfriend is a 5th grade teacher and several of her students have
picked up Inkscape. I once talked to her about a simplified Inkscape
that would be more accessible for children. But she was emphatic that
5th graders are quite capable of learning adult tools, they just need
time to learn and experiment.
They're not cowards and they won't be scared by a powerful UI.
The word "coward" is terribly prejudicial (and I know you dont mean much
by it but that doesn't make the words any less loaded or the attitude any
less common). Forgive the user.

the Windows Icons Menu Pointer (WIMP) system was designed "for children"
and intended to be easier than the command line. turns out that although
most people are capable of using the command line the easier solution is
rather more popular.

(Would mentioning how the easier more "user friendly" Xemacs displaced
emacs be a more relatable example for some.)
Post by Bryce Harrington
The things that are important for neophyte users are the same things
that are important to any user: That the program is rock solid stable,
well documented, has a well-thought-out UI that doesn't get in your way,
and can be used for a large variety of tasks.
Further, as I've pointed out before, our principle userbase is not
neophytes or the occasional user, but rather the heavy/power users who
are likely to become contributors. Where neophytes and occasional users
are important is that every heavy/power Inkscape user starts off as one
of those.
The beginner and the infrequent user suffer the same learning problem and
they suffer it over and over again. To appeal beyond those who use
computers heavily (even if they are the primary target) the shallower the
learning curve the better and as I mentioned before the superficial ease
of use can often trap users in (and conversely user often balk at the
likes of Blender and GIMP).
Post by Bryce Harrington
We don't need to dumb down the interface or disable a lot of
flexibility for neophytes; we just need to avoid scaring them off right
away, give them a good experience, and pack enough generality and power
that they can grow with the program. We're going after the
Visio/Illustrator crowd, not the MS Paint crowd.
There is no clear line here, the balance is hard to get right. Having
good defaults always helps, less complexity without sacrificing
flexibility. Offering many small options is much like microptimising,
sure it works but the problems can be solved at a bigger level.
Post by Bryce Harrington
What happens is, the inside of the line is filled. What I am drawing
freehand, say, is a circle. So, I end up with wha looks like a donut
oh, crap. I am wrong.
Stupid me; ignore me.
I was forgetting to join the endnodes
users tend to blame themselves for not understanding ... this might be
another opportunity to improve the affordance and somehow hint to user
that the two ends of the line can be connected.
Post by Bryce Harrington
A little confusion at first, but a lot of love moments later. ;-)
... and I'll probably keep suggesting they could have more love and less
confusion.
Post by Bryce Harrington
However all of this is just one speculation, until someone codes. Point
--
Alan
Thorsten Wilms
2007-03-28 07:55:25 UTC
Permalink
Post by Bryce Harrington
Obviously this is just another reason why distinguishing between "page"
and "paper" is important. With enough generality and flexibility, I
could specify my pages are 7.5"x10" (printable), while using 8.5"x11"
paper. My canvas would then be composed of several 7.5"x10" rectangles
side by side. It would be left to me to trim paper edges to compensate.
So far I never considered using Inkscape for a print job.

With printing in mind, distinguishing between "page" and "paper" is
indeed important. Take for example a real world task of creating
a portfolio with no margins (graphics reaching to the edge). Due
to imprecision in printing, you need bleed (at least 3 mm in each
direction for offset printing, rather more if it's a copy-shop job).
And cropping marks. If you also need a PDF for screen display, you
either need a tool that can crop on export, or you need to create
2 versions.

In the PDF and printing world, things are a bit more complicated than
just "page" / "paper", though:
http://www.tgreer.com/printforum/showthread.php?p=265
http://bugs.scribus.net/view.php?id=1041
--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
David Christian Berg
2007-04-01 17:22:06 UTC
Permalink
Post by Thorsten Wilms
So far I never considered using Inkscape for a print job.
I already used Inkscape for printjobs. however, I needed to export to
png because of missing CMYK support.

Still Inkscape is a powerful tool for the printsector, if CMYK and
multipage support is added. So far I love using it to create a concept
for a poster or magazine layout, and then I'll finish it in InDesign or
Scribus.

being used to these publishing softwares, I totally agree with the idea
of having multiple pages in one canvas, just scrolling down...
It is logical that the paper size should be shown, because a user will
want to know, what the finished product will look like. There then
should be a printing margin, a layout margin (framing the main place for
putting element) as well as an adjustable bleed.
A view setting will allow the user to hide everything but the pages and
also blank the parts on the page, that are not printable.
A menu like the layer menu will allow easy navigation between pages.

As for the tabbed vs. multiple windows interface thing: Somebody said
before that with the tabbed interface it must be also possible to open
several windows. As long as that is ensured, there is nothing wrong with
that approach whatsoever. Also a split-pane view could be implemented
with the tabbed interface (showing all tabs above/under each pane).

As for the docked tool windows: This really would be a great step
forward in helping to clean the interface. I talked about this before in
several bug reports, suggesting a docked property box like the one
scribus has, but docked.

Thanks for Inkscape!

David
Alexandre Prokoudine
2007-03-26 18:43:17 UTC
Permalink
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents.
And how do you see mulltiple pages GUI implemented then?

Alexandre
Joshua A. Andler
2007-03-26 18:52:27 UTC
Permalink
Post by Alexandre Prokoudine
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents.
And how do you see mulltiple pages GUI implemented then?
What about how Scribus handles multiple pages? Or Acrobat which is a
different method (and less appealing to me personally).

-Josh
momo
2007-03-28 17:52:45 UTC
Permalink
Post by Alexandre Prokoudine
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents.
And how do you see mulltiple pages GUI implemented then?
Take a look at Corel Draw (see attached screenshot, the document's pages are
colored in blue)

Having several multipage documents in one single program window is IMO a
good concept...

Molumen


I'm protected by SpamBrave
http://www.spambrave.com/
Jon A. Cruz
2007-03-28 17:57:46 UTC
Permalink
Post by momo
Having several multipage documents in one single program window is
IMO a good concept...
IMO it is a very poor concept, and dates from the time waaaaay back
when OS's weren't really multitasking and each app had to be it's own
universe.
momo
2007-03-28 18:14:40 UTC
Permalink
Ok, then tell me why the concept of multiple document windows in a single program window it still used in Indesign, Corel, Photoshop, Illustrator, XaraXtreme, and many other professional programs? Having several program windows for every opened document is confusing, specially when working with lots of documents in several applications at one time. You'll end up with a whole bunch of windows all over the screen...

It is a question of ergonomy, multitasking has nothing to do in this...

Molumen


----- Original Message -----
From: Jon A. Cruz
To: momo
Cc: Alexandre Prokoudine ; inkscape-***@lists.sourceforge.net
Sent: Wednesday, March 28, 2007 7:57 PM
Subject: Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...


On Mar 28, 2007, at 10:52 AM, momo wrote:


Having several multipage documents in one single program window is IMO a good concept...



IMO it is a very poor concept, and dates from the time waaaaay back when OS's weren't really multitasking and each app had to be it's own universe.



I'm protected by SpamBrave
http://www.spambrave.com/
Donn
2007-03-28 18:27:46 UTC
Permalink
Post by momo
It is a question of ergonomy, multitasking has nothing to do in this...
Have to agree. Many entire Inkscape instances is downright confusing.


/d
Jon A. Cruz
2007-03-28 18:30:54 UTC
Permalink
Post by Donn
Post by momo
It is a question of ergonomy, multitasking has nothing to do in this...
Have to agree. Many entire Inkscape instances is downright confusing.
Multiple Inkscape instances is a separate problem. Also having too
many windows listed in the taskbar is a separate one. Those are not
directly tied to MDI or non-MDI.
Jon A. Cruz
2007-03-28 18:29:18 UTC
Permalink
Post by momo
Ok, then tell me why the concept of multiple document windows in a
single program window it still used in Indesign, Corel, Photoshop,
Illustrator, XaraXtreme, and many other professional programs?
Having several program windows for every opened document is
confusing, specially when working with lots of documents in several
applications at one time. You'll end up with a whole bunch of
windows all over the screen...
It is a question of ergonomy, multitasking has nothing to do in this...
Simple.

The main reason many of those programs do that is due to legacy
behavior in coming from Windows 3.1 or Mac OS 4.

In fact, when Microsoft introduced Windows 95 their official
requirements were that applications drop MDI and switch to SDI. That
was due to many studies done on the efficiency of MDI, etc. However,
since the large vendors already had programs that did things the
ancient way, they were able to get "grandfathered" in with exceptions.

To give a counter example, think of a designer working on two jobs.
One graphic for client A and one graphic for client B. The
requirements for client B's artwork happen to be in a MS Word
document. So the artist opens up that "MS Word doc for client B" and
also the "Photoshop document for client B" and has them side-by side
on the screen. That way he can copy and past and also just read
things now and then from the requirements as he does the design. This
is especially useful if some rough storyboarding or such diagrams are
included in the Word doc.

However, during that day he also has to complete some work for client
A, and so has the "Photoshop document for client A" open.

Artists generally find it very annoying when doing the work for
client B if just clicking on the client B artwork document causes the
client A artwork document to *also* come forward and obscure the
client B requirements/design doc.

Or think of the case where an artist is referring to some MS Word
requirement/design doc and *also* some web page on a specific
technique. It's *very* counter productive if just bringing up the
photoshop document brings up the full "photoshop application" with
it's MDI parent frame that takes over the entire screen. (That's what
you showed in your example screenshot)

In general, studies keep showing that it's far more productive for
people to work with "documents" instead of working with "applications"


Yes, it's a question of ergonomy... however they MDI paradigm *came*
from the ancient requirements of older operating systems and has just
hung around because "that's the way we've always done it"
Thorsten Wilms
2007-03-28 18:44:49 UTC
Permalink
Post by momo
Ok, then tell me why the concept of multiple document windows in a single
program window it still used in Indesign, Corel, Photoshop, Illustrator,
XaraXtreme, and many other professional programs? Having several program
windows for every opened document is confusing, specially when working with
lots of documents in several applications at one time. You'll end up with
a whole bunch of windows all over the screen...
It is a question of ergonomy, multitasking has nothing to do in this...
Jon A. Cruz
2007-03-28 18:57:59 UTC
Permalink
On Mar 28, 2007, at 11:44 AM, Thorsten Wilms wrote:

Thanks for the list. It's actually a bit outdated, especially for MS
Windows users.
* Many child windows do not fill up the OS task management
interface, as they
are hierarchically organized. Users simply switch applications.
As of Windows XP this is no longer an issue. Windows automatically
collapses documents from the same app so that the management
interface does not get filled up. Also, users usually want to switch
to a *document*, not an *application*, so switching applications is
actually a negative.
* With MDI (and also TDI), a single menu bar and/or toolbar is
shared between
all child windows, reducing clutter and increasing efficient use of
screen
space.
The extent of benefit depends on the application and if windows are
tiled or worked with individually. Most applications have more
efficient screen use and customizable toolbars, so the base clutter
is far less than it used to be. Additionally, unless the windows are
tiled, there is no net gain, since switching from App A window A to
App A Window B will bring forward and use the same screen pixel
locations.
* All child windows for an application can be hidden/shown/
minimized/maximized
as a whole.
Again, questionable if it is an actual "advantage". It is a property/
behavior of MDI, but most studies indicate this is a negative for
most users. People most often think of "documents" and tend to work
"on documents" instead of "in applications".
* Without an MDI frame window, floating toolbars from one
application can
clutter the workspace of other applications, potentially confusing
users with
the jumble of interfaces.
True. But this advantage is also gained by not having floating
toolbars and does not require MDI to gain. SDI also has this
advantage, so it really shouldn't be a factor here.
* Features such as "Tile" and "Cascade" can be implemented for the
child windows.
A decent advantage. However, it is also a disadvantage in that it
means all documents of a given application are tiled, not of a given
set. The work-around in MDI to make this point an advantage is to
only open documents for client A. However, that also then is the same
thing to give SDI the same advantage.
Jon A. Cruz
2007-03-28 19:01:36 UTC
Permalink
A proposal to bring Blender-like splitable views, detachable panels
and tabs
to the WM level is on my too-long todo list.
Splitable views and tabs are mechanisms that will probably solve all
the problems people want MDI used to solve, but in a much better
solution.

In fact, having split views on a single document in a single window
along with having a separate window for each document will probably
be the best solution.

Adding in tabs will be a solution for some people, but personally I
don't use them nearly as much as others.

Having both implemented and allowing the users to use as little or as
much of each as they desire will probably maximize productivity, and
that will be far better than trying to solve those with MDI.
jiho
2007-03-28 20:32:01 UTC
Permalink
Post by Jon A. Cruz
A proposal to bring Blender-like splitable views, detachable
panels and tabs
to the WM level is on my too-long todo list.
Splitable views and tabs are mechanisms that will probably solve
all the problems people want MDI used to solve, but in a much
better solution.
In fact, having split views on a single document in a single window
along with having a separate window for each document will probably
be the best solution.
Adding in tabs will be a solution for some people, but personally I
don't use them nearly as much as others.
Having both implemented and allowing the users to use as little or
as much of each as they desire will probably maximize productivity,
and that will be far better than trying to solve those with MDI.
Having both tabs and several windows (with as few floating palettes
as possible ;-) ) would indeed be the best solution IMHO. A currently
working example is browsers: I think everybody can now see the
benefit of tabbed browsing (opening the results from a search in the
same window, having related websites opened in the same window,
opening a whole folder of bookmarks in one window etc.). However it
is also useful to open a new window when one want to change focus/
subject, kind of opening a new browsing "session". This is
particularly useful on desktop systems which handle several virtual
desktops: one can have a desktop with one browser window containing
several search results for python tutorials and a text editor window,
and a another desktop with a new browser window displaying an online
drawing tutorial and an Inkscape window (with several tabbed
documents to host all the examples in the tutorial maybe!).

I can't wait to see all these docked/tabbed things implemented! Cheers,

JiHO
---
http://jo.irisson.free.fr/
Gail Banaszkiewicz
2007-03-28 20:39:07 UTC
Permalink
Post by jiho
Having both tabs and several windows (with as few floating palettes
as possible ;-) ) would indeed be the best solution IMHO.
I can't wait to see all these docked/tabbed things implemented
I wholeheartedly agree with this. I have studied user and task analysis and, to an extent, usability in school, and take special interest in the topic. Somehow, the whole MDI issue never seemed to come up :) The MDI-ness of CorelDRAW works for me, but I have to agree that something as described below would be really nice to have.

I have to say I've enjoyed learning from all of you as I read through the discussions on the topic, so thanks for that!
Thorsten Wilms
2007-03-26 19:08:05 UTC
Permalink
Post by bulia byak
By the way, one way to resolve this issue would be to go even further
in UI redesign and abandon separate windows altogether, instead adding
tabs to the main interface for open documents. I personally would
welcome this, although I'm afraid there are many who are used to the
current behavior (e.g. for viewing documents or views of the same
document side by side).
With GIMP and Inkscape, I like to put dialogs on the side of the screen
and allow them to fall back behind the document window. As I use focus
follows mouse and auto-raise without delay, I can bring any dialog to
the front with a flick of the mouse and the document back up as easily.
This is especially useful with GIMP and large images.

Of course, this is all far away from the defaults, so few people can be
expected to do the same. However, there's the related idea of having
auto-expanding/collapsing side panels.

Floating dialogs that stay on top are only good for obstructing the
view and getting in the way.

I wouldn't mind document tabs, but there needs to be a way to have
documents side by side for comparison. Vertically or Horizontally
split views, please :)
--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
Gustav Broberg
2007-03-26 19:40:18 UTC
Permalink
On Mon, 26 Mar 2007 14:07:49 -0400
Post by bulia byak
Post by Gustav Broberg
The patch adds a dockable pane to the desktop on which any
GTKmm:ified dialog can be docked. Here are some screenshots showing
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
This is an extremely desirable change. It turns Inkscape from a clunky
and messy Gimp lookalike into a clean, modern-looking application. I'm
all for it.
However, I foresee one problem. Currently all of our dialogs are built
around the "one dialog serves all open windows" concept. Making them
dock to the editing window seems to switch them to the "each window
has its own dialog" paradigm. This therefore may not be as
straightforward, because in each dialog we will also need to find and
fix code which (1) assumes there's always only one copy of the dialog
and (2) switches its state and display when a new window gets focus,
and (3) applies the changes in dialog to the currently active window.
Gustav, have you looked into these problems at all? I suspect the
severity of the required changes varies from dialog to dialog, but at
least for Fill&Stroke it's going to be rather major (although it
hasn't even been ported to GTKmm and Dialog class yet, as are many
other dialogs).
No, I haven't, so you're right that it's still a problem to solve.

Skipping support for the current floating style dialogs would make this
easier to solve but then gdl would be a requirement. There would still
be the problem with gdl's floating dialogs, as Bryce mentioned, though.
However, I'm not sure that I think it's necessary to keep the singleton
behavior for them...

I like the single desktop approach with multiple (tabbed) documents that
you suggest. With gdl it wouldn't be a problem to allow documents to be
arranged side by side in a split view, or as tabs in a notebook.

On the other hand I guess that some people just like their windows to be
managed by their window manager :)

--
Gustav
bulia byak
2007-03-30 18:33:31 UTC
Permalink
Post by Gustav Broberg
No, I haven't, so you're right that it's still a problem to solve.
Skipping support for the current floating style dialogs would make this
easier to solve but then gdl would be a requirement. There would still
be the problem with gdl's floating dialogs, as Bryce mentioned, though.
Personally I would not object to removing the floating dialogs. But I
know other people would object (those with multiple monitors, etc).
Post by Gustav Broberg
However, I'm not sure that I think it's necessary to keep the singleton
behavior for them...
A freely floatable dialog not being a singleton? I don't see how it's
possible without a terrible confusion.
Post by Gustav Broberg
I like the single desktop approach with multiple (tabbed) documents that
you suggest. With gdl it wouldn't be a problem to allow documents to be
arranged side by side in a split view, or as tabs in a notebook.
Ideally, yes. I would love to have that as the only mode of operation.
But I don't know if we'll ever achieve that, given how entrenched is
the current layout.
Post by Gustav Broberg
On the other hand I guess that some people just like their windows to be
managed by their window manager :)
Not everyone has a window manager worth speaking about :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
MenTaLguY
2007-03-30 22:36:09 UTC
Permalink
Post by bulia byak
Post by Gustav Broberg
I like the single desktop approach with multiple (tabbed) documents that
you suggest. With gdl it wouldn't be a problem to allow documents to be
arranged side by side in a split view, or as tabs in a notebook.
Ideally, yes. I would love to have that as the only mode of operation.
But I don't know if we'll ever achieve that, given how entrenched is
the current layout.
Have you had occasion to use Eclipse, by the way? If one was going to do that sort of thing, it gets it about as right as I've ever seen it.

-mental
Bryce Harrington
2007-03-26 18:15:34 UTC
Permalink
Post by Gustav Broberg
I have uploaded a patch to the tracker which is a first attempt to
implement dockable dialogs/panels using gdl (Gnome development
library).
The patch adds a dockable pane to the desktop on which any GTKmm:ified
dialog can be docked. Here are some screenshots showing what it's all
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
Very cool, this definitely looks like something we want.
Post by Gustav Broberg
To compile you'll need gdl >= 0.6.1, the latest version is available
here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2
Gdl is a fairly small UI library developed for IDE:s such as
Anjuta. The main thing it provides is a set of components to build
dockable interfaces.
I realize that it would be better to do this without an additional
library, but right now I think gdl is the best option assuming that we
want a dockable interface.
If it works as a reasonably standalone library, with dependencies only
on libraries we already depend on (gtkmm, glib, etc.) then this is
probably a good choice. If it depends on libraries we don't already
have in the codebase, then that could be a problem, as it increases our
"weight" on windows, non-GNOME platforms, and so on.

This could be made optional in autoconf, as we do with inkboard, etc.
However, this feature is something that probably should be implemented
in a way that allows us to use it universally.

Can you please investigate the dependent libraries, and especially look
for ways to "trim" the dependencies down? The nautilus dependency is
especially worrisome.
Thanks, this is a good analysis.

Bryce
Gustav Broberg
2007-04-04 20:28:48 UTC
Permalink
[...]
Post by Bryce Harrington
Post by Gustav Broberg
I realize that it would be better to do this without an additional
library, but right now I think gdl is the best option assuming that
we want a dockable
interface.
If it works as a reasonably standalone library, with dependencies only
on libraries we already depend on (gtkmm, glib, etc.) then this is
probably a good choice. If it depends on libraries we don't already
have in the codebase, then that could be a problem, as it increases
our "weight" on windows, non-GNOME platforms, and so on.
This could be made optional in autoconf, as we do with inkboard, etc.
However, this feature is something that probably should be implemented
in a way that allows us to use it universally.
Can you please investigate the dependent libraries, and especially
look for ways to "trim" the dependencies down? The nautilus
dependency is especially worrisome.
Compiling gdl with --disable-gnome will require you to have libglade2,
libxml2 (and gtk, obviously :). Stripping away its gdl-dock-layout
part, which is used for serializing/parsing dock layouts to/from XML,
will leave us with gtk as the only dependency.

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.

Other than that, the patch is pretty much the same. On the other hand
some substantial changes have been made to gdl lately, which is nice
to see.

The patch is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1688508&group_id=93438&atid=604308

Then I have a question about compiler warnings. Compiling gdl with our
gcc flags gives a lot of warnings about unused parameters (they are
unused params in callback functions, so the warnings don't really
apply here). Is there an easy way to suppress them just for this
directory using the current build system? There's a trick mentioned in
configure.ac:684 that suggest that removing the parameter name would
fix this, but I'm getting an "error: parameter name omitted" when
trying it? Is it perhaps valid C++, but invalid C?

--
Gustav
Jon A. Cruz
2007-04-04 20:35:01 UTC
Permalink
Post by Gustav Broberg
Then I have a question about compiler warnings. Compiling gdl with our
gcc flags gives a lot of warnings about unused parameters (they are
unused params in callback functions, so the warnings don't really
apply here). Is there an easy way to suppress them just for this
directory using the current build system? There's a trick mentioned in
configure.ac:684 that suggest that removing the parameter name would
fix this, but I'm getting an "error: parameter name omitted" when
trying it? Is it perhaps valid C++, but invalid C?
I believe that the portable and C / C++ way to do it is to just
reference the parameter

void foo ( int bar )
{
(void)bar;
...

}
MenTaLguY
2007-04-04 21:18:29 UTC
Permalink
Post by Jon A. Cruz
Post by Gustav Broberg
There's a trick mentioned in
configure.ac:684 that suggest that removing the parameter name would
fix this, but I'm getting an "error: parameter name omitted" when
trying it? Is it perhaps valid C++, but invalid C?
void foo ( int bar )
{
(void)bar;
...
}
As this is somewhat ugly, I would still recommend omitting the parameter name when you have the luxury of working in C++.

-mental
bulia byak
2007-04-05 05:08:45 UTC
Permalink
Post by Gustav Broberg
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!

- 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.

- 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?

- 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

- 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.

- Can we make it remember what was in the side dock and restore that
configuration upon the next launch?

- 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.

- 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.

- 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).

- 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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Gustav Broberg
2007-04-23 21:21:10 UTC
Permalink
On Thu, 5 Apr 2007 02:08:45 -0300
Post by bulia byak
Post by Gustav Broberg
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.
- Overall, it works and is already usable!
Thanks for the review! I've uploaded an updated patch that address some
of the issues.
Post by bulia byak
- 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).
Post by bulia byak
- 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.
Post by bulia byak
- 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.
Post by bulia byak
- 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...
Post by bulia byak
- 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.
Post by bulia byak
- 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.
Post by bulia byak
- 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.
Post by bulia byak
- 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.
Post by bulia byak
- 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
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

J***@ewi.utwente.nl
2007-03-26 18:26:28 UTC
Permalink
Post by Gustav Broberg
Post by Gustav Broberg
The patch adds a dockable pane to the desktop on which any
GTKmm:ified
Post by Gustav Broberg
dialog can be docked. Here are some screenshots showing
what it's all
Post by Gustav Broberg
http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png
http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png
This is an extremely desirable change. It turns Inkscape from
a clunky and messy Gimp lookalike into a clean,
modern-looking application. I'm all for it.
Loving it!
Post by Gustav Broberg
(although it hasn't even been ported to GTKmm and
Dialog class yet, as are many other dialogs).
As this is already an ongoing effort, this should not hold it back.
Maybe we should bump this effort on the prio list?

Regards,
Johan
Continue reading on narkive:
Loading...