On Fri, Sep 18, 2009 at 9:26 PM, peter sikking wrote: > hey guys, > > I have now blogged about the single-window mode: > > <http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html> Peter, I'm afraid this is not going to work for a lot of users. Let's start with a mission statement: a user should be able to a) compare several images and b) have editing access to multiple ones. To me your proposal fails here, in both tasks. Let's go into details: Comparison. You solve the comparison task by introducing windows that overlay actual content and duplicate existing views of same images. What needs to be thought about here is that there are two reasons to compare images, and your proposal deals more or less nicely with just one of them: 1. Quick comparison, basic overview of differences between several of images, usually up to four. This is where your proposal sort of works, up to a point where there are too many polaroids around overlaying your current image. Think about poor netbook users with 1024x600px displays. Two polaroids is best what they can allow. 2. Detailed comparison, when you lock view of several similar images and thus get synced navigation. Your proposal sort of deals with this, but what it basically does is creating temporary view windows on top of just one current image. What is wrong with that? The fact that detailed comparison is often coupled with introducing gradual changes to several images. So this is time for the b) part of the mission statement: Editing access to multiple images. Why is it important to have access to several images at once? Consider a situation when you have two versions of a project you've been working on, that is -- two image windows/views. And you need to add elements from a couple of other projects to both of them. It looks like this: 1. You have a source file(s) window(s) and two target projects. 2. You pick, say, a group of layers from it and transfer (let's omit details for now) it to a different image. 3. You do the same for the second target project. 4. In both target project you aply a number of changes (like reordering objects in layer stack, moving dropped objects around, applying some filters, etc.) 5. You overview changes in both target project and decide whether you need something else from the source project(s). 6. If you do, you repeat steps 2-5. What is the fastest way to drag'n'drop stuff (paths, layers, selections etc.) from one window to another? By having image windows side by side. Why is the presumably optional (C)SDI not right for the task? 1. Because you don't always need that, so switching between (C)SDI and MDI modes is tedious. 2. Because you don't always need that for *all* opened images, so when you have five images opened and you need to see just two or three of them at the same time, by switching to (C)SDI you end up with several more images floating around that you don't really need right now. 3. Because in the upcoming new GUI using (C)SDI based UI means having varios dialogs floating around, so you will have to manually resize image windows to see both of them, which is, again, tedious. You could say "Hey, then let's just drag'n'drop stuff to polaroids!". But then you will still not have the editing functions available. So why introducing polaroids that overlay actual content and do not allow to edit content they display? If not polaroids, then what could be done instead? Custom tiling of images. The space inside working area should become a container that can have both groups of tabs and tiles. You can drag an inactive image using by its tab caption to either of the side of the currently visible image, and they two will share tiled part of the container. Then you can add another one. Each tile would have a sort of draggable caption to help you distinguish one tile from another, so if you don't need that image window anymore you just pick it and drag back to the group of tabs, and the container would refit the rest of the tiles. Why is it better than the proposed solution? 1. Solves the need to view as many images as you need without adding overlay clutter. 2. Solves the need to have a fast editing access to multiple images. 3. It's flexible - it's up to users how exactly they organize images in their working environment. There is a number of things to be thought here like exact method of focusing between tiles (sloppy focus won't work, I guess), especially re. drag'n'drop, but pretty please think about tiling. For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking about: URL. Not that I'm suggesting to reuse it, but at least it demonstrates the kind of flexibility I mean. However I agree that the proposed polariod widget would help with viewing same image in different zoom. Now, as for the "filmstrip", it's quite okay, but I'd mention just one thing here. It really would make sense to display basic metadata there, e.g. title of an image. Because when all you see is a (even large) preview of a 14 Mpx multilayered image and a very similar one next to it, you can't alwyas say which one you need exactly. Especially when it wasn't you who created the images and thus naming of files isn't obvious to you. Whereas metadata can have that information for you. P.S. I do know that it's much easier to be a smartass (like me) than a UI architect (like you) :) Alexandre _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
