On 3/26/07, Alexandre Prokoudine wrote:

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

Forget this part of email, please :)

Alexandre

On 3/26/07, bulia byak <buliabyak@...400...> wrote:

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

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. --- Bryce Harrington schrieb:

On Mon, Mar 26, 2007 at 02:25:29PM -0400, bulia byak wrote:

...

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=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Mar 26, 2007, at 11:34 AM, Gail Banaszkiewicz wrote:

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

On Mar 26, 2007, at 1:58 PM, Gail Banaszkiewicz wrote:

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.

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.

On Mon, 26 Mar 2007, Gail Banaszkiewicz wrote:

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

On Mar 26, 2007, at 5:02 PM, Bryce Harrington wrote:

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

On Tue, Mar 27, 2007 at 03:17:38AM +0100, Alan Horkan wrote:

On Mon, 26 Mar 2007, Jon A. Cruz wrote:

...

On Mar 26, 2007, at 5:02 PM, Bryce Harrington wrote:

...

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

...

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

...

...

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

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

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

On Tue, 27 Mar 2007 11:07:40 -0400, Pierre-Luc Auclair <p.lucauclair@...1585...> wrote:

...

...

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

On Mar 27, 2007, at 11:27 AM, Alan Horkan wrote:

...

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.

On Tue, 27 Mar 2007, Bryce Harrington wrote:

On Tue, Mar 27, 2007 at 07:27:25PM +0100, Alan Horkan wrote:

...

On Mon, 26 Mar 2007, Bryce Harrington wrote:

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.

...

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.

...

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.

...

...

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

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

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.

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

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.

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.

However all of this is just one speculation, until someone codes. Point

Alexandre Prokoudine wrote:

On 3/26/07, bulia byak wrote:

...

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

From MAILER-DAEMON Mon Mar 26 12:08:26 2007

Date: Mon, 26 Mar 2007 21:08:05 +0200 From: Thorsten Wilms <t_w_@...123...> To: inkscape-devel@lists.sourceforge.net Message-ID: <20070326190805.GD4614@...1413...> References: <20070326192049.2eafc8a2@...1567...> <3c78ff030703261107w647bc7bidd44969a733141f@...401...> <3c78ff030703261125s7a78c61as8231da2efa2faf17@...401...> MIME-Version: 1.0 In-Reply-To: <3c78ff030703261125s7a78c61as8231da2efa2faf17@...401...> Priority: normal X-Mailer: Mutt User-Agent: Mutt/1.5.13 (2006-08-11) X-Warning: 80.138.124.242 is listed at list.dsbl.org X-Warning: 80.138.124.242 is listed at dnsbl.njabl.org as open proxy server X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.5 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy [80.138.124.242 listed in combined.njabl.org] Subject: Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns... X-BeenThere: inkscape-devel@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: t_w_@...123... List-Id: <inkscape-devel.lists.sourceforge.net> List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel List-Post: mailto:inkscape-devel@lists.sourceforge.net List-Help: mailto:inkscape-devel-request@lists.sourceforge.net?subject=help List-Subscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe X-List-Received-Date: Mon, 26 Mar 2007 19:08:26 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline

On Mon, Mar 26, 2007 at 02:25:29PM -0400, bulia byak wrote:

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

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.

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

Have to agree. Many entire Inkscape instances is downright confusing.

/d

On Mar 28, 2007, at 11:14 AM, momo wrote:

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"

On Mon, 26 Mar 2007 14:07:49 -0400 "bulia byak" <buliabyak@...400...> wrote:

On 3/26/07, Gustav Broberg <broberg@...370...> wrote:

...

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

On Fri, 30 Mar 2007 14:33:31 -0400, "bulia byak" <buliabyak@...400...> wrote:

...

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

On Mon, Mar 26, 2007 at 11:15:34AM -0700, Bryce Harrington wrote:

On Mon, Mar 26, 2007 at 07:20:49PM +0200, Gustav Broberg wrote:

[...]

...

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

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

On Wed, 4 Apr 2007 13:35:01 -0700, "Jon A. Cruz" <jon@...18...> wrote:

...

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?

Yes, it's valid in C++ but not (strict) C. The portable C solution is what Jon gives below:

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

On Thu, 5 Apr 2007 02:08:45 -0300 "bulia byak" <buliabyak@...400...> wrote:

On 4/4/07, Gustav Broberg <broberg@...370...> wrote:

...

So that's a good thing. I've uploaded a new patch which includes the stripped down gdl (svn head version) merged with the Inkscape tree. Linking gdl statically increases the 'inkscape' binary size with about 800 kB (total size is 51 MB) on my system.

Thanks! I just tried the new patch. First impressions:

• Overall, it works and is already usable!

Thanks for the review! I've uploaded an updated patch that address some of the issues.

• However, many dialogs require serious re-layout of many dialogs to

make them more vertical. For example, Align and Layers already fit nicely. Transform, less so. Trace bitmap looks ugly when in the dock - way too wide.

Yeah, I agree. I think Document Properties is a good candidate as well (it can be useful to have it in the dock in some situations).

• Can we assign default docked/undocked modes for specific dialogs?

For example Preferences, apart from being way too wide for the side dock, simply does not make much sense in the dock. It's not really interactive, i.e. you don't need to look at the canvas when you're working in it. Can we set it to be in its own floating dock by default?

Fixed. A state attribute per dialog is stored in preferences.xml (1=floating, 2=docked). The Inkscape and Document Preferences dialogs are in a floating state per default, the rest are docked. The state is saved back to the preferences file on change.

• Bug: when I place Preferences to the side dock but then delete it, I

can't squeeze the empty dock back - it still takes almost half of screen width

Fixed.

• Can we have some more prominent titles of panels stacked in the side

dock? Right now it's not easy to find where one panel ends and another begins.

Any ideas on how to make this clearer? I tried making the titles bold, but I didn't like the way it looked. I added the dialog icon next to the title in the latest patch, I think it made it slightly better, but not good enough...

• Can we make it remember what was in the side dock and restore that

configuration upon the next launch?

Yes, it would be nice. Too bad I had to strip away the layout manager part of GDL which would make it easy to serialize/build up the dock to/from xml. Just storing _what_ dialogs that are in the dock is easy -- storing their arrangement, position and state is a bit more complicated.

• Bug: floating docks show up in KDE's Alt-Tab list (floating dialogs

don't). Looks like GDL does not set the correct flags on the dock windows.

Fixed.

• Bug: defocusing fails. Clicking a button on a toolbar sends focus

back to the canvas so that keyboard shortcuts work. This fails with side-docked dialogs - they steal focus mercilessly.

Fixed.

• Why can't I squeeze the nonempty side dock all the way off, so it is

not visible at all? I think there should be an easy way to minimize it

• it's cumbersome to have to close all panels in it before you can

make it go away (and even then you can't do it, see bug above).

Show/Hide dialogs (F12) hides the dock, but I guess an extra shortcut for hiding just the dock (and not any floating dialogs) would make sense. And perhaps a button on the dock itself to collapse it.

• And of course, if we go with this patch, we'll need to convert the

rest of gtk dialogs to using Panel too. I think this can be done relatively easily - no need to gtkmmify all their widgets at once: just take the top-level widget, Glib::wrap it and place into a gtkmm container. Should work for the time being.

Ok, I'll take a look see if this is as easy as it sounds :)

I'm still not sure on how to solve the problems that arises when multiple document windows are open. The one-dialog-for-all-windows design doesn't really work when dialogs both can be docked and floating. What would happen to a dialog that is docked in one window when you open a new window? Letting it control both windows would be strange as it's attached to only one of them...

You could allow the user to have multiple instances of dialogs as long as they're docked in their parent window, but prevent the user from having two floating ones. I think this would be equally strange as the user suddenly wouldn't be able to drag dialogs from the dock (into a floating state) which one normally can.

Another way to solve it would be to make the whole dock a singleton that moves with the document that currently has the focus. But on the other hand I think it would be good to allow the user to have different dock layouts for each open window.

Inkscape's current dialog management is also a bit different. There's one DialogManager per document, the dialogs that have singleton behavior implement it "themselves". E.g. Transform and AlignDistribute are non-singleton, while e.g. Layers and UndoHistory make sure that they're only instantiated once.

It pretty much boils down to what the desired dialog behavior is...

Another remaining problem is what to do when docked dialogs go of screen (i.e. the dock becomes taller than its parent window). You could automatically force them on top of each other in a notebook, or perhaps iconify them to the dock-bar on the right. I removed the scroll pane I had before as it created more problems than it solved.

-- Gustav