Although the GDI model ("all in a window") is not the True X Way
and would be hard to implement because the application would have
to re-implement some WM functions in order to manage the child
windows, this feature has been suggested many times.

I am leaving this bug open as "enhancement", but low priority.

Re-assigning all Gimp bugs to default component owner (Gimp bugs list)

Reassigned to current CVS because it's a wishlist item.

See also bug #52305.

I have thought a bit more about the MDI interface and I have changed
my mind since last year.  Now I think that an MDI interface would be
very useful.  That would solve some serious usability problems for
those who do not have the opportunity to use a good window manager
(especially on non-X11 platforms) or who do not want to (or are not
able to) reconfigure their window manager in order to be able to use
the GIMP.  In addition, an MDI interface would provide a much better
transition path for those who have some experience with other
programs such as Photoshop.  Moving from another program to the GIMP
requires some re-training because of the unusual user interface used
by the GIMP.

These problems could be solved with an option for using the MDI model
in the GIMP.  This means using a Window-in-Window interface (or more
precisely Widget-in-Widget) with a menu bar on top of a "workspace
window" containing all MDI child windows (widgets).  This is
different from the MDI model in GnomeMDI, which is a modal notebook
style (tabbed windows).  For more information about the GnomeMDI
model, see:
  http://developer.gnome.org/projects/gup/hig/1.0/windows.html
  http://developer.gnome.org/doc/API/libgnomeui/gnomemdi.html

During the past two years, there has been some discussion on several
GNOME and GTK+ mailing lists about adding the widget-in-widget model
as part of GTK+ or in some GNOME libraries.  This has been rejected
several times because of the limited usefulness of the WiW MDI model
and the risks of mis-using it.  However, this model is suitable for
the GIMP because it has to manage a potentially large number of image
windows that are not suited for inclusion in a tabbed notebook (as in
GnomeMDI).  So I think that it would be useful to implement this
feature in the GIMP or Film Gimp, and maybe move it later to GTK+ if
this makes sense (so that other applications can benefit from it).

The implementation would require at least two new container widgets:
- GimpMDIWorkspace
- GimpMDIChild
Both of them would be derived from GtkContainer.  The first one
defines the workspace that will contain all "pseudo-windows".  The
second one is a container for what would otherwise be top-level
windows, such as all image windows or the various GIMP docks.  It
would draw a minimal decoration around the "pseudo-windows" so that
they can be moved or resized easily.

If the user selects the MDI model, the GIMP would use a GimpMDIChild
as a parent for any image window, instead of using a top-level
GtkWindow.  It may even be possible to switch between the SDI (or
CSDI) and MDI models while the application is running because the GTK
widgets can be reparented.

Additional notes:
- It should be possible to move the GIMP docks in and out of the main
  workspace so that they become MDI children or top-level windows.
- The GimpMDIWorkspace will be included in a GtkVBox containing the
  menu bar on top and the status bar at the bottom.  These elements
  are not part of the GimpMDIWorkspace.
- The decorations around the MDI child "pseudo-windows" should be as
  simple as possible.  I do not think that we should try to support
  WM themes or things like that.
- I am not sure about what should happen when the workspace is resized
  or when an image window would be larger than the workspace.  Maybe
  the workspace should be contained in a viewport with scrollbars?  It
  is probably better to limit the size of all MDI children so that it
  is not necessary to use scrollbars for the workspace.
- It will be necessary to write several wrapper functions for anything
  that is currently dealing with top-level windows, such as resizing
  them, setting WM hints, etc.  If the target is a GimpMDIChild, then
  these calls will have to be translated appropriately.
- At any time, there is one MDI child that is "active": the menu bar
  and the status bar will be linked to it.  This is similar to the X11
  top-level windows getting focus.
- Most users of the MDI model will probably prefer the "click to
  focus" style.  But it may be interesting to implement an option to
  use the "enter to focus" style.

Well...  This comment is a bit long and may not be very well
structured, but this is a kind of "brain dump" of what I had in mind
for the MDI model.  There are still many open issues, but hopefully
this can be useful as a starting point.

Sorry, but i'm all against this "window in window" madness
which is impossible to get right, useable and consistent
with the way GTK+ works.

GTK+ is simply not the window manager and the window manager
is not the toolkit.

Even under Windows, where it is possible to draw the "inner"
windows in the same style as the toplevel one it is totally
unusable, and in fact, even M$ is abandoning this "feature".

I do not talk about a menu bar in all image windows. That's
a different issue and easy to hack. (I'm almost tempted
to hack it as a preference option just to get rid of all the
requests :-)

An MDI should, if at all, be done with tabs as in many other
GNOME/GTK+ programs, because this is something we can control
and is clearly different from the way windows are managed.

We simply *cannot* mimic window managing becuause we are not
the window manager. Any try to do so is IMHO doomed to fail
and will confuse users very much because of the difference
between "inner" and "outer" window handling which will be
different on all platforms. (I mean the difference will be
different which is the worst thing to happen in GUI design).

I understand that you are against this feature.  Being a UNIX/X11
bigot myself and believing in the strict separation between
applications and window manager, I was also against it at first.  But
then several documents about user interface design and some
comparisons with other GUIs made me think differently.  The
window-in-window MDI model can be useful in a few cases if it is used
correctly.  And I think that the GIMP is one of these cases.

There are basically 4 choices for the interface:
* Single Document Interface (SDI): not appropriate for the GIMP
  because it must be possible to open more than one image.
* Controlled SDI (CSDI): this is approximatively what the GIMP uses
  for the moment.  There is one control window (toolbox) for several
  document windows (image windows).
* Two variants of Multiple Document Interface (MDI):
  - Tabbed MDI: This is a modal interface in which only one document
    is visible at a time.  It provides a convenient way to group
    several documents belonging to the same application and to switch
    easily from one to the other.  Examples: Mozilla, gedit, etc.
  - Window-in-Window MDI (WiW MDI): this variant allows several
    documents to be visible and to be edited at the same time.
    Examples: Photoshop, Paint Shop Pro, etc.
  In both variants of the MDI model, there is one main window in
  which several documents can be edited.  The main window contains a
  common control part (menus, buttons) and information part (status
  bar).  The main difference is that the first one is modal and the
  other allows simultaneous viewing or editing of several documents.

Using the WiW MDI model for the GIMP would have some drawbacks
(discussed below) but also some advantages:
- It makes it easier to manage all image windows and to switch
  between the GIMP and other applications.
- Using a common menu bar and status bar for all image windows
  increases the amount of usable space on the screen.  With the
  current interface, the status bars in the inactive image windows
  are useless most of the time.
- The MDI child windows can have a minimal decoration without
  requiring any special configuration of the window manager.

Currently, the GIMP almost requires the usage of a dedicated
workspace from the window manager in order to avoid the problems
mentioned in the first point.  This is what most people use, assuming
that they have a WM that offers multiple workspaces.  The other
points (saving screen space) cannot be solved easily by the WM.

The WiW MDI model has also some problems, as mentioned by Mitch:
- There is a difference between the "real" top-level windows and the
  MDI child windows because they are not always decorated in the same
  way or behaving in the same way (depending on the WM and OS used).
  This can confuse the users.
- If the only way to access the menu is to move the mouse to the top
  of the large workspace window, then the pointer has to travel a
  longer distance than if the menu was in the image window itself or
  used as a context menu.
The second point can be solved easily: there is no need to remove the
context menu, so both ways can be used.  The first point is more
important and is the reason why some applications that were previously
using the WiW MDI model are switching to the Tabbed MDI model or even
SDI.  These applications (e.g., office suites) did not require several
documents to be visible at the same time so they did not really need
the WiW interface.  In some cases, they still offer a way to split the
main window in several parts to be able to compare some documents, but
this is not necessary most of the time.

However, there are some applications that are still using the WiW MDI
model: the drawing and painting programs.  For these programs, it is
often essential to be able to compare several images side-by-side (so
the Tabbed MDI model is not acceptable and splitting the window is
not ideal if there are more than two or three images).  It is also
important to have as much space as possible dedicated to the images
instead of having multiple menus or status bars on the screen (so
multiple SDI programs are not suitable either; CSDI can help but is
not optimal).

Currently, the GIMP is already close to the WiW MDI model because it
(almost) requires a dedicated workspace from the WM.  But this
requires a "decent WM", which is not available for all users (or not
the best choice for their platform or for their level of experience).
Unfortunately, even with a good WM it is not possible to have a
common menu bar and status bar, which would be more convenient.  So I
think that implementing a WiW MDI model as an option in the GIMP
would make sense.

I don't think that the difference between the "real" windows and the
MDI child windows would be a big problem.  On the contrary, even
under Windows some programs decorate their inner windows differently,
using very thin borders and a small title bar in order to minimize
the space taken by the decorations.

I don't know if I have convinced anybody with this long rant.
Anyway, this is only my opinion and I do not want to force anybody to
implement or use something that they don't like.  But if I have the
time, I will try to implement this and I hope that the code can be
integrated in the main branch so that it can be used by those who
prefer this mode of interaction.

Just like to throw in an idea: What about implementing "tabbed MDI"
with the possibility to open a second/third/... tab container? This
would work in a similiar manner as the GimpViewable stuff.

So basically the image windows would become GimpViewables and we'd
just need a "fancy GimpViewableContainer" where you for example can
embed the toolbox, image windows and the layers dialog in three columns.

Sorry, got confused. Of course I mean Image windows to become a
GimpDockable and the main window would be a GimpDock.

Thus we would not need to emulate window manager behaviour (which I
would not like at all) but have a simple way to allow the user to have
a "single-window-gimp".

I do not really see it too often that someone uses the WiW-MDI in
windows other than in the "fullwindow" mode. The importance of this
is IMHO overestimated. However, I can see an advantage of having all
of the Gimp in one big window, especially when you are bound to use a
sucking WM (Windows comes to my mind...).

And if someone wants to compare images side by side the user could
simply open another image-window container (or drag a tab outside the
Image window) and would have a lean "regular" image window.

Nasty stuff to think about: When there is a window dragged out, on
what image would the "global" menu in the main Gimp window operate?

Yes!  My good friend Michael Torrie has been asking for a dockable, 
tabbable image window since, well, as long as I've known him.

Please hold your breath. GTK+ doesn't allow for window-in-window MDI
and as long as there is no GTK+ widget for it (which will almost
certainly never happen) we shouldn't even consider to implement this
stuff. We can consider to add a menu to the image window (almost
working on Mitch's tree) and we can consider to try a tabbed image
window but we don't want to have multiple image windows in a larger
main window.

We also don't want to try what Simon suggests since the dockables
don't even work properly in their current state. If we are lucky we
get them to behave properly as they are now but I don't think that
making GimpDockables out of GimpDocks will ever work.

Reasonably good window managers with multiple workspaces are available
for all operating systems and all desktops out there. I don't see why
The GIMP should implement this functionality which is best handled
outside of the application.

Also don't forget that we are close to feature freeze for GIMP-1.4.

The reason GIMP seems to fare best with a CSDI or a WiW MDI, seems to
be that with the GIMP your edit windows are almost always a different
size. That is why I can imagine, for instance, that Film-GIMP uses the
interface it uses now, because there you work on frames/cells, which
are always the same size. 

In text editors and word processors, tabbed MDI makes sense, because
the  documents in those programs will almost always be edited to the
same width.

In web browsers, a hybrid approach makes sense (windows with tabs):
although technically web pages can have all kinds of different sizes,
they're often 'optimized' for a mythical 'standard' browser window
size. So, depending on your browsing needs, you would use different
tabs or different windows. Actually, there are cases, for instance
when using web applications (say you want to copy parts from a former
bug report to this bug report) where you would use separate windows
because you need to be able to view the contents of both at the same
time, and, on the other hand you may use tabs for all web pages,
simply because you do not care for the sizes of the web pages, and
tabs are easier to control than your window manager.

Mitch and Sven use a strange argument (in my view) for not
implementing WiW MDI: their toolkit does not allow it. Since when does
a toolkit dictate the functionality of the program you make with it?
In the rare instances I am coding (it happens), the desired
functionality of my program dictates what toolkit I will be using, not
the other way around.

Knuth wrote TeX, because with other toolkits he could not publish his
book. Mattis and Kimball wrote GTK, because with other toolkits they
could not write the GIMP they envisioned. 

Of course, the GIMP has a large investment in GTK, and on the other
hand GTK has been separated from the GIMP, so that the GIMP's
developers can no longer dictate what the toolkit should be like. But
if the GTK would suddenly decide to remove a widget that only GIMP
uses, GIMP would have to work around that too.

I am not saying that GIMP should move to a new toolkit, but lobbying
for WiW MDI with the GTK developers, just for GIMP, would not be wrong
IMO.

I will certainly not lobby for it since I think it is wrong.

I know that GTK+ does not currently support the WiW MDI model.  Also,
there won't be a GTK+ widget for it until someone implements it.  But
I think that there is a chance to have some kind of WiW MDI in GTK+
if someone contributes the code that does it.  There are not many
applications that would benefit from that (in most cases, using WiW
is the wrong solution) but I think that the GIMP is one of them,
that's why I am proposing to implement it in the GIMP first and then
move the code to GTK+ if the GTK+ developers think that the new
widgets could be useful in some other applications.  Note that I do
not see any other application that could benefit from it (and would
not work better with CSDI or Tabbed MDI), so it would be fine for me
if the widgets would be a GIMP-only thing (or GIMP & FilmGimp-only).

Actually, Havoc Pennington has been thinking about the same thing as
Simon (notebooks with windows that can be detached) but he is waiting
for contributions.  See this message, for example:
  http://mail.gnome.org/archives/gtk-list/2002-March/msg00070.html

Although the proposal from Simon is interesting (and goes along the
lines of what Havoc would accept for inclusion in GTK+ 2.x), I do not
think that it would work well for the GIMP.  In order to have a
consistent user interface, each dock would need to have its own menu
bar, button bar and status bar.  Otherwise, the user would not know
how to apply some operation to the detached images (as mentioned
above by Simon).  But if the menu and status bars are duplicated and
if we need a row of tabs in addition to these, then we will not have
gained anything in comparison with the current interface.  The amount
of available desktop space will be reduced, not increased.  I am
frequently working with a large number of very small images (such as
16x16 icons or 88x31 buttons) and I usually keep several (4 or 5)
versions of the same image side-by-side for comparison.  Putting
these small images into one or several docks would waste a lot of
space.  Besides, as Branko mentioned, notebooks are not appropriate
if you have documents (images) of different sizes.

Sven mentions that WMs with multiple workspaces are available for all
OS's.  I do not like this argument for two reasons:
- Why should we require the users to install something in addition to
  the GIMP?  They would also have to become familiar with this new
  environment (especially for Windows users), assuming that they can
  install it in the first place (not always possible for corporate
  users because changing the WM often requires administrator rights).
  This is a bit like saying: "yes, this application does not work
  well in GNOME, but we prefer to support KDE so please use KDE and
  the application will work better."  This is not very helpful.
- More importantly, this does not solve the problems that I mentioned
  above: the WM alone cannot provide a common menu bar at the top of
  the screen and a common status bar at the bottom of the screen.
  The main advantage of using a WiW MDI model is that it provides a
  single menu bar and a single status bar that is shared by all
  image windows (and used by the currently active MDI child window).

I think that the WiW interface is the best way to provide a shared
menu bar and status bar.  I am open to other suggestions, but so far
I do not see a better solution.

I see the problems you mention but I think that the suggested solution
is unacceptable. WiW is evil! Why do you want to put a large window
all over your screen that hides everything but your application?
Because your desktop sucks? Then get a better one.

I don't think we should try to improve this situation in The GIMP.
It's simply not correct to handle this in the application. We should
limit our responsibilities to a minmum instead of trying to do things
that are better handled by a window manager.

Having one menu bar on top of the screen ala MacOS could be an
acceptable solution and it would save screen estate. However this is
completely outside the GIMP realm. GIMP should use the hooks to
install such a menu bar if they were available but it shouldn't
attempt to create and handle such a beast.

If you ask me we should concentrate on providing proper WM hints and
should make sure that dialogs are set transient for their parents.
There is a lot to do in this area and help is needed. Please don't
waste valuable time by adding things to The GIMP which don't belong there.

I would like to have a large window all over my screen because it
provides a natural anchor point for the menu bar and status bar.  It
also prevents accidental clicks on the desktop or in other
applications, but this is a minor issue.

I don't think that we should expect all WMs (or even the major ones)
to provide hooks for a global menu bar and status bar in the near
future.  So the problem would still remain unsolved for the majority
of the users.  Also, I would not like to use a global menu bar for any
other application than the GIMP, because in most cases I would have to
move my mouse pointer more frequently between the application windows
and the menu at the top of the screen.

So I still think that a solution provided by the application itself
(GIMP or GTK+) is better than what can be done by any window manager.
I also think that some of the problems that we are trying to solve
(and we probably agree that the GIMP has some problems with its user
interface) are specific to image editing programs.  There are not many
other types of applications that should allow the user to view and
edit several documents of different sizes simultaneously.

I agree that the WiW MDI model has some drawbacks and should be
avoided in most cases.  But it is useful in some cases.  If it was so
bad, then why would all major image editing programs use that model?

I know at least one major image editing program that doesn't.

Fair enough.  s/all/most/  ;-)
I only checked Photoshop, Paint Shop Pro and Corel PhotoPaint.

I'd rather see GIMP providing (optionally) a global menubar/statusbar
of it's own, like the Mac. It could be limited to a single desktop, or
minimize/hide all the windows on a common desktop. Most people who use
WiW MDI maximize the container window anyway.

I think this solves most of the issues brought up here, and is way
eaiser to implement. There was also some discussion of having a system
wide menubar on one of the gtk lists a while ago, and having apps
automatically use it by sticking it in the existing menu classes. I
wouldn't hold my breath for this happening, but it is similarly easy
to implement this GIMP side.

The Mac way fits in much better, plus another very popular image
editing uses it.. namely Photoshop on Mac. ;)

From my point of view, having a container window covering the whole
screen is also an interesting feature: it avoids accidental clicks on
the desktop and minimizing or closing it will also minimize or close
all windows belonging to the application.  The buttons in the title
bar that the WM adds to the container window can be intuitively used
by the user and they affect the whole application.  This is less
intuitive if there is no container and all windows are independent of
each other.

My original plan for implementing the WiW MDI feature was to start
with a pseudo-container window covering the whole screen (with a menu
bar and status bar) while still using real top-level windows for all
image windows, etc.  The windows would still be independent of each
other, but the container window would always be placed below the
other ones in order to provide the illusion that the other ones are
inside it.  This should not be too hard to implement and it would
allow me to debug the code for the menu/status bars and ensure
that everything works as expected.  Adapting the code to a single
menu/status bar will probably require several days of testing, so
this intermediate solution is useful before any real work starts on
the implementation of the new MDI widgets.

But since you mention that it would be interesting to have an option
to have a global menu/status bar (without container) and the
implementation of that feature would be very similar to what I had
in mind for the intermediate debugging step, I will try to implement
both options.  One of them would be what you described and it would
be kept as an option; the other one would be one step towards the WiW
MDI implementation.

IMO the full-screen WiW MDI interface should be discussed on the
mailing-list before you start working on it. You risk to waste your
time hacking on a feature that might not be included at all.

OK, I will write a proposal and post it on the mailing list ASAP.

I changed my mind...  I will post the MDI proposal when I come back
from vacation, because it does not make sense to start a discussion
without being able to participate.  And sorry for the noise.

*** Bug 106483 has been marked as a duplicate of this bug. ***

Created attachment 14901 [details]
new interface

And what exactly would be better about this interface? IMO it has
nothing but disadvantages. The 1.3 user interface is much more
convenient and offers enough of an MDI interface.

What is better about this interface is that it allows Windows users
(who do not have multiple virtual desktops) to use the GIMP in the
same way as other drawing/painting programs: with a menu bar at the
top and the status bar at the bottom, showing the status of the
current image.  I also like the idea of displaying the tool options
right under the menu.  In addition, it puts everything in a single
window so that it is very easy to switch between application in the
way that is familiar to Windows users.

Two small criticisms about this pseudo-screenshot:
- I think that the docks as they are implemented in GIMP 1.3.x would
  work better than the concept shown here.  On the other hand, they
  take a bit more space on the screen.
- I don't think that we should try to use the same window decorations
  as for the top-level windows.  IIRC, other programs such as
  PhotoShop or Corel Draw use decorations that are smaller than the
  normal window decorations.  This is done on purpose in order to show
  that these are not top-level windows.  This also saves some space.
  When I discussed this issue with Owen Taylor, he also suggested that
  we should use smaller decorations instead of trying to copy the
  style of the WM.

Sven, I know that you don't like the WiW MDI model, but I think that
it is a good solution for Windows users, and probably also for most
users who are not using a window manager with virtual workspaces.  We
should try to make the GIMP work for these users without requiring
them to change their environment.  In addition, it will be easier for
these users to move to the GIMP if they come from another program,
because this type of user interface has been used for a long time by
many other painting/drawing programs (which are not moving away from
the WiW MDI model, contrary to what some people claim).

We have had a discusion on the gimp newsgroup this week, so I would
like to add my 0.0002 eurocents to this endless discussion, hoping a
third way could be possible.

First, I use both Windows and Linux Gimp, but am not a coder, so this
is from a dumb-user view.
Second, I think gimp should not do window management, this is not its
role, so I could be classified in the Sven Neumann supporters' gang ;)

Here are now two successive (or independent) steps I could see to
improve the usability for windows, without adding bloat to the source
code. Please feel free to flame me, or to comment on this two proposals.

1) Even on Windows, it is possible to send messages to the window
manager. Winamp is an example. On Linux, there are several standards,
the freedesktop WM spec (
http://www.freedesktop.org/standards/wm-spec.html ) seems to be the
most recent/interesting one. Thus, if Gimp should not do window
management, Gimp can send messages to the WM (and actually already
does, I think, with "save/restore windows position" preference).
So it should be not that hard (I'm not a coder, remember ;) ) to make
available in the preferences a capability to specify some options for
types of windows: "default", "always on top", "sticky" etc. The
windows types could be "toolbox", "docks", "image windows" and
possibly others. Gimp would thus set the policy and send the signal to
the WM.
At least, with this feature, Windows users could have more options to
control the interace, and I do not think the code would be bloated.
This could be a target for 2.0, as 1.4 is too close now.

2) Then, when this is done, a subsequent step can be started. In fact,
it can be done independently. This would be _out_ of Gimp project, and
could benefit to other programs.
The use of the "Windows in Window" paradigm is basically due to what?
In Windows, the WM is barebone, and its very few options are not
accessible to the user. So people have developed the WiW, with is
nothing more than a virtual desktop running one application in
full-screen mode. So some windows developers (not necesarily gimp
windows developers, and of course not MS Windows developers) could
solve the problem with a graphic shell/WM. A program where you launch
another program (and one only, to make it simple to code). Windows
build would then be usable either with the command:
gimp.exe where the gimp as it is now would be launched
or by
gimpshell, a batch file or shortcut which would launch "wiw_shell.exe
gimp.exe" (or something alike).
This would not be a rewrite of an independent WM, as are litestep and
its brothers. It would not replace Windows native WM. It would just do
it for a _unique_ program, wrap the interface inside a unique Windows
window (thus 1 button in the taskbar, minimize would minimize all).


Well, I know that this second task is partly off-topic as it would be
out-of gimp code (although used by the gimp build). I just wanted to
point that there could be a third way between the "we can not do
anything for the unfortunate windows users" and the "bloat the code
with WM/mp3 player/ftp client  because our OS is not able to do it".

Thanks for the attention and time spent on reading this :)

Regarding point (1), do we really need to make this configurable as
you suggest? IMO the GIMP should set window manager hints about the
typed of windows it creates. There is already a bug-report about this
(bug #94669) and it is supposed to be considered for 1.4. 

It's however the window manager's job to interpret this hints and do
stuff like 'keep this window on top' according to the window type.

Concerning point 1, I was thinking to something similar to what xmms
or winamp have, i.e. some "always on top" options. I 100% agree with
you about the responsability of the WM.
Personally, I use E as a WM, and even if it is old (years older than
the WM specs), it still can interpret the xmms hints and allows me to
easily set the placement policy.

My proposal is mainly in order to avoid future bug-reports and
messages on the newsgroup:

* even Windows WM is able to interpret the hints, so point 1 would
allow to answer: "File->Preference->Windows placement->etc."

* by detaching the WiW from gimp, this would allow to answer "there
exists a project that needs developers, called foobar on
sourceforge.net. This project would allow gimp and sodipodi and LyX
and etc. Windows versions to behave like in a WiW interface." and then
close the bug, which would then not be gimp related anymore. This
wrapper would just be like the Windows installer, an external tool
used by the Windows build of gimp.

However, I do not know what are the possibilities to code such a
wrapper (esp. in terms of intercepting signals sent by gimp to the
real WM). And I do not know if enough people with enough knowledge
would be interested to start such a project. Maybe sodipodi people
could be interested now that there exists a win32 port. And people
from windows port of gimp and from cinepaint. It is just a conceptual
idea to say there might be a way to solve this feature request,
without bloating gimp.

I don't think that we can easily move the WiW stuff out of the GIMP
as you suggest.  There are two things to consider:
- Changing the interaction model in the GIMP to be able to use a
  global menu bar and status bar instead of (or besides) the
  right-click menu and individual status bars in each image window.
- Implementing the widgets for the WiW MDI model: MDIWorkspace for
  the top-level container and MDIChild for the decorations of the
  child windows (without trying to mimic a whole WM, of course).

Both parts are necessary in order to have a working interface.

The first part is the most important one and it cannot be developed
outside of the GIMP, because it changes the behavior of the
application.  The same applies to some features such as being able to
display the tool options right under to top-level menu, as shown on
the screenshot.  As I wrote in December (2002-12-14) in reply to
Yosh's comment, this part of the work is what I am planning to start
with.

Regarding whether or not the WiW widgets (MDIWorkspace and MDIChild)
should be part of the GIMP or not is a different issue.  They could of
course be developed separately.  On the other hand, it is likely that
the GIMP will be the only application using these widgets because most
other applications would benefit more from the Tabbed MDI model than
from the WiW MDI model.  So I don't know if it would make sense to
develop this as a separate project, although I wouldn't be opposed to
it.

>- Changing the interaction model in the GIMP to be able to use a
>  global menu bar and status bar instead of (or besides) the
>  right-click menu and individual status bars in each image window.

Anyway, this would be a feature-regression, as the right click menu is
contextual and would not be anymore. For someone with two image
windows opened, applying filters to one and the other would be a major
pain.
Let's face it, the right-click menu (or top-left-triangle menu) is one
of the most useful features of gimp. It is a plus compared to other
software. It's not only a matter of taste. It can be measured in terms
of mouse-clicks, mouse moves, and in terms of Fitt's law. The
aquisition area (the area of the image window) is bigger than the
menu, and it is immediately available. Windows people are not used to
it, but it is a killer feature.

What I was describing does not go that far as what you describe. The
contextual menu stays in the image window. The only advantage of the
WiW that I have seen mentionned is the capability to minimize all
windows at the same time. This of course is easily done with a WM that
proposes windows grouping. This feature would be the one implemented
by the shell idea (if feasible).

When I wrote: "to be able to use a global menu bar and status bar
instead of (or besides) the right-click menu", I did not mean that the
right-click menu should be removed.  I only meant that those who
prefer to use a global menu bar can use it.  Yes, this would require
more mouse clicks.  But it will require less re-training for the
users.  As you pointed out, Windows people are not used to the
right-click menu.  Experienced users will probably switch to the
right-click menu once they become used to it.

There are more advantages to the WiW model than the ability to
minimize all windows at the same time.  If you work with all top-level
windows maximized (as many Windows users do), you can also switch
between applications quickly (in essence, this provides the same
effect as a virtual workspace, but it does it in a way that is
the "normal way" for many users - sigh!).  Also, having a container
window (the MDIWorkspace) covering the whole screen hides the other
applications and prevents accidental clicks on the desktop or in
another application.  And even if a top-level menu bar requires more
mouse movements and more mouse clicks, it has the advantage of being
always in the same place and being always visible.  This is important
for beginners who are trying to learn the interface.  The same applies
to the status bar and maybe also to the tool options, if they could be
displayed under the menu bar.  And the last advantage, which is quite
important from my point of view, is that a WiW MDI takes less screen
space overall because the menu bar and status bar are shared by all
windows and the decorations for the MDIChild windows can be rather
small.  This can be useful if you want to open several image windows
while you are working on a small screen (e.g., using an old laptop).

Of course, this has disadvantages as well: most UNIX users do not like
this kind of interface and prefer to use the advanced features of
their WM (unless they recently moved from the Windows world), the
shared status bar implies that you cannot see the status of several
images at the same time (but this is seldom necessary), you need more
mouse clicks and mouse movements to use the menus, and last but not
least, this feature still needs to be implemented and this is not a
trivial task.

*** Bug 57671 has been marked as a duplicate of this bug. ***

Sorry if I missed the discussion when it was current; still I think
that I can add my two cents.

The following solution might satisfy all those who ask for MDI and in
fact be better than conventional WiW MDI applications, but needs
support from the WM:

Have (optionally) a "background window". This window needs to be
*always* the last in the Z-order within the current application (i.e.
the last wrt all the windows in the same group), but on top of other
applications' windows that are not raised. When the background window
is moved, the application can change the placement of all of its
windows accordingly. When it is closed, the full application is closed
as is now happening with the toolbox. The menus that it holds could
correspond to the active image (the image seen e.g. in the navigation
window) or be the global menus used currently in the toolbox window; I
have no particular preference on this.

The advantages of such a window are the same as in MDI: it hides other
applications and the desktop (assuming it's big enough), acts as a
moving handle for the whole application, and brings all of the
application's windows to the top when it's raised. In addition to
these, it has an advantage over WiW MDI: the "child" windows can get
out of the "main" window's area if needed. This can also be seen as a
disadvantage by some people, though, because e.g. the menus can be
overlapped by the child windows, but I've always seen the confinement
of the inner windows as a problem of the MDI model.

Another big advantage is the simplicity of adding support for it in
most applications including Gimp. A disadvantage is the treatment of
some WM features like "shading" (i.e. shrinking the window to just the
title bar). If only the background window is shaded, there's no gain;
the remaining windows should be hidden at the same time for it to be
useful.

The WM_TRANSIENT_FOR property of the ICCCM could help in the
implementation of this feature, but I'm not sure if this is enough or
will need more support from the WM, as this is not exactly the purpose
it was originally designed for. Also, I don't know how GTK+ handles
this property. Anyway, having that option for the case the window
manager handles it properly is better than not having it at all.

Ugh, what you are proposing here is even worse than everything Raphael
has come up with so far. What you describe is usually refered to as
WiW (Window-in-Window) and there seems to be broad consent that it is
the worst user interface mistake that has ever been made.

No, read it carefully. What I'm proposing is a novel way of doing MDI.
See http://perso.wanadoo.es/p.gimeno/temp/mdi-proposal-800.png to see
the difference. It is *not* WiW. It's more or less what there is
already in Gimp but with the addition of a new window. None of the
alternatives to MDI currently available fits well with Gimp, but this
one could make a difference.

Well, if you read the comment that I posted on 2002-12-14, this is
exactly what I intended to start with, because using only top-level
windows makes it easier to debug things such as the common menu bar
and status bar.  However, I think that it should only be a temporary
solution that is replaced by new GTK widgets as soon as the code for
these widgets is ready.

I don't think that the proposed solution can be reliably implemented
because X11 doesn't give you any control about where windows are
placed. All you can do is hint the WM where you'd like the window to
show up.
I'd rather not see this code in GIMP since I don't believe that it can
be implemented in a sane and reliable way.

That's why I did not intend to keep that as a final solution, but only
as a temporary step during development.  Implementing MDI with multiple
top-level windows would be hard not only for X11, but also for Windows.

Note that it would be possible to implement this under X11 because there
are functions like XRestackWindows that can be used in combination with
ConfigureNotify events to restack the windows in the correct way.  But
there is no portable way to do this in GTK+ so I don't want to waste my
time trying to implement that.  The widget-in-widget model is the way
to go, IMHO.

How about: http://www.kde-look.org/content/show.php?content=6255.
Something called regimp: regimp is a container ("parent") application
for gimp 1.3.

Might satisfy the needs of some users.

Here's a small mockup I thought about. There would be an option to
have the toolbox be the master container window (for MDI lovers; not
shown on the mockup).

The toolbar would be horizontal with the tools grouped. 

The grouping is there because we have way too many tools and if
they're structured, they're easier to find. People use the toolbox for
tools they don't use too often (they use shortcuts for those). Also
the shortcuts and tool names are visible (without the need to wait for
a tooltip) - good learning aid.

http://jimmac.musichall.cz/stuff/mockups/gimp-toolbar.jpg

I hate that mockup, it has several severe problems:

- It mixes the toolbox and image menus.
- People will keep applying filters to the wrong image since there is
  no indicator of the active image. There shouldn't be the need for 
  such an indicator since the menu belongs to the image window.
- It looks so ugly (especially the windows-like gradient in the menu).

The number of tools will go down again when we move all the color
tools out again. We could think about making the image menu-bar the
default for 2.0 in order to make it easier for newcomers.

The basic idea behind the toolbox-as-pulldown menu looks ok (although 
personally I don't like icons-that-are-menus, but it's not hard to 
make icons or text labels an option)  The windows gradient label is 
pretty scary and shouldn't be implemented.


"The number of tools will go down again when we move all the color
tools out again."

Does this mean that the color tools will no longer be implemented as 
tools, or that we simply won't have an icon for them in the toolbox?  
I hope not the latter, because that leads to an inconsistant UI (some 
dialogs (like save) keep the current tool active, while 
other "dialogs" (like the histogram) make the current tool something 
different.  

Besides, the hiding of the fact that histogram et al. were 
implemented as tools was never done well before.  For instance, the 
tool options window would display something along the lines 
of "histogram tool: this tool has no options."  Since the user 
expects all the tools to be in the toolbox window, this is confusing.

Sure, it is a little wierd in the first place that the color tools 
are implemented as tools, but since they are, it is best to make sure 
that the user understands that he is working with a tool.  In other 
words, we shouldn't leave the tools lying around, but should put them 
all in the toolbox.

I don't see your point. Well, the Histogram tool is an exception, it
should be made a dockable dialog since it doesn't need to be a tool.

We only moved all tools to the toolbox in an attempt to clean up the
code. This was never intended as a final solution. Not having all
tools in the toolbox worked fine in 1.2. I don't see the problem of
doing the same in 1.3 now.

A followup on Sven's previous comment:
> - People will keep applying filters to the wrong image since there is
>   no indicator of the active image. There shouldn't be the need for 
>   such an indicator since the menu belongs to the image window.

I disagree.  The menu does not necessarily belong to the image window.
If you want to implement MDI correctly, the menu should be at the top
of the container window, not in the image window itself (although we
will of course keep the right-click menu, but those who prefer the
"main" menu on top will not have to use the other one).  Therefore,
it is necessary to have an indicator for the active image.

And anyway, there is already such an indicator in the current version
of the GIMP (without MDI).  It is provided by the window manager, and
it is already necessary for the user to know which image is the active
one because some image-specific operations are not started from the
right-click menu.  For example, anything done in the Layers, Channels
and Paths dialog such as hiding some layers or changing their opacity
or blend mode will affect the active image only.  Similarly, changing
the value of a color in the Indexed Palette will affect the active
image although the operation was not started from the image itself.
And for all users of a click-to-focus WM, the keyboard shortcuts can
be invoked on the active image even when the mouse pointer is in a
different location on the screen.  So the notion of "active window" is
important, even for the current version of the GIMP.

"We only moved all tools to the toolbox in an attempt to clean up the
code. This was never intended as a final solution. Not having all
tools in the toolbox worked fine in 1.2. I don't see the problem of
doing the same in 1.3 now."

Just because the behavior of 1.2 was confusing and inconsistant 
doesn't mean we need to repeat that mistake for 1.3.  Either a tool 
is a tool or it isn't.  A half-tool confuses the user because the 
active tool goes away when she didn't click on any tool in the 
toolbox?  Why should popping up an aparent dialog (after all, the 
color tools give no warning that they are in fact tools) cause the 
active tool to go away?  (yes, I know that there actually is some 
mouse-related functionality in some of those tools, but this isn't 
obvious and I doubt many casual users know that)

Why not make a docked Toolbox like in Sodipodi? 

Here is my mockup:
http://gug.sunsite.dk/pictures/1055190174.png

After a short poll in #gimp, we've moved the imagemap tools out of the
toolbox again. Let's see how people like the smaller toolbox of
1.3.15. IMHO the saved screen estate and the smaller number of tools
outweights  the fact that the behaviour is sometimes slightly confusing.

marking Target Milestone:Future

*** Bug 119812 has been marked as a duplicate of this bug. ***

*** Bug 121087 has been marked as a duplicate of this bug. ***

alright, interface as of 1.3.19 looks great to me except for one
detail.  Am I missing the part where I can create a pane that holds
the image in the main window?  I DON'T want a separate window floating
around in the main one, but I don't want it outside it either.  I want
to actually have it stuck to the side of the toolbox and stuff.  Then
I could simply adjust the width of each pane, add the tabs I need to
the (beautifully done) box just below the toolbox, and it'd be exactly
what I want, but better than I'd imagined.  Of course, selecting the
image would need the Image List tab, but . . . heh, no bother.

I've been stuck with gimp stable forever.  this new UI in the most
recent unstable is quite a shock to me.  Still, it's not good to let
developers feel they've accomplished the best until they have ^_~ 
Just lemme see a way to connect my image window to the main one, and
not have multiple windows at all, and I'll be happy.

Bluefox, please open a separate enhancement request for the feature
that you are describing (you could use the title "Allow image windows
to be docked").

This one is specifically about MDI, which should have:
1) multiple image windows inside one big window (it should be
   possible to work on more than one image window at the same time)
2) minimal decorations on the image windows
3) a single menu bar on top of the container window
4) a single status bar at the bottom of the container window

Your proposal would not allow multiple image windows to be visible at
the same time (criterion 1 in the list above).  In addition, it would
probably miss 2, 3 and 4 that are designed to save valuable space on
the screen.

As I understand it, this request is not for docked image windows, but
for a drawing area which will contain multiple, possibly overlapping,
image windows. That window would be a child window of the toolbox. At
least, that's what I understand...

In which case, this is MDI but without the toolbox and utility windows
in the container. And as such, it fits here :)

Cheers,
Dave.

Actually if you see bug 121087, you'll notice I DID start a new
report, before searching the bug database, and as a result wound out
making a duplicate of this bug.  There's a mock-up screenshot I made
with gimp 1.2.5 in there as well.  The request I made was, however,
for simply keeping one image window, and selecting which image is
being shown with the images tab.  I don't really want to see image
windows floating around separate; I prefer a single window, for
everything.

Of course, I also prefer lots of options.  "Am I missing the part
where I *can* create a pane that holds the image in the main window?"
 Not saying make it like that only, but just as an option.  I already
proposed this separate, and it was marked as a duplicate of this.

Also technically with this method you would use the same window to
edit multiple documents, just not at the same time.  Thus, this is a
request related to MDI.

OK, let me rephrase my previous comment: since the ability to dock
windows would result in a tabbed MDI model in which only one image
window is visible at any time, I had already excluded this feature
from this bug report.  See my comment on 2002-12-09, followed by the
proposal from Simon (yours is almost identical), followed by the
comments from Branko and others.

So if you think that dockable image windows would be a nice feature
(I don't think so), then I suggest that you open a new bug report
describing that feature.  Alternatively, you can re-open bug #121087
and change its summary to describe the new feature a bit better.

*** Bug 127077 has been marked as a duplicate of this bug. ***

*** Bug 130852 has been marked as a duplicate of this bug. ***

If you look at the comments for regimp
(http://www.kde-look.org/content/show.php?content=6255), many people
seem to want WiW MDI.

Are there any 'real' reasons, aside from personal taste, not to
implement a much wanted feature? Especially if you have volunteers?

We don't have volunteers though. If someone wrote a wiw implementation
that was reasonably compact, and was available as a preference, I
would certainly not object to it. I wouldn't use it, though - and I'm
not sure how you'd do it with gtk+, given that there is no way to get
the window manager style in a gtk widget, nor is there a way to
inherit gtkrc stuff that I know of. 

If someone wants to do this, it is a much-requested feature, and it
would be a welcome addition, as long as it did not replace the current
way, lived alongside it, and was maintained by the people who
developped it.

I think that tabbing image windows in a way similar to the mozilla tab
interface would be easier to do, and would be quite nice.

Cheers,
Dave.

Regarding the tabs, this is not a very good solution IMHO because they
do not allow you to work with multiple images of different sizes and to
view them side-by-side, which is often useful when working with images.
This has already been discussed in previous comments, but I will repeat
it anyway: image editors are somehow special in this respect because
the "documents" (images) usually have different sizes and it is useful
to be able to see more than one at a time.

Regarding the volunteers, this is something that is definitely in short
supply.  I started implementing this, then lost my work (disk crash),
then never got back to where I was.  It is still on my TODO list, but
any contributions would be more than welcome because I do not know
when I would have the time to finish this.  So if you have some
coding skills, feel free to help!

Raphael,

Why not?

If we copy the mozilla interface, we would have the choice of opening
a new image in a new image window, or in an existing image window as a
tab. I can still view multiple images together. When opening an image
in a tab, I just have to avoid doing a shrink-wrap and changing the
window size, so there's no real issue with images of different sizes
either...

Cheers,
Dave.

Being able to open multiple container windows is useful in any case,
regardless of whether we use the "true" WiW MDI model or only the
tabbed MDI model.  This feature would be necessary for those using
multiple screens.

But having multiple tabbed MDI containers _on the same desktop_ is not
as convenient as having a single WiW MDI container.  It would provide
some of the same advantages (being able to have several images side-
by-side) but at the expense of more desktop space taken by the window
decorations, duplicate menus and status bars, etc.  In this case, the
WiW MDI model is more useful if you want to view and edit several
small images at the same time.  In fact, I had already discussed this
in my rather long comment from 2002-12-09, which is still applicable.
I also repeated this on 2003-03-12: "WiW MDI takes less screen
space overall because the menu bar and status bar are shared by all
windows and the decorations for the MDIChild windows can be rather
small.  This can be useful if you want to open several image windows
while you are working on a small screen (e.g., using an old laptop)."

So, while I agree that having multiple tabbed MDI containers on the
same screen would allow several images to be edited at the same time,
this would not work as well as a WiW MDI solution.

For cross-references: bug #121087 is now focusing specifically on the
tabbed MDI model.  This one focuses on the window-in-window MDI model.

A thought borne out of a recent irc conversation: Xnest is almost
there, so perhaps the best way to implement it is to fix up Xnest,
have it support XRandR so resizing can work, and implement or adopt an
existing mini-wm, and do the glue to make it nicely integrated to
launch gimp.

A similar solution on windows could be done with VNC, though with a
performance hit.

FYI: someone implemented a plug-in that does something like WiW for
GIMP on Win32

http://registry.gimp.org/plugin?id=3892

Please don't start a flamewar about its description - it is a bit
offensive, but I will try to convince the author that it should be
less offensive, shorter and a bit more fucossed on the actual purpose
of the plug-in.

All his plug-in descriptions are like that, so you better approach him
with the same attitude he approaches us. Or better then, ignore him...

I read the descriptions of both of his plug-ins.  Despite the fact that
he uses a provocative style, he is right.  We should not ignore the
message even if the messenger is a bit weird.

Regarding Xnest and VNC, I doubt that these solutions would be accepted
by most users who are requesting MDI support, because they only provide
a workaround for one aspect of the user interface problems.  They do not
provide the good features of MDI (good for those who like it, of course)
such as having a common menu bar and status bar for all windows, savings
in desktop space by using minimal decorations for MDI children, etc.

I'd have more respect for the win32 plugins if his code wasn't so awful.

* savings in desktop space -> see my suggestion of having mini-wm that
runs in Xnest
* common menu bar and status bar -> gimp could make separate windows
for these, and the aforementioned mini-wm could handle them properly.
And a common menu bar that isn't tied to container window
functionality means we can integrate on the Mac better.

The bulk of the work is handling all the intricacies of subwindows and
window management, which Xnest+mini-wm can handle just fine. Keeping
that all separate doesn't impact the complexity of the app codebase
negatively. Modularity is a good thing, and the existing abstractions
all exist within Xnest and VNC already. And there are plenty of small
WMs to start from for the mini-wm project (Both for X and Windows).

Yosh is the first one who has ever added something constructive here.

For several years now, I am desperately waiting for someone who
doesn't like the current GIMP UI to do something about it. It is clear
that the solution is not in The GIMP, so there needs to happen
something on the desktop or toolkit level. Someone should get the
freedesktop people involved and design a spec for MacOS-like menubars.
Or write a patch for GTK+ that allows to implement such a thing.

Hi all,

This is the plugin writer here. As you've seen I've written a nasty hacky 
plugin that does something similar to this. It was a really quick half hour 
proof of concept, but it does seem to work suprisingly well in the few hours 
I've had to work with it. I've updated it to remember window position, 
background colour etc.

http://registry.gimp.org/plugin?id=3892

Why did I write this? Well, basically I'd spent hours and hours using gimp on 
Windows for image editing and design work and the more I used it, the more I 
got annoyed with a few things. The big one was when I was working with a 
folder of files, an html editor and several gimp windows. Every time I clicked 
off gimp, I had to select ten gimp windows to bring them back to the top to 
get them back. The same if I used alt+tab to leave gimp. It just didn't work 
like an application, it worked like a bunch of different ones. Every linux 
geek I asked about it said that the gimp interface was actually great, I just 
had to spend more time using it, or that I was a windows luser and didn't 
understand proper user interface design, or that I should get a 'proper' 
window manager.

The code is gross, uncommented and uses a bunch of windows specific things 
that will probably be totally incomprehensible to anyone who isn't a windows 
developer, this was really intended as a quick hack for me to use, but I put 
it out in case anyone wanted something like this and it seems quite a few 
people do. It has to do nasty hacky things so that it can work as a plugin, as 
it's pretty limited in what it can do.

The descriptions of the plugins are somewhat inflammatory, because I was 
pissed with all the time I'd wasted bringing GIMP windows to the front, or 
minimizing windows behind it. It used to be that I loved gimp despite the user 
interface, now with the combination of this plugin and the gimp 2.0 interface 
enhancements I'm using gimp happily on Windows without the interface being a 
problem at all.

Joe
news@joemarshall.org.uk

I personally like the gimp interface, with one exception. I have been using
Linux now for the past 2-3 years, but still did all my graphics work under
Windows with PSD and PSP. When I switched over to Linux entirely, I picked up
the gimp as my main editor (I only used it sparingly before hand, both the win32
and linux versions). With that as my background, I am very used to having the
toolbox  (and any other windows related to it, which for me, only other one is
the layers window) always ontop of the image. I like full screening my image,
and zooming in so I can really see the details up close, however, its a pain
when switching tools because I have to bring up the windows I need and switch
back. I dont want a "window in window" (Gimp aint like Photoshop for a reason,
and that image attached here is too PSD like), I dont want a tabbed window, I
just want the current Gimp interface to have an OPTION for making the Toolbox
and other dialog windows you have always on top (if your window manager supports
it) when a Gimp Window has focus.

Keith: that option does exist, see #131672. With some window managers you can
already do this in gimp 2.0 simply by setting the toolbox and/or docks to be
"utility" windows.

*** Bug 153498 has been marked as a duplicate of this bug. ***

*** Bug 159345 has been marked as a duplicate of this bug. ***

I've just installed The GIMP as I really want to move to OS software and
eventually Linux, but I'm finding the user interface awkward.  The MAJOR thing I
miss is being able to open a window, then open a folder window, and drag all
images in the directory into the image program.  This is extremely useful for a
large folder of images that I want to create thumbnails of.  You have them all
loaded in the application then systematically go through them and alter the size.

As far as I can see, with the GIMP you have to specifically go to File/Open for
every single image.  I don't mind how an MDI interface is implemented
(Window-in-Window, tabs etc) but it would increase usability no end if it was
possible to load several images into the same program.  If fact, it doesn't even
have to be done with MDI, if there could be a File/Open option to open all
images in a selected directory at once, even in their own windows, then that
would still be a great improvement.

Another problem is having The GIMP running displaying one image, then
double-clicking on an image file (or right-clicking and using Open With) and
having another instance of The GIMP be invoked.  Again, this would be solved if
you could drag several images into the one application.

I don't understand about "decent window managers".  I'm a Windows user but have
also been playing around with Linux, and I know that Gnome and KDE have virtual
workspaces, but I don't understand how this would help to be able to load and
work on multiple images within the same application?

If you have a folder of 100 images that have come from a digital camera, which
you want to quickly correct the contrast on, and then reduce to thumbnail size
and then save, then I don't see how having multiple workspaces will help.  Try
this task with MS Photo Editor and then try it in The GIMP and you'll see
exactly what the user interface problem is with The GIMP.

Unless I'm missing some really fundamental feature - I must admit I'm new to The
GIMP but have looked through the documentation and can't immediately see any
easy way of opening and working on images in bulk - in which case I apologise. 
Or perhaps I'm just trying to use the wrong application for this type of task?

Both drag&drop and opening images in an existing instance of GIMP are possible
and even the default behaviour. If this doesn't work for you, this might be a
reason for opening a new bug report (your issues as such are unrelated to this
report, though), but only after making sure that it isn't just a configuration
or user problem.

However, Bugzilla is no help forum, so you should rather ask for advice on one
of the mailing lists (see www.gimp.org for pointer).

Chris: You can also open several images by dragging a selection from the
explorer to the GIMP toolbox. And make sure that you are running at least
version 2.0.x of the GIMP. Oh - and check that the "open with..." is set to
"gimp-remote" or "gimp-win-remote" and not just "gimp".

Ah yes, Drag & Drop does indeed work but only if you drop into the top portion
of the tools window where the icons are.  I think I had previously tried
dropping anywhere/nowhere inparticular in the window and probably landed in the
bottom half which doesn't do anything, and therefore assumed that it doesn't
work.  Also sorted the remote thing as well...many thanks.  I still support the
MDI request though (in whatever way it is implemented) as it helps to keep
everything organised - you could at least minimise the whole application with
one click in order to reduce the clutter.  In reading all the previous messages
about this, it's obvious there are so many other implications that arise (such
as individual menu bars per image versus a global menu bar) that I can
understand the many different points of view and how difficult it will be to
agree on the best way to proceed!

Actually, I've just tried that plugin mentioned somewhere above and it works
quite well - I think I'm happy for the time being!  It gets rid of all the
individual windows from the taskbar and allows all windows to be minimised at
the same time.  Apart from that, the GIMP user interface is exactly the same,
with a separate floating toolbox window etc which is certainly what other
programs have anyway.  The background window and the individual GIMP windows
still work independantly so you could reduce the size of the background window
and leave it in the corner of the screen - whether you literally have it as the
background to all the individual windows is purely cosmetic but it does make
sense visually and spacially, especially within a MS Windows environment, to
have the controlling menu bar encompassing what it controls.  I haven't yet
tried GIMP on Linux, obviously this plugin only works on Windows, but I'll see
how I can get on with multiple workspaces, running GIMP on its own in one
workspace and then switching to another workspace if I want to use something else.

Oh, and furthermore...!

I've been pondering about what the plugin does to actually make the user
interface better.  In effect, the MDI model gives each application its own
virtual workspace, in Unix/Linux terms.  You can switch them in out by
minimising and restoring them from the taskbar, just as you do with Linux
environments.  The difference is that you can have several of these workspaces
on the screen at the same time, if you resize them and your screen is big
enough, whereas the Linux workspaces are mutually exclusive.  Food for thought -
MDI is actually the same as virtual workspaces except it's more flexible! 
Whether each document within the workspace has its own set of menu bars, or
whether you just have one for the workspace itself that changes to match the
current document, is probably a matter of taste.

I tried the mentioned WiW-MDI plugin and it's going the right but it's still
very far from the WiW MDI interface that we are so many that would like.

Not much inpur I know, but I just want to encourage people to keep
fighting/working for a WiW MDI interface for GIMP. GIMP is a fantatic
application and deserves more popularity. The current interface is preventing that!

Fighting for a WiW interface will never make it happen. Working for it might -
but then this work should go into the current platform specific solutions, to
make them more capable.

You could contact the author of the plug-in and suggest improvements if you have
any.

I don't think this should be handled platform-specific. Only very little work
needs to be put into abstracting window handling in GIMP to the point where it
would have a simple and well-defined API. At that point someone could write a
different backend and provide a WiW approach as an option. Obviously though,
noone really seems interested enough in such an option. Otherwise someone would
have written this code by now.

Just some short notes about what would have to be done:
1) Find one or several volunteers to work on that code
2) Modify the code for the status bar so that a single one (in a separate
   window or at the bottom of the MDI container widget) can be shared by all
   image windows.
3) Same for the shared image menu.
4) Abstract the window handling in GIMP so that image windows (and docks?)
   could be reparented and put inside some MDI child widget.
5) Create new widgets for MDI container (workspace) and MDI child windows.
   Draw minimal decorations for the MDI child windows (just enough to move and
   resize).
6) Optional: make it possible to detach MDI children and turn them into
   top-level windows.
7) Optional: use some platform-specific calls allowing the image windows to be
   featured in the task bar (or list of apps / windows), but not the docks and
   dialog windows.

It could be possible to skip (4) and (5) if we go for some intermediate solution
based on VNC or Xnest, as explained by yosh in comment #70.  But then we would
lose some opportunities for integration and we would also lose option (6).

For the moment, we are still stuck at item (1), although some unrelated changes
to the code are starting to make it easier to solve the other items.

Optional: Add tabbed images instead of this mess.

Tabbed images are not suitable because they prevent you from working on more
than one image at a time or to compare several images side-by-side (unless you
have several containers, but that has other problems).  Anyway, the proposal
for Tabbed MDI has been moved to bug #121087 some time ago and I suggest to keep
it there so that this bug report can focus on WiW MDI.

I think that most users asking for an MDI interface would be completely
satisfied by a GIMP layout that consists of a single window which toolbox and
docks on the left, tabbed images in the middle and an image dock for layers,
chanels, path and the like on the right. That would be a lot easier to implement
than trying to reproduce window manager behaviour in the application. That's why
I suggest to finally close this report as WONTFIX and concentrate on this much
saner approach.

Regarding comment #87, I don't see how using Xnest loses any oppurtunities for
integration, and option 6 can easily be realized using GTK+'s display migration.
In fact, I think my suggestion is the only practical way to do things, since it
minimizes impact on the app codebase.

Putting WiW MDI in the app adds a large amount of complexity, which not only
needs a volunteer to write, but one to actively maintain, which is much harder
to come by. Nobody has put forth a workable proposal that cleanly tucks this
functionality away, so this would impact all the app developers, which would
slow down other UI developments.

You'll also never get it 100% right at the app level. It's so much better to use
the current abstractions, which actually *work*, and minimal impact on GIMP's
codebase. The Xnest solution is about 80% there already, all it needs is some
glue and polish. Perhaps a month's worth of spare time work, and less for
someone working on it fulltime.

Am I missing something?  Xnest is an X client as well as an X server.  Windows
GIMP doesn't use X.  

Yeah, but you could hack something similar with VNC or the like. It'd involve
somewhat more glue than Xnest, but it should work.

There already is something similiar for Win32.
http://registry.gimp.org/plugin?id=3892

Somewhat broken from what I've heard on gimpwin-users, and also
application-specific. I don't know if there is a generic app that does this on
Win32.

*** Bug 169119 has been marked as a duplicate of this bug. ***

*** Bug 309525 has been marked as a duplicate of this bug. ***

*** Bug 313910 has been marked as a duplicate of this bug. ***

*** Bug 314225 has been marked as a duplicate of this bug. ***

I am not a GIMP developer (at least not yet ;), but I use GIMP frequently on
both, Linux and Windows. I'd really appreciate a MDI window for GIMP - again on
both, Linux and Windows. The point is usability: usually GIMP is not the only
application which is running on my desktop, when I use it for Website graphics
or anything else, there are many different applications open at the same time.
Okay, I could move GIMP and all its associated sub-windows onto a different
virtual screen on Linux (and this possibility exists on Windows too) - but I am
not comfortable with this multi-screen thing. There were times when I liked it,
but in the end it is not a good thing, regarding usability. The problem with
multi-screen is that I - as a working user - cannot concentrate on many desktops
at the same time. If I have many different desktops and several applications
running on all of them, I get lost and sooner or later don't know which apps are
open already and where. I don't want to remember or learn which application is
running on which desktop, I just want to see the running apps in my task bar.
That's why I switched off multiple virtual screens completely even on my GNOME
desktop.
Back to the subject: GIMP and the multi-window interface (as it is currently) is
only usable with (a) a multi-virtual screen desktop, or (b) when it is the only
application you have running at a certain point in time. Option (a) does not
running conform with any usability issue in my point of view - as I mentioned
above, I think multiple virtual screens are not usable at all. Option (b) does
not happen when I use my computer, since I have always more than one application
running.

My point of view might not be right in general, certainly there are people who
like the multi-screen thing and find it usable - there are always different
opinions. But I think GIMP should offer the option for both types or users, the
MDI and multiple window "likers" ;-). Well, let's find it out: make a poll on
the GIMP site and let the users vote, how important they find the MDI option.

An MDI interface is not the bad thing it used to be in the first versions of 
Windows. It can be more attractive and in fact easier to use when it allows 
grouping all windows and dialog belonging to the same application into the 
same grouping plane, without necessarily making lots of icons in the icon bar 
of window managers such as Windows.
It allows easier switching from one application to the other, also when one 
wants to work with screen snapshots.

It can be more attractive than the basic MDI interface that showed windows in 
windows: think about the dockable panels, merged menus, tabbed panes, etc... 
Look at the Eclipse GUI for interesting management of multiple dockable panes, 
and with its interesting concept of "perspectives" that allows concentrating 
the work on the document (in GIMP it would be the image itself, but there may 
also exist perspectives for working on multiple frames, or on animations.)

Well I won't like having multiple working documents in the same window: the 
MDI interface should be document-centric rather than application-centric. This 
means that the various tool palettes and menus should be merged in the same 
document window, and these tool palettes all dockable to that window, and 
detachable when desired, as floatting windows without icon in the system tray, 
and with no title bar decoration and no duplicate close buttons.

Really, the GIMP needs a more modern GUI design, with less distinct windows 
for the same working document. The current design is in fact confusive with 
duplicate menus (one in the tools window, one in the document window).

For example the "Acquire image" menu item is in the image window, but it 
creates a new document so it will create a new window; this is illogical.

A second example is the File/Open menu (and related...) duplicated in both 
windows.

The other example is the strange switch of the palettes when one switches from 
one image window to the other. Each image window should have its own tool 
palettes, not necessarily the same set of open palettes for each image, and it 
will even be more intuitive if those palettes are visually docked within the 
document window.

Another example is the help menu, absent from the document menu (why?)

Another example is the help window itself, which could be a docked pane 
showing contextual help on the side of the document window.

Finally, the GIMP uses its own look and feel, based on GTK, and it looks quite 
poor, and less usable on Windows, notably for users that don't have a mouse 
but a touchpad or trackpoint: one reason is the specific behavior of menus and 
comboboxes, which are difficult to use on touchpads. Why isn't there an option 
to use the native look and feel for such items? In windows, The GIMP should 
use by default the Windows look and feel. On MacOSX it should use the Mac look 
and feel. On Linux, it should use the current Window manager look and feel 
(Motif, Gnome, ...). Not all platforms need to support the look and feel of 
the other platform (for example there's no need to support the MacAqua LAF on 
Windows, but The GIMP could provide a common GTK look and feel on all 
platforms if needed, without forcing it to be the default).

Finally, reduce the number of steps or info provided in the first installation 
wizard: the default user folders should be immediately created, and later 
mchanged or moved by the user if he really wants to, by going into the 
preferences menu...

One more note about GTK look and feel on Windows:
upgrade the Windows installer for The GIMP to use this version of the GTKèWimp 
theme engine:

GTK-Wimp 0.7.0 (Monday, 27 June 2005)
*Menu/toolbars have a gradient applied to them 
*Better handling of menu/toolbar shadows, even tracking how the theme is using 
them 
*Sliders (GTK+ calls them "scales") now use WinXP theming 
*Apps with status bars now get the WinXP status bar grippie drawn properly 
*Toolbar grippies are drawn nicely too 
*Notebook tabs now get that orange stripe across their top 
*A host of scrollbar bugs are fixed 
*Other misc things 

With this version of the engine, it respects the Windows native look and feel, 
and solves the problem with comboboes, menus, and many others.

You can patch the current release of The GIMP after installation, by 
downloading the GTK-Wimp 0.7.0 (Monday, 27 June 2005) ZIP archive, then extract
- "libwimp.dll" into
C:\Program Files\Fichiers communs\GTK\2.0\lib\gtk-2.0\2.4.0\engines\
(replacing the old version)
- "gtkrc" into
C:\Program Files\Fichiers communs\GTK\2.0\etc\gtk-2.0\
(also replacing the old version)

Definitely it makes a lot difference in usability of The GIMP on Windows, and 
it works in collaboration with your current installed Windows XP native theme 
(as selected in the Windows display control panel), including Windows 
extension themes, and supports the current settings for cursor blinking rate, 
mouse behavior, ...

GTK-Wimp is now part of GTK+ istelf, isn't it?

*** Bug 317317 has been marked as a duplicate of this bug. ***

wxwidgets, a corss-platform toolkit, has ported MDI to GTK. the cvs is browsable
at http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/. Maybe that can help with an
implemantation of MDI for the GIMP.

Note that I don't want MDI (i.e. the old Windows concept that was abandonned).
In fact I want one window for one (image) document.

What I really want is to enhance usability when only working with one document:
there are too many windows, and switching from The GIMP to other concurrent apps
is a nightmare, because the various panels remain behind, and it's difficult to
see in the list of desktop icons which one refers to the wanted window (there
are too many icons too in the application bar).

It would be MUCH preferable to have dockable panels that can be detached in
separate windows if desired. And when panels are detached they should belong to
the same window group, without creating a new icon in the application bar.
Switching back and forth to the GIMP would then bring the whole group of windows
together.

To create such a feature, you need a transparent parent window (this is the one
that creates a icon in the application bar) that contains the document window,
and the undocked panels inthe same group.

If you work with several images, there will be several transparent parent window
grouping the image document with the undocked panels.

If you work on multiple calcs for the same image document, these calcs
andmultiple views should better be in the document window (that's the place to
use MDI or tabs).

The document window will merge the two existing menus into a single consistent
one. The existing main window will then become a transparent parent window
convering the desktop space, containing the document window, the merged menu,
and a undockable tool panel. It will have a non transparent MDI work area where
the document views will be displayed as child windows. The various dialogs
should not use that space but should be docked on one border, or detached and
placed into the parent window.

Philippe, you may want to try the latest development release and enable
transient docks in the preferences dialog.

*** Bug 354421 has been marked as a duplicate of this bug. ***

If MDI is not possible, at least a "always in foreground" option for each dialog should be added to the windows version of gimp.

Christian: that it doesn't work that way is because of bugs and lacks of features in GTK+ on Windows, not because GIMP wouldn't do all it can to make the behaviour like that.

I've skimmed all the comments, and as far as I can see, this proposal hasn't been made yet:

How about having each image in its own top level window (GtkWindow) and let them share the palettes (Layers, Channels, etc)?.

The "application" menu would be on each image, i.e. File -> New and so on (much like it is now), merged with the "image" menu, (Filters, Colors, etc).

When you start up GIMP, that will mean that there has to be a default new image created. When all images are closed, the whole of GIMP closes down. The default image can of course be changed to whatever.

Technically, you would have an manager class that keeps track of how many images that are open, and when no more images are left, the application closes itself. The File -> New menu items would bind to some method of this manager class, i.e. the manager class handles creation of new images.

This approach is exactly what I have begun experimenting with on my still vaporwarish C++ implementation of an IMP.

Having to keep an image around in order to keep GIMP open and allow me access to menu functions previously accessible from the toolbox just doesn't sound all that helpful to me.

The other problem with this approach is that, whereas a word processor is often used to create documents from scratch and at standard dimensions, most of the time GIMP is used to edit existing documents or create images of custom dimensions and resolution.

Combining the Application menu and image menu would surely do little to help menu clutter.

The windows interface is horrible.

*** Bug 422703 has been marked as a duplicate of this bug. ***

*** Bug 465178 has been marked as a duplicate of this bug. ***

*** Bug 472963 has been marked as a duplicate of this bug. ***

I still wondering why noone has leave it for the user to decide what interface did he prefer. Using SDI only is limiting the freedom and doesn`t in OSS style you know. What should one do currently to make MDI possible in GIMP ?
I`ll try to make some steps. 
Also i`ve heard that someone was hired to redesign the interface, but no other news since then. Was any work done?

I still wondering why noone has leave it for the user to decide what interface did he prefer. This behaviour is limiting the user`s freedom and doesn`t fit in OSS style you know. What should one do currently to make MDI possible in GIMP ?
I`ll try to make some steps. 
Also i`ve heard that someone was hired to redesign the interface, but no other news since then. Was any work done?

No one is hired to work on GIMP. All contributions are voluntary.

Still, we should finally close this report as WONTFIX. This has been discussed to dead and there are plans for a user interface that will solve the problems that the MDI approach is supposed to solve.

We are currently working on changes to the user interface that will solve the problems that the MDI approach is supposed to address. Window-in-window is definitely not part of this plan. It's not going to happen.

You ignore MDI it mean you ignore Windows Family Users,  Microsoft Rethink abount internet that they come back before die on netscape session,  Photoshop Rethink about  Windows Users now They come back #1 in all platform before Corel Photopaint nearly win in Windows platform.

PS: Windows Users is more than 70% in computer world (may be 20,000,000 users or more) (if you looking for donate (somebody in Windows users) you may be rethink.


I'am not reprimand you , true like you say, you not beg us to use, 
(1-2 USD / Users from us ,i think it easy for you 1-2 x 20,000,000 USD to make decision)

Come back to visit about mdi ui
Bye