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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
