GNOME Bugzilla – Bug 121087
Dockable Image Window (Tabbed MDI, not WiW MDI)
Last modified: 2008-11-09 17:56:53 UTC
Well, it has to be ported to GTK2 sometime. Don't waste your time just rewriting. I've attatched a png image of a mock-up I did of an MDI interface. The brush and tool option area can be any of: Brushes/Tool Options Color Selector Gradient Selector Pattern Selector It'd be nice if the thing was adjustable (especially since my screen is so huge, and gimp's bare minimum is 1024x768 . . . ) but it at least has to fit on the bare minimum settings. That mock-up will have to be adjusted I guess.
Created attachment 19621 [details] A mock-up of the UI I would like to see, at 1280x1024
You should update to 1.3.19 and see most of your wishes fulfilled (except what looks MDI like to me). See discussion of bug #7379. *** This bug has been marked as a duplicate of 7379 ***
Oh, sorry. I really should have searched first. And, I'll hit the newest CVS and hack it overtop the install Gentoo has here . . . thanks.
Alright, as suggested in the conversation on Bug #7379, I am re-opening this bug with a better summary. I would like to see an option to dock the image window to the toolbar window, resulting in a "tabbed MDI" structure. I am requesting this only as an option. It seems that the interface is VERY close to this, but programmatically i'm not really sure exactly how close. You would have to prevent new image windows from popping up, and connect the image window to the side of the toolbox window, so that changing the image is done with the Pictures tab. Also, dialogs should simply either create or select their tabs in the toolbox window in this mode.
Please look at MonoDevelop, it has a very nice engine to handel windows. http://www.monodevelop.com/
MonoDevelop is a completely different application. I don't see how the user interface of an integrated development environment relates to the GIMP GUI. Your comment is not really helpful unless you go into more detail.
The interface is quite like Eclipse - you have a main panel with several sub-panels containing utility stuff. You can expand any panel to full window size, and it is not so much WiW as notebooks that arrange themselves more or less on demand. Basically, docks in 1 window. I think it could work for the GIMP, but it'll need someone to code it, and it'd take quite a while, I think. Cheers, Dave.
I fail to see how such an interface could be useful for image manipulation. I agree that it is a reasonable approach to working with texts but image manipulation requires to be able to work with multiple images at the same time.
The need to be able to work with multiple images at the same time was one of the reasons why I suggested to keep the discussion about the Tabbed MDI interface in a separate bug report from bug #7379, which focuses on WiW MDI. Take a look at the comment that I added on 2004-01-09 to bug #7379 for an evaluation of the tabbed model. On the other hand, several users like the tabbed model because it is used by other applications such as Mozilla, Eclipse, MonoDevelop or KDE's regimp. Even if a tabbed interface is less convenient and less efficient for editing images, some users may prefer to use a known user interface model instead of having to become familiar with another one (which would be better, but has its own learning curve). This could be interesting for those who only use the GIMP once per year.
Aren't many of the problems be solved if you do the window-handling just like OpenOffice? So: a) Gimp starts by default with an empty image if the user clicks the program icon. Otherwise, it just opens the clicked image. b) remove the tool-windows from the task/window list, only leave one entry per open image c) bring all tool-windows to the front if an image is activated (either by clicking on it or via the task list), only remember the z-order of the tool windows and the image window I don't know about the internals of GTK or the Gimp, but perhaps it could be done quite easily in this way. -- Wouter
Basically everything you mention here is nothing that an application should be doing. It's the window managers job and there are window managers that do just that.
*** Bug 139585 has been marked as a duplicate of this bug. ***
instead, or also, why not make tabs dockable in the image window? Allowing a flag of "in all images" for a tab would be nice, too, where one could dock a tab in one window and flag it "in all images" and then that tab would appear in all images. This would save me a lot of flipping between windows.
*** Bug 142960 has been marked as a duplicate of this bug. ***
Bug #142960 has this nice mockup: http://bugzilla.gnome.org/attachment.cgi?id=27933&action=view
*** Bug 314027 has been marked as a duplicate of this bug. ***
See bug #314027 for another mockup.
Here is how I feel about tabbed interfaces: * Tabs do not prevent from editing multiple files at a time. (But this is obvious) * What is less obvious is that tabs do not prevent to LOOK at two files at a time either. Why? Because it is impossible to look at two pictures at the same time. Even if two pictures are visible at the same time, you can only look at one of them at a time. Your conscious attention can only focus on one thing at a time. * So, what is the real downside with tabs? The problem is that they make it SLOWER to switch your attention from one picture to another. It is slower because you have two click on a tab, instead of just moving your eyes. But this is only a problem when you FREQUENTLY need to switch your attention from one picture to another (e.g. when you are drawing based on a model). * Therefore we should ask ourselves how often we need to FREQUENTLY switch our attention from one file to another. Because, when we RARELY need to switch our attention, tabs are perfectly usable. For example, when you are editing one picture and using the other only for cut and paste. * Does this mean tabs can be the only idiom in GIMP? No. There are times when you frequently need to switch your attention. Does this mean tabs should be the default idiom? Probably so, because they have advantages. Let us see what these advantages are: * The advantage of tabs is that they spare you from doing window management. In particular, they spare you from dragging and resizing windows, in order to have a wider view on the picture. This dragging and resizing can be unnerving (e.g. in GIMP you need to do that each time you open a picture), especially when the user feels it is useless, i.e. when he has no need to _frequently_ switch his attention between two open files.
There are several usecases for multiple views that cannot be done with Tabs. Off the top of my head: doing stereographic stuff which might require you to do cross-eyed viewing of two images or "spot the difference" tasks. More frequently is probably the usecase of having multiple views on the same image, e.g. creating an icon in a very big zoom level while having a 1:1 view next to it. Another thing is when you have an image of building blocks you use to assemble a second image. So Tabs can definitely not replace multiple top level views.
* Should tabbed layout be the _only_ idiom in GIMP? No. There are times when you frequently need to switch your attention (see comment #19); * should tabbed layout be allowed in GIMP? Yes. There are times when you don't need to frequently switch your attention, and in this case tabs spare you from doing window management (see comment #18) * should tabs be the default layout in GIMP? Who knows. It depends on people's usage of GIMP. Maybe a first time wizard would do.
Switching between two views is a very frequent action in GIMP because it is very common to work with two views on the same image. But anyway, there is no need to convince anyone that tabs in the image window are a good idea. The reason we don't offer that possibility yet is not because we wouldn't like the idea. The reason is just that noone has yet written the code. There have been dozens of proposals and mockups over the last years but never even an attempt at an implementation.
*** Bug 314258 has been marked as a duplicate of this bug. ***
Created attachment 63741 [details] Another mockup with multiple panes This is my idea for a tabbed interface for gimp. It was made in gimp by a non-dev so bear with the looks. The idea is to have multiple panes with their own tabs. The tabs would have drag and drop between panes. If you right click on a tab you would get a menu something like thes: Move tab to new pane. --- Consolidate all tab panes Move all tabs to new panes --- Close current tab Consolidate all tab panes would take all of the tabs in all of the tab panes and move them to one tabbed pane. Move all tabs to new panes would open a new pane for each tab. So you would see all of your images side by side. Panes wouldn't have to be side by side. They could be top to bottom, or some other configuration. Menu items could be added to the effect. It may be possible to drag and drop panes so you could reposition tab panes on top of each other or something else. It may be a good idea to have tool panes in addition to tab panes. That way you could have a tool pane with buttons and tabs along the top. The sky is almost the limit. Another possibility, to save screen space, is to have a vertical tab bar along one or both sides with the ability to hover over a tab and have the tool box come out, like Visual Studio 2005. You might also be able to detach a tool, pane, or image from the main window and have it float above. By this manner you could revert to the current gimp behavior. This would seem to allow almost unlimited flexibility. Just my two (or maybe four) cents. :-)
Why there are no votings for bugs? My opinion that tabs should be merged with window-in-window interface. I.e. if a window is expanded - it is present in tabs. The worst thing is of course the fact that for four years nothing has changed. =(
techtonik, "voting" for this bug or whining that nothing happened in years won't help even a little bit. Get yourself an editor and a compiler and do something about it.
Let me disagree. Votings help to get the real picture of user's need. It can help everybody to see the next thing to be done and elaborate on it. As for me - if you can tell where can I plug my scripting and XML skills to move this issue from the dead point I may help. Otherwise it could take more time than I'll have to get to the entrypoint.
(In reply to comment #26) > Let me disagree. Votings help to get the real picture of user's need. It can > help everybody to see the next thing to be done and elaborate on it. No, voting in Bugzilla doesn't help to get the real picture. Only a small subset of GIMP users visit Bugzilla. In addition, the decisions on "the next thing to be done" are not based on whether many users request it but are instead based on whether experienced users such as graphics professionals are interested in that feature or not. For details about our target group, see the "GIMP Vision" chapter at the end of http://developer.gimp.org/gimpcon/2006/index.html So in the end, voting for bugs is a waste of time; time that would be better spent implementing a solution. This bug and the related bug #7379 are important and the developers are aware of them. They are also among the oldest unresolved GIMP bugs, because solving them is not trivial and nobody has implemented a good solution yet. If you really want to discuss some features rather than implementing them, please do so on the mailing lists (gimp-user or gimp-developer), not in Bugzilla.
I intend to fix this for 2.8, at least making the image window dockable.
This needs to be discussed on the mailing-list before it is set on any milestone. In my opinion this should be closed as WONTFIX.
Setting back on Future.
The "Future" milestone means that we agreed that this should be implemented at some point. But there is no such agreement. If this was set on the Future milestone before, then this happened by accident. Overall I think this bug report should be closed as it is not specific enough and mixes several user interface changes. It would be a lot better to discuss this again and to open new bug reports then.
Sounds reasonable actually, closing as INCOMPLETE.