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
