On 1 May 2004, at 11:02, J. Grant wrote:

I wonder if there is any way I can donate money towards development of a specific feature addition in GIMP?

Hello J.,

I guess there are two ways:

1) Unconditionally donate money to the group. This may buy you goodwill, and it will enable GIMP developers to get together on GIMP conferences, which may help the progress of the project in general. However, it won't influence directly the creation of the feature you want.

2) Find a developer (not necesarilly an existing GIMP developer) who will create the feature for you.

Note that even in case 2, there is absolutely no guarantee that the feature will be folded into the GIMP tree that is developed by the people on this list.

For that, you would probably need to convince the people on this list that your feature is useful, and your developer will have to make sure (s)he sticks by the rules of adding code to the tree.

Of course, having the code remain outside the GIMP may be exactly what you want. In that case, your task is just to find a developer. There used to be websites where you could hook up with such coders (sort of like dating sites :-)), but I don't seem to be able to flex my renowned Google skills this very moment and find some for you.

If you would like to have something developed that can be used by others (i.e. free software), please tell us what you want.

J. Grant wrote:

Hi Branko,

Thanks for your reply.

While I love the flexibility the separate windows of the GIMP software provide. A friend and I think it would be very useful to have a "single window" styled layout (as well as the present flexible window position interface), where all GIMP child windows are within a core GIMP window. I think this is called MDI (Multiple Document Interface). This style of interface is common in proprietary gfx software we have used.

Actually, it is called Window in Window MDI, or WiW. It is mainly used on the Microsoft Windows platform, which, despite it's name, is rather limited in regard to handling application windows.

My friend and I are thinking £50 (UKP) each donation so far (I know not much, but we don't have a lot to spare.. if others would donate it could be increased). If there is support for this idea, I could email the gimp-users list and ask if others would like to donate for this feature.

I wonder if there are any programmers (way 2 below) who would like some donated money to work on this style of window layout..?

You might want to have a look at XNest, or the following GIMP plug-in if you are working on Win32: http://registry.gimp.org/plugin?id=3892 I don't know if there is an equivalent for Mac OS X, though.

HTH, Michael

On 1 May 2004, at 13:51, J. Grant wrote:

Thanks for your reply.

Could you please cut my reply from yours if there are no specific points of my reply that you are addressing? It saves unnecessary scrolling on my part.

While I love the flexibility the separate windows of the GIMP software provide. A friend and I think it would be very useful to have a "single window" styled layout (as well as the present flexible window position interface), where all GIMP child windows are within a core GIMP window. I think this is called MDI (Multiple Document Interface). This style of interface is common in proprietary gfx software we have used.

My friend and I are thinking £50 (UKP) each donation so far (I know not much, but we don't have a lot to spare.. if others would donate it could be increased). If there is support for this idea, I could email the gimp-users list and ask if others would like to donate for this feature.

I am a firm believer of WiW for GIMP like software, but as such I stand mostly alone in this group (and I am not a developer, so don't expect any code to come from me).

There have been several discussions about this topic; on this mailing list, in articles and discussions on Advogato, and in the Bugzilla enhancement requests posted for this and similar features (see ). Search for terms
like MDI, SDI, WiW et cetera. If there is any new information you can bring to this discussion, please do so on the appropriate forum.

The consensus so far seems to be that the developers don't want to touch such a feature. It's hard to find the real arguments against the feature through the forest of emotional arguments that the discussion has produced so far, but it seems that the developers won't touch it, because the GIMP works perfectly fine for them the way it does now, and in their working environment. And that is of course a perfectly valid argument.

Depending on the operating system you use, there may be software available that can help you. For MS Windows, for instance, there's a tool called Gimpex (). I
haven't tried it much yet.

Hi,

"Branko Collin" writes:

The consensus so far seems to be that the developers don't want to touch such a feature. It's hard to find the real arguments against the feature through the forest of emotional arguments that the discussion has produced so far, but it seems that the developers won't touch it, because the GIMP works perfectly fine for them the way it does now, and in their working environment. And that is of course a perfectly valid argument.

There are a couple of good arguments against this "feature". Basically it is agreed that WiW is a bad concept that is being dropped by all major software companies nowadays. It was only ever introduced to work around the problem that some operating systems, namely Windows, don't handle many windows very well. So we should ask ourselves why people keep asking for it. I remember people mainly giving the following reasons:

(1) multiple windows clutter the taskbar (2) the application can't be minimized/maximized as a whole

GIMP addresses these points by setting the same WM_CLASS attribute on all GIMP windows, including plug-in dialogs. This allows the window manager to group the GIMP windows. This means that GIMP only shows up as a single item in the taskbar and that all its windows can be minimized/maximized together. Most window managers on Linux support this and I heard that Windows XP does at least support the taskbar grouping. I am not sure where Mac OS X stands here.

Are there other advantages of WiW that I didn't address here?

There are a couple of technical arguments against the implementation of a WiW user interface. First of all, there's no support from GTK+, so this would have to be all implemented in GIMP. It would duplicate the window manager functionality and the way that GIMP manages its subwindows would almost always be different than how the toplevel windows are managed. That's very bad from a usability point of view.

Another argument is that we would certainly not want to drop the current user interface since it works well for a lot of people. So the WiW feature would have to implemented transparently for the rest of the application and doing this will be very difficult. It seems a lot easier to implement this whole thing outside The GIMP. There are already several attempts at doing this. They are all platform-specific but that's probably unavoidable. A sane approach for GIMP running on X11 is to run GIMP and a simple window manager in an Xnest session. Perhaps we should bundle a script that does this with the standard GIMP distribution.

Sven

On 05/01/2004 07:16:32 PM, Sven Neumann wrote:

There are a couple of good arguments against this "feature". Basically it is agreed that WiW is a bad concept that is being dropped by all major software companies nowadays. It was only ever introduced to work around the problem that some operating systems, namely Windows, don't handle many windows very well. So we should ask ourselves why people keep asking for it. I remember people mainly giving the following reasons:

(1) multiple windows clutter the taskbar (2) the application can't be minimized/maximized as a whole

(3) the windows that are below it are not hidden by the application (4) the application can't be "shaded" (i.e. leave only the window title bar) as a whole

For me there's another reason explained below.

GIMP addresses these points by setting the same WM_CLASS attribute on all GIMP windows, including plug-in dialogs. This allows the window manager to group the GIMP windows.

Personally I find it irritating to have so many windows open at once. In WindowMaker my only choice is to guess which of the icons is the GIMP one because it doesn't provide an icon that WindowMaker likes, so in practice I can't raise all windows at once. I also find confusing that between the image and the toolbox or the layers or the info window there can be windows from different applications. Of course a solution is to dedicate a virtual desktop only for the gimp but that's not practical sometimes.

This means that GIMP only shows up as a single item in the taskbar and that all its windows can be minimized/maximized together. Most window managers on Linux support this and I heard that Windows XP does at least support the taskbar grouping. I am not sure where Mac OS X stands here.

Taskbar grouping doesn't help since when you click on the taskbar button what you get is a menu of windows to choose from. It reduces the cluttering of the taskbar but does not allow raising all windows at once.

There are a couple of technical arguments against the implementation of a WiW user interface. First of all, there's no support from GTK+,

I'd say that first of all there's no WiW standard for window managers to comply. As a consequence, the embedded windows must be managed and decorated by the application rather than by the window manager, resulting in ugly hacks like those of kvirc and Scribus. Now this implies your argument about the lack of support from GTK+, which should act as a (sub)window manager for these reasons.

Another argument is that we would certainly not want to drop the current user interface since it works well for a lot of people. So

I seriously doubt that any user would object against having WiW in the preferences.

the WiW feature would have to implemented transparently for the rest of the application and doing this will be very difficult.

I don't think it would be so difficult actually, as it's just a matter of reparenting windows.

I am making an experiment about transient windows. It is not window-in- window but uses a background window similarly to what "Deweirdifier" does. If it works well, maybe I can make the patch available as an attachment to bug #7379. Here's the result:

http://perso.wanadoo.es/p.gimeno/temp/bgw-screenshot-1024.png

(unlike http://perso.wanadoo.es/p.gimeno/temp/mdi-proposal-800.png this one is NOT a mockup but an actual screenshot)

Pedro Gimeno

Hi,

Pedro Gimeno Fortea writes:

(3) the windows that are below it are not hidden by the application

But that's _the_ major advantage of the current user interface. It allows you to easily use GIMP together with other applications such as web browser and file managers.

Taskbar grouping doesn't help since when you click on the taskbar button what you get is a menu of windows to choose from. It reduces the cluttering of the taskbar but does not allow raising all windows at once.

It does so here (using sawfish). IMO it would be a major regression if the individual GIMP windows would not any longer be accessible via the taskbar. That's the nice thing about taskbar grouping. You get a single item in the taskbar that represents the application but you can still easily access a specific GIMP window.

Another argument is that we would certainly not want to drop the current user interface since it works well for a lot of people. So

I seriously doubt that any user would object against having WiW in the preferences.

That's not my point. But adding WiW to the GIMP code will almost certainly add a level of complexity to to the user interface code. Let alone the fact that noone has yet come up with a proposal on how plug-in dialogs should be handled.

the WiW feature would have to implemented transparently for the rest of the application and doing this will be very difficult.

I don't think it would be so difficult actually, as it's just a matter of reparenting windows.

Eeek, reparenting :( Reparenting should IMHO be avoided. It will break code that relies on gtk_widget_get_toplevel() working properly.

I am making an experiment about transient windows. It is not window-in- window but uses a background window similarly to what "Deweirdifier" does. If it works well, maybe I can make the patch available as an attachment to bug #7379. Here's the result:

http://perso.wanadoo.es/p.gimeno/temp/bgw-screenshot-1024.png

I don't understand this screenshot; it seems to just add another window. What's the advantage?

Sven

On 05/02/2004 02:01:37 AM, Sven Neumann wrote:

(3) the windows that are below it are not hidden by the application

But that's _the_ major advantage of the current user interface. It allows you to easily use GIMP together with other applications such as web browser and file managers.

That's not an advantage for everyone :)

Taskbar grouping doesn't help since when you click on the taskbar button what you get is a menu of windows to choose from. It reduces the cluttering of the taskbar but does not allow raising all

windows

at once.

It does so here (using sawfish). IMO it would be a major regression if the individual GIMP windows would not any longer be accessible via the taskbar. That's the nice thing about taskbar grouping. You get a single item in the taskbar that represents the application but you can still easily access a specific GIMP window.

I was referring to the behaviour under Windows XP. Taskbar grouping is not useful there since you can't still raise all windows at once.

Let
alone the fact that noone has yet come up with a proposal on how plug-in dialogs should be handled.

Making them transient for the application window would be enough; it's not necessary for them to be inside the app window. Only windows which are "permanent" need to be: image windows, docks and such. However I don't know if a window in a separate process can be made transient for the application window. Probably not. But then, leaving them free is not so troublesome as long as the permanent windows are not.

Eeek, reparenting :( Reparenting should IMHO be avoided. It will break code that relies on gtk_widget_get_toplevel() working properly.

If that code is in the GIMP then it would have to be changed of course; reparenting is a prerequisite for WiW. I don't expect the GIMP changes to be problematic at all. With the appropriate help from gtk+ it could even be made transparent with no need to change the code. But I don't expect the gtk+ guys to be adding support for WiW, so a gimp wrapper function controlling which windows are "toplevel" within their big parent sounds like the reasonable approach. What worries me is the gtk+ code relying on it; that needs testing at least.

I don't understand this screenshot; it seems to just add another window. What's the advantage?

It has the same effect as what the "Deweirdifier" plug-in does: adds a background window which hides the windows below (you can, at your option, shrink it vertically if you don't want that); also, on Windows it's the only window showing up in the taskbar during normal work. The screenshot emphasizes that the windows on top of the background window are not inside it, to remark the difference with WiW; however the expected workflow is to have it maximized or otherwise so that all other windows lie inside it.

Pedro Gimeno

Hi,

Pedro Gimeno Fortea writes:

Making them transient for the application window would be enough; it's not necessary for them to be inside the app window. Only windows which are "permanent" need to be: image windows, docks and such. However I don't know if a window in a separate process can be made transient for the application window. Probably not. But then, leaving them free is not so troublesome as long as the permanent windows are not.

If you read the ICCCM specification you will notice that the transient relationship is not meant to be used like this. Please don't get me wrong, I am not saying that we shouldn't attempt an optional WiW user interface but I think your approach is not a good solution. It abuses a window manager hint and it only works on certain window managers. With a different window manager like for example metacity, yout change will break window positioning. Also a lot of window managers decorate transient windows in a way that makes the windows appear as temporary popup windows (that's what the ICCCM spec says what transient is all about). Some WMs don't decorate the window at all, some window managers keep transient windows above, others don't. This makes GIMP more or less unusable. The fact that it somehow works with your WM doesn't make this an approach that is worth following.

Eeek, reparenting :( Reparenting should IMHO be avoided. It will break code that relies on gtk_widget_get_toplevel() working properly.

If that code is in the GIMP then it would have to be changed of course;

That code could very well be in a third-party plug-in where it can't be changed. I don't think we can break the assumption that GIMP windows appear as toplevel windows at the GTK+ level. So the right approach is to embed the GIMP windows at a lower level, like Xnest. This would be a platform-specifc solution but that's IMHO the only way to implement this reliably. I think it should be possible to come up with reasonable approaches for the different platforms we support. Actually the Mac OS X users will probably not desire this "feature" at all since all Mac applications behave like GIMP currently does. What the Mac people are asking for is to have the image and toolbox menus merged into a menubar at the top of the screen.

Sven

Hi,

"J. Grant" writes:

Another argument is that we would certainly not want to drop the current user interface since it works well for a lot of people. So

I seriously doubt that any user would object against having WiW in the preferences.

That's not my point. But adding WiW to the GIMP code will almost certainly add a level of complexity to to the user interface code. Let alone the fact that noone has yet come up with a proposal on how plug-in dialogs should be handled.

IMHO, the plugins could be left un-bound to any window as they are atm. Or is there a hard coded underlying attachment between the plugin and parent windows required for it all to work?

Are you saying that plug-in dialogs should be handled differently than core dialogs? If we want to implement WiW, then plug-in dialogs need IMO be embedded into the container windows just like any other GIMP dialog.

Sven

Hi,

J. Grant wrote:

Hi, I wonder if there is any way I can donate money towards development of a specific feature addition in GIMP?

We are currently working out two things which may be of interest - first, we are working to have a way to make tax deductible donations to the GIMP via another organisation. And second, we are working out a set of bounties with another donor.

In short, for small amounts there is no point in proposing to pay for the feature (I note that you are proposing something like £50, which is very generous for an individual, but it is hardly an incentive for a developer to do a couple of weeks work - the incentive would be actually wanting the feature).

We always accept feature requests, and it is quite possible that your feature request is already on our TODO list. Unfortunately the TODO list gets things added to it quicker than they get taken off - the resource we lack most at the moment is people willing to take on a feature and code it.

However, there are several ways you can donate money to the GIMP - you can donate to the FSF directly, who have always been our biggest sponsor, and have given us great support over the years, or if you hold on for a few days, you will be able to donate via PayPal (and perhaps other ways - details will follow) directly to the GIMP. Your money will go towards having as many developers as possible meet up for the GIMP Developers Conference in Norway this Summer, which will be hosted by GUADEC.

Thanks for your generous offer, in any case. I hope we can make it easy for you to donate in the very near future.

Cheers, Dave.