Cole wrote:

I think the term single-window mode is potentially confusing. It's how you dock the windows together that gives the user the *perceived* single-window or multiple-window mode.

well, if I have to formulate it, then single-window is users' preference for a flat working surface, where nothing overlaps. Multi-window is a staggered environment.

one thing is bugging/intriguing me and that is the (single) point where single-and multi-window 'lines cross'. That is when one image is open and for single window toolbox and inspector column(s) have been torn off.

Forgetting the parade for a moment, single-and multi-window look the same in that situation. It is tempting to think that from there users can 'just go in four directions,' by opening a tab, a new window, docking toolbox or inspector column(s). that is just 3 directions, because
exactly docking on a multi-window environment is not a viable route afaics, docking global stuff to image instances.

But I said "forgetting the parade for a moment" because that exactly points at the kind of UI optimisation that can be done if it is known whether a flat or staggered environment is the goal. I'll also be damned to double a number of menu items because the result could be a new window or a new tab. this now works automatic according to the single-window mode setting.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Mon, Sep 28, 2009 at 5:56 PM, Cole wrote:

If implemented correctly the user that prefers a multiple-window mode gimp wouldn’t
see much difference from the existing gimp version to a gimp version that supported a
single-window mode.

Only if I can dock non-GIMP windows there.

Jakub Friedl

On Mon, Sep 28, 2009 at 11:56 AM, Cole wrote:

/ For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking

/>>/ about: URL.
/>

Eeek, here is the missing URL:
http://curlyankles.sourceforge.net/widgets_docking.html

Alexandre

Hello,

I think the term single-window mode is potentially confusing. It's how you dock the windows together that gives the user the *perceived* single-window or multiple-window mode.

I'm still thinking GIMP could benefit from Eclipse-style "perspectives", where which dialogs are visible and which are hidden are user-defined sets that can be switched between. The user can then define which dialogs are useful for certain commonly occurring tasks and quickly switch between them. It takes a little getting used to at first, but once you understand the paradigm you never want to go back to managing individual windows.

Rockwalrus

On Sep 29, 2009, at 9:40 AM, Nathan Summers wrote:

I'm still thinking GIMP could benefit from Eclipse-style "perspectives", where which dialogs are visible and which are hidden are user-defined sets that can be switched between. The user can then define which dialogs are useful for certain commonly occurring tasks and quickly switch between them. It takes a little getting used to at first, but once you understand the paradigm you never want to go back to managing individual windows.

In my personal preference, Eclipse's "perspectives" are an interesting idea but one that is implemented somewhat poorly. Even after using it for years I still find it a very clumsy and inefficient implementation.

A recent example of some of my bad experience was when I was coding and debugging some Java while working on both BIRT and Crystal reports. That's four different "perspectives" I had to try to work in. The UI gave poor switching and tracking of the current "mode", and there were even technical problems where they fought over keys and killed shortcuts in each other. Quite painful.

Peter:
What do you think about the method for splitting/joining views in Blender 2.5?
It's fast, it kinda covers the idea of the image parade and it allows to float a section as a new window.
The only thing needed would be something to mark which is the active image and that would be enough for most of the described cases.

I prepared a brief screencast showing how it works. http://dl.getdropbox.com/u/255376/Blender-UI.avi

I think that some interesting concepts can be picked up from this kind of non-blocking UI.

Gez

Guillermo,

What do you think about the method for splitting/joining views in Blender 2.5?
It's fast, it kinda covers the idea of the image parade and it allows to
float a section as a new window.
The only thing needed would be something to mark which is the active image and that would be enough for most of the described cases.

I prepared a brief screencast showing how it works. http://dl.getdropbox.com/u/255376/Blender-UI.avi

thanks for that, I watched it a dozen times, even in slow-motion.

first I noticed this set-up has no rulers or scrollbars. we have and I am avoiding the replication of the all over the screen.

you can see here sort of the same problem that that control bar below the canvas is repeated for each of them. that sort of hides that they have to repeat that clever divider/split handle for each pane (OK, we could only show it for the current active pane, but that is slower)

another thing I see here is filling the new tile immediately with the same thing as the parent one. I thought I wanted to do that too, but then realised that in GIMP an empty tile would be automatically a drag-n-drop target to open an image, from the parade, file browser, etc.

being empty does give a requirement where the new tile has to appear: for l-to-r locales it has to be on the right, so it would have to be 'pulled in' from the right. which would put that clever split handle in the corner where resize corners are found: bottom-right. ouch.

float a tile as a new window: could be for multi-win (but how to not introduce visual clutter for this), not for single win.

then there is a the arbitrary splitting. I have a funny feeling about that.
has to do with how arbitrary the result is. and how, and how fast, do I build 9 (halfway) equally sized tiles to start filling with images? I know a fast way for that (View->Tile->9-square) but that is incompatible with arbitrary splitting.

and how does blender define the current canvas one is working on? I would expect the load of inspectors on the right and bottom of the screen to track the current canvas.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Thu, Oct 1, 2009 at 3:17 AM, peter sikking wrote:

another thing I see here is filling the new tile immediately with the same thing as the parent one. I thought I wanted to do that too, but then realised that in GIMP an empty tile would be automatically a drag-n-drop target to open an image, from the parade, file browser, etc.

Auto filling fits with blender UI concept but not with gimp-s. Its important to remember that in blender you can only have ONE project file open at any given time and all these tiles display different aspects of that same project. Not so in gimp.

then there is a the arbitrary splitting. I have a funny feeling about that. has to do with how arbitrary the result is. and how, and how fast, do I build 9 (halfway) equally sized tiles to start filling with images? I know a fast way for that (View->Tile->9-square) but that is incompatible with arbitrary splitting.

How a bout using a modifier to span the split. Basically, when you start the split you can control the position by dragging and only the current pane, the one that you started to split is split, but if during split, before commiting by releasing the mouse button shift is pressed, the split is made to span the whole screen. This will mean that 9-square split will take total of 4 splits, two of those modified.

and how does blender define the current canvas one is working on? I would expect the load of inspectors on the right and bottom of the screen to track the current canvas.

Actually, the current one is the one that has your mouse cursor and that's the only bit of info you need. It works surprisingly well for blender and its specifics, but I think it would be quite had to make it work for gimp because in a piece of pixel art, I want my mouse off canvas unless I'm actually using it.

Alexia Death wrote:

On Thu, Oct 1, 2009 at 3:17 AM, peter sikking wrote:

another thing I see here is filling the new tile immediately with the same thing as the parent one.

Auto filling fits with blender UI concept but not with gimp-s. Its important to remember that in blender you can only have ONE project file open at any given time and all these tiles display different aspects of that same project. Not so in gimp.

that is what I suspected about blender. and right: "not so in gimp."

then there is a the arbitrary splitting. I have a funny feeling about that.

How a bout using a modifier to span the split.

you know, the quest here is really is speed-of-set-up. It has got to be so easy to knock these splits up from scratch that only a minority of users will have a urge to ask for saving these configurations (they will eventually, and one day we will, eventually).

so thanks to the challenge and discussion in Guillermo’s email and this one I am also getting there on the flexibility front. I now have a system where in 4 (four) user actions a 12-way split (3 rows, 4 columns) can be set up with the size of the main image and of the 11 other ones set ‘just right.’ and then there is the flexibility that when each of these 12 tiles/images is the current image, there can be a different sizing of the main image and the 11 other ones.

and I am working on keeping the clutter further down.

and how does blender define the current canvas one is working on?

Actually, the current one is the one that has your mouse cursor and that's the only bit of info you need.

ah, right, cursor. I already realised that when someone wrote here or in a comment on my blog ‘to do it like xyz code editor’ that these apps have a cursor. which defines the focus. we do not have always a cursor. or we have multiple (highlighted paths). or it is in the other image (cloning). again: "not so in gimp."

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Peter: Thanks for your reply. You exposed some issues that I didn't took in consideration.
Of course I'm not saying that Blender's UI can be ported as-is to GIMP. However I found some of those ideas pretty interesting for our case.

first I noticed this set-up has no rulers or scrollbars. we have and I am avoiding the replication of the all over the screen.

The buttons window has scrollbars that appear if they're needed. Blender doesn't use scrollbars in the design area itself since it's easy to scroll and pane the view. GIMP is pretty much the same. Honestly, having middle click + drag to pane and CTRL + wheel to scroll makes those scrollbars old :-)

you can see here sort of the same problem that that control bar below the canvas is repeated for each of them. that sort of hides that they have to repeat that clever divider/split handle for each pane (OK, we could only show it for the current active pane, but that is slower)

I think that it boils down to having an effective way to highlight the working image. I think that working with more than one image at the same time is not a real use case. You'll always be working on a single image since you have just one mouse pointer. Finding a good strategy to switch between the active images would solve most of the problems (maybe just a click on an inactive window and a colored border like this? http://www.mmiworks.net/pics/blog8/lgmbigparadeL.jpg). The file menu would be just one, the rulers should appear in just one window at a time and we even may get rid of the scrollbars :-)

another thing I see here is filling the new tile immediately with the same thing as the parent one. I thought I wanted to do that too, but then realised that in GIMP an empty tile would be automatically a drag-n-drop target to open an image, from the parade, file browser, etc.

In blender you work with a single project and open separated resources. Of course it isn't the same in GIMP. I think that again the "active" image window should define the title displayed.

being empty does give a requirement where the new tile has to appear: for l-to-r locales it has to be on the right, so it would have to be 'pulled in' from the right. which would put that clever split handle in the corner where resize corners are found: bottom-right. ouch.

I din't consider rtl locales at all, good point. Anyway, the resize handlers of the view in blender ar performed by dragging the edge of the window, not the corner. The corner icon is only used for splitting, joining or floating the window (with shift+click+drag on the icon)

then there is a the arbitrary splitting. I have a funny feeling about that.
has to do with how arbitrary the result is. and how, and how fast, do I build 9 (halfway) equally sized tiles to start filling with images? I know a fast way for that (View->Tile->9-square) but that is incompatible with arbitrary splitting.

In blender you have a pre defined orthographic 4-view window. I guess you can split the main image in two, leaving an empty area, and via the view menu perform something like: split this window in 9. Then drag and drop images from your OS file browser in each empty window, making always active the last touched.

and how does blender define the current canvas one is working on? I would expect the load of inspectors on the right and bottom of the screen to track the current canvas.

yes, mouse pointer focus. And that's true, it's not usable in GIMP. But I guess that a single click in an inactive window could make it active. It's the same that you currently do to make active another image window when you're working with multiple windows opened.

HTH, Gez.

Just a couple of things:

- The splitting could display another "view" of the same image, just like in blender. That would make working with views a breeze (for icons or pixel art, for instance). It doesn't need to be empty if you dragged it from an existing image window
- About the problem of arranged multiple views, it seems that one would use that amount of images just as reference, or for fast switch. Then, a view could have a "parade" mode that allows you to open a directory or a selection of images in a row. And you can use that row as a fast switcher to open (or drag as a layer in the active image) any of the images. In that case the parade won't be a group of opened images, but rather a thumbnailer.