We should go for a single-window mode in 2.8

[Guillermo Espertino]

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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

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





_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexia Death-2]

On Thu, Oct 1, 2009 at 3:17 AM, peter sikking <peter@...> 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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Alexia Death wrote:

> On Thu, Oct 1, 2009 at 3:17 AM, peter sikking <peter@...>  
> 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



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Guillermo Espertino]

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.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Guillermo Espertino]

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.


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer