We do not set the always_on_top hint, we'd never do that.

The fact is that your WM interprets the Window Manager spec
incorrectly. We are only setting a window type hint of 'utility
window' on the docks. The WM spec doesn't specify that these windows
should be held on top. Please open a bug-report against your window
manager.

Couly you please tell us which WM you are using so that we can
reassign the bug-report if possible?

metacity-2.5.2

Metacity doesn't stack utility windows always-on-top, though it does
keep them above other windows in the application.  I suppose we could
get rid of that.

Updating the summary.

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

On the mac, are palette windows kept on top of document windows?

Would that make a difference? IMO the WM should not keep windows on
top unless the application or the user explicitely asks for it. The
spec is really lousy in this regard, it shouldn't leave so much space
for interpretation.

Yes it makes a difference, I'm wondering what the opinion of the mac
UI designers is.

The whole point of the spec is to leave room for interpretation;
that's why it's TYPE_UTILITY not STATE_ON_TOP_OF_GROUP. The spec uses
semantic types to allow different WM UIs.

It would make a difference if the spec had a window type hint for
palettes and one for a toolbox but unfortunately the spec is missing
these. Perhaps we need to change GIMP not to set the window type hint
and instead set the window behaviour more explicitely.

IMO it would have been a lot better not to have any semantic types in
the spec. There could be a set of typical window setups for
application developers to use. These would be similar to the window
types the spec has now but they would define an explicit set of window
attributes instead of leaving it up to the WM to interpret how for
example a "utility" should be treated.

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

I've added a workaround to The GIMP now. GIMP users can specify the
window type hint to set on the toolbox and on dock windows in their
gimprc. The choice is between normal and utility. This is somewhat
akward but it allows to workaround this problem:

why not just set NORMAL hints on them?  TYPE_UTILITY is for a "small
persistent utility window".  GIMP currently uses TYPE_UTILITY for
absolutely everything, including dialog boxes (e.g. the "Measure
Angles and Distances popup dialog), which is just plain wrong.  Seems
like it should just use NORMAL for GIMP dock windows.  The only reason
I can think of why GIMP uses UTILITY at all is for the smaller window
decorations, maybe?

GIMP doesn't use the utility type hint on almost verything. The
dialogs you mentioned use "dialog" (mainly because they are derived
from GimpDialog and because the type hint fits). GIMP uses "utility"
for docks because the definition of the type hint matches the window
type best.

OK, I stand corrected. We did indeed use the utility type hint on tool
dialogs. This was more than questionable and I've changed it now.

I think the problem that people are having here is that the GIMP docks
aren't "small persistent utility windows", but are rather behemoths
that are really designed to be quite large, expecially when the
docking feature of the docks is used.  It's also somewhat odd that the
main GIMP toolbox sets a NORMAL hint while the other docks set a
UTILITY hint, since visually and semantically these windows are really
equivalent.  As far as I can tell the only reason the main toolbox
isn't just another dock is to have somewhere to put the menu bar.

I've asked the wm-spec list to try to find out what semantics other
WMs are using here.  It seems worthwhile to standardize here.  The
GIMP dock windows are just so much different than anything else out
there that it's hard to know what to do with them (though they are
unquestionably very cool).  Maybe it'd be worthwhile to have a
gimp-style dock window semantic type.

Yes, a window type that matches the role of the GIMP docks would be
very much appreciated. Utility fits best so far but I admit that it
doesn't feel right.

I should point out that it's not overly likely that such a thing will
make it into the spec.  I still think that the best bet for GIMP in
the short term is probably to use NORMAL for the dock windows.

One thing I've noticed with GIMP is that window placement for gimp
dialogs is woefully bad.  Whereas it generally makes sense to popup a
dialog centered over a window for almost everything else, in GIMP you
almost invariably want the dialog anywhere _but_ centered over the
window you're working on.

Not really sure how to solve this problem; perhaps GIMP should use
little drawers popping out of the image window instead of dialogs or
something like that, or some heuristic metacity could use to try to
place these things better.  Or perhaps GIMP shoud explicitly place its
own dialogs (which metacity will respect). GIMP certainly poses a
unique challenge for a window managers.

Almost all GIMP dialogs are session managed. So they may popup in a
bad place when they are used for the first time but then GIMP will
remember where the user moved them the last time. IMO this works
reasonably well.

Gimp dialogs just aren't dialogs. Dialogs are things that appear, you
click a couple things, and you close them. The GIMP windows are not
this, they are persistent control windows you'd expect to keep open at
length and session manage.

If we really want to solve this we need to sit down and:

 - define the "application archetypes" as Microsoft calls them; 
   the control flow or work pattern for each type of app, the 
   kinds of windows found in that app type, how each window behaves
 - sync this with the spec; a window type in the spec for each 
   type in the app
 - GIMP has to conform to one of these predefined archetypes, 
   not make up whatever it wants

Short of that, just using NORMAL and having GIMP override the WM is
the only answer.

Apple's UI guidelines have 4-5 window types covering *all* app styles,
our spec already has several more than that.

My view is that this bug is NOTABUG honestly, because UTILITY is
supposed to be the little palettes as with the photoshop toolbox, and
those are always on top of their parent in photoshop aren't they?
The Apple guidelines document what they are like. They never get
keyboard focus for example.
Gimp doesn't have this kind of window really iirc. But maybe on
wm-spec-list someone else would interpret UTILITY differently.

I agree with Havoc: this is NOTABUG for Metacity (of for the EMWH
spec).  This is a GIMP bug, or rather a set of GIMP bugs related to
how the GIMP manages its windows (pop-up dialogs, docks, etc.).
Currently, a GIMP dock is used as a top-level "main" application
window (except that there may be several of them) and should get the
NORMAL hint.

The type UTILITY should only be used for the dialogs if we implement
the MDI model as described in bug #7379.  I suggest that we use NORMAL
in GIMP 2.0.  For future versions such as 2.2 or more probably 3.0, we
should really re-think some parts of the user interface and stick to
some of the known models.  This would also help the users of platforms
other than Linux (e.g., Windows) because we cannot always tell them to
get a better WM.

Raphael, you know that you are pretty much on your own with this
opinion and that this kind of drastic user interface change will
probably never happen.

The problem with the EWMH spec is that it assumes a user interface
that is single document centric. It simply doesn't provide the window
types and other hints that an application like GIMP would need. There
is for example no concept of a leader window such as the GIMP toolbox.

We could agree that Metacity has a right to interpret the spec as it
does and it could be argued that the utility window hint doesn't fit
our docks good enough and would better be avoided. But I still believe
that a bug report needs to be opened against the EWMH spec asking to
extend it so it fits the needs of more applications.

Sven: I realize now that my previous comment could have been
interpreted in the wrong way.  I was not suggesting to plan MDI for
2.2 or 3.0 (even though I think that it would be an interesting
option), but rather some re-thinking of the GIMP can interact in the
best way with the user and with most WMs.  Anyway, let's not discuss
the MDI stuff here, because this bug is about how the current GIMP
docks are handled.

Contrary to what you wrote, I think that the GIMP does not really have
"a leader window such as the GIMP toolbox".  The difference between
the toolbox and the other docks is that it has a menu bar (which could
even be made optional) and the buttons for the tools (which can also
be accessed via the image menu).  So for most purposes, the other
docks can be considered as "control windows" in the same way as the
toolbox.  You can control the image window from any of the docks as
well as from the toolbox: it only depends on the tabs that are
included in the dock (e.g., the Layers tab).  No user would be
surprised if the menu bar or the tool buttons could be dragged to
another dock, like all other things that can be detached.

So from that point of view, I agree especially with the first
paragraph in Havoc's comment.  And as a consequence, it would make
more sense for all GIMP docks to have the NORMAL hint.

There is a lot of special treatment of the toolbox that makes it stand
out. It's not yet another dock window. If you want me to explain you
the details, please bring this up on the mailing-list.

Back to how GIMP can interact best with window managers. As you may
have notices already, we added code to let the user configure how GIMP
interacts with the window manager. This fixed most (if no all) WM
issues that people reported.

That's not a fix; it's a workaround.  GIMP needs to work out of the box.

That is hardly possible. Perhaps if there was API to ask the determine
window manager behaviour. For example we'd need a way to find out
whether click-to-focus or focus-follows-mouse is being used. But since
there isn't, we depend on guessing the desired behaviour (based on
host platform) and we need to provide a way for the user to configure
the behaviour.

By the way, this is getting a bit off-topic for this bug report, but I
think that the default should be the same for all platforms.  As far as
I know, all current Linux distributions are shipped with a WM that uses
the click-to-focus behavior by default.  The GIMP should use the same
default.

I know this is getting off-topic but I'd like to use this channel to
ask for opinions and advices. If you think we should move this
elsewhere, let me know about your preferences.

It seems obvious that the utility window type hint doesn't match our
dock windows good enough. We sortof solved this now by making the hint
configurable. But perhaps we should ask ourselves why people keep
asking us to set the utility hint and at the same time others complain
about the way their WM reacts on this hint...

There seem to be two kind of people. Those who prefer the toolbox and
the docks to float over the image window(s) they are working on. And
those who want to the image window to raise when they are working on
it. When people of the first kind discovered that the utility window
type hint causes the docks to float, people started trying to persuade
us that utility type would suit well and that The GIMP should set it.
It seemed like a good idea and we went for it. Then the other kind of
people got upset since suddenly windows sticked on top of their image
windows, even in fullscreen mode!

So what is it what our users really want us to do? The user doesn't
care about window type hints, what she cares about is behaviour, how
the windows are handled. So instead of giving the choice for window
type hints, shouldn't GIMP give the user the choice to decide if the
toolbox and/or docks should stay on top of image windows or not? Now
what would be the correct way to achieve this behaviour?

well I guess the best bet for now would be to set a NORMAL hint and
also optionally set _STATE_ABOVE, though this isn't quite what you
want since the dock windows should only be above the image window and
not above other application windows.

Maybe a _STATE_FLOAT hint would be a good idea, to give the floating
window behavior metacity uses for utility windows, or a new semantic type.

Not really sure what to do here.

People involved with Inkscape (forked from Sodipodi) suggested to make
the docks transient to the active image window. This means changing
the transient parent when the focus switches to a different image
window. This way the float above the document windows behaviour is
achieved.

I consider this an abuse of the transient relationship. But perhaps I
am misinterpreting transient-for ?

The idea of the semantic window types is that you can choose a WM or
configure your WM so each type behaves as you like, so if you do feel
these windows are semantically the little utility palette windows as
on the Mac, then you probably want to mark them as such, and if users
don't like the resulting behavior they should change WM to one that
does what they want.

However, the whole idea of semantic window types does hinge on having
only a few basic application "archetypes" or macro-scale designs, and
thus only a few basic kinds of window. This relies on all apps
behaving in essentially the same way UI-wise.

Using transient for docks would be a very bad idea, since many window
managers render transient windows without any handles, so it's a bit
awkward to move then around etc.

The reason they do so is because of the meaning of "transient":
cursory, unsteady etc.. which works fine if the windows indeed are
transient, but permanent windows should never be marked transient.

This is as resolved as it's ever going to be, I think.  The world just isn't a
perfect place, it seems.

I'm a bit frustrated that nobody paid any attention to my comment here:

If we really want to solve this we need to sit down and:

 - define the "application archetypes" as Microsoft calls them; 
   the control flow or work pattern for each type of app, the 
   kinds of windows found in that app type, how each window behaves
 - sync this with the spec; a window type in the spec for each 
   type in the app
 - GIMP has to conform to one of these predefined archetypes, 
   not make up whatever it wants

Anyway, agree we have to close this since nobody is doing the above. The OS X UI
guidelines even have an example, as does Microsoft in their Longhorn guidelines.

Over in GIMPland we were kind of busy getting a release ready... now would be a
good time to re-start this conversation, I think.

Optimistically re-opening.

Dave.

And I've actually been thinking about adding an archetypes section to the HIG
for the next release, so perhaps all is not quite lost :)

Calum,

Where should the discussions about this takeplace? It would be nice to have a
couple of GIMP people involved to hash out whether we're doing things wrong with
the existing window types (in which case, what would be right?), or whether the
existing types are insufficient for general needs, and that the GIMP comes in
under that. 

In which case, it'd be good to have some kind of discourse on the window types,
and specifically the window types we used during the development series and the
usability problems that we encountered around that.

Cheers,
Dave.

I would suggest bringing this up on wm-spec-list, or usability.  Not anything
more we can do here.  Please open a new bug when we have a standard to implement.