Re: [Usability] GIMP - CSDI and Toolbox

[Havoc Pennington <hp redhat com>]

On Sun, 2004-06-13 at 19:19, Alan Horkan wrote:
> 
> > What everyone hates about the Gimp is that cluttered feel you get with
> > multiple windows. But *that* is a *responsibility* of the WM, not Gimp!
> 
> Havoc Pennington where are you?
> I would be very eager to hear what he thinks the responsibility of the
> Window Manager is.
> 
> Metacity is the default Window Manager for Gnome (and Sawfish too) and the
> reality is that it is what most Gnome users will be using.
> Most KDE users will be using the default that ships with KDE (kwm?) and
> Microsoft 99.99% of users will

There's a metacity bug with some GIMP discussion.

The basic deal is that the WM can't work for any random thing app
authors want to do. What we need are a set of fixed ways that apps can
be designed from a high level. Meaning, if you look at kinds of window
(palettes, dialogs, documents, etc.) and how those window kinds relate,
app authors can't make this up. There has to be a fixed list of ways
apps can be done. Otherwise the WM can't figure out what to do, it can
only punt to the user to write their own WM extensions or something.

There's a Microsoft page that's sort of similar, defining "archetypes"
for applications:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaero/html/apparchetypes.asp

On the Mac for example, each type of window has specific behaviors. 
Palette windows don't get focus on click, and iirc vanish when their app
is not focused.

In the EWMH spec we already have far more window types than there are in
the Mac or Aqua HIGs, but the definition of the window types is a bit
too loose.

So what we really need is to write a document that has diagrams of a
"correct" app in each major archetype or pattern, and defines the EWMH
window types and expected behaviors for the window manager for these.

Then we have a framework to fix the problem, because we can say "the
GIMP is trying for app archetype Foo and has to change in XYZ ways to
implement it properly" and then we can say "the WM is handling archetype
Foo incorrectly in XYZ ways" and we can fix the WM.

The obvious archetype to start with is the basic "office" archetype most
word processors use. This one probably won't work well for GIMP though,
so one question is what _would_ work well for GIMP. Once we know that we
can figure out how to translate it to EWMH and implement it in the WM.

Personally I don't think it's possible to get this right by bottom-up
arguing about how to tweak the GIMP. We need to start with the global
view of _all_ the major ways to organize an application and its windows.

Havoc