Bug 157270

Also there may (or may not) be different behavior (pop-up or pop-under) for a
user-initiated chat window from a network initiated chat window.  Again this is
an upstream decision.

Is this going to be fixed before release?  It's a surprising and non-trivial
bug.  Gaim has a clearly explained, obviously useful "Raise IM window on events"
configuraiton setting which is totally borked right now.

Upstream or not, this is a fairly serious bug for anyone who uses gaim (or other
such software).

"The side-effect of this is gaim windows have become pop-under, which is
extremely confusing to users."

Only because our implementation of DEMANDS_ATTENTION sucks.  If the users were
actually notified that there is a new window in a way that they would notice,
this wouldn't be a problem.  Putting a window on top of what the user was
attempting to work on and obscuring everything they were doing is not the only
way to provide the hint that there's a new window for them to interact with. 
(However, Havoc and Ray have worked on this; see
http://bugzilla.gnome.org/show_bug.cgi?id=120439; there may be other things we
can do as well)

"RH desktop team thinks any network initiatied pop-up event should not steal
focus from the desktop...

I'm not part of the RH desktop team (not yet at least, who knows about the
future), but I am part of the upstream Metacity work and it isn't just network
initiated events.  If any window was opened due to an event not initiated by the
user, it shouldn't be focused.  Doing so causes all sorts of problems.  I'll
cover some below with your examples.

* Chat Dialog (with potentially dangerous text input)

Looks like you already know the problem--users can get other's passwords by
sending them an IM just as they were about to type in the root password.  (IIRC,
Telsa reported having gotten Alan's password this way, though accidentally.)

* Pounce Notification Dialog (with not dangerous OK button)

It is dangerous--just in a different way.  If the user was in the middle of
typing and hits enter just as the window appears, then the dialog is dismissed
and the user has ZERO ability to determine what its contents were.  They may
have just lost some vital information ("You have an appointment in two minutes"
or "The program was unable to reach the network printer after several tries;
your job did not print (you may not want to walk up to the fourth floor and hang
around at the printer wondering where your job went)", or "I was unable to save
the file to your USB keychain (you may not want to leave to that conference just
yet until you make sure you have a copy of these important files)").

* Error Dialog (also not dangerous)

Can be quite dangerous, but again in a different way.  It shares the problems
with the pounce notification dialog above; actually it looks like one or two of
the examples I gave were actually error dialogs.  But the idea that they can be
dismissed before the user is aware that they are being alerted of a problem is
real.  It has happened to me.  In addition, error dialogs usually give the user
a number of options to choose from.  That means that if the user is typing at
the moment the dialog appears, the user can accidentally select some action that
they did not want.  One can only hope that it isn't an action that will lead to
data loss (especially since the user probably won't realize what has happened).

http://cvs.fedora.redhat.com/viewcvs/devel/libwnck/libwnck-2.10.0-add-glow-effect.patch?rev=1.2&view=log
Ray Strode wrote the flashing taskbar patch for libwnck that we're shipping in
FC4.  It does improve the situation a bit.  It would be good enough if it were
more obvious ways of attracting attention, but there aren't any trivially
implemented ways of doing so.

So I guess this bug is really:
gaim needs to somehow attract more attention to events without popping up a
window.  Flashing taskbar is helpful but insufficient.

Elijah, any objections to Bug #157271 proposed behavior?

"RH desktop team thinks any network initiatied pop-up event should not steal
focus from the desktop..."

I keep seeing this argument raised as to why all sorts of brokennesses are
happening in Metacity.  I completely agree with the statement, but _not_ with
the conclusions it seems to be leading to.  I personally use Fvwm, with
SloppyFocus and window placement set to SmartPlacement, CleverPlacement.  The
net result is that new windows are created on top, occluding as little area of
preexising windows as possible, without focus.  In most situations this means
that the new window is created out of the way in some place where, even if it is
partially occluding a window I care about, it isn't an immediate irritation.  It
is never given focus, so I will never type a password into it on mistake.

I think Luke's comment in the mailing list thread which was something to the
effect of "stacking and focus model should be decoupled" is very important here,
and I don't think that metacity Gets It.  Just because a new window has been
created on top, you don't _have_ to give it focus.  In fact, you shouldn't,
except in a very few circumstances.

Having used a capable window manager and applications which have spurious popups
(e.g., Gaim) for many years and not experienced any problems, I just don't get
what all of the fuss is about.  I think the basic assumptions of focus and
placement in metacity simply need to be revisited.

Ethan

I did not remember it as related untill Lubos Lunak mentioned the work on kde's
focus stealing prevention, but this relates to KDE as well.  specifically, we
used to see reports about gaim raising to just under the active window when KDE
first introduced focus stealing prevention.  However, the frequency of such
reports has dropped, so either kde is now doing something to allow the raise
window option to work, or users have all hit this already and moved on. 

Warren: no objections at all; we would have liked to have implemented taskbar
flashing sooner (see http://bugzilla.gnome.org/show_bug.cgi?id=120439#c35 and
http://bugzilla.gnome.org/show_bug.cgi?id=150594 for why it took a while).  Why
is flashing taskbar insufficient, though?  Has anyone actually shipped with it
yet (it hasn't been coded for libwnck, or at least committed there), in order to
test whether its enough?

Ethan: Um, metacity basically does that now.  It tries to place the new window
that is denied focus and the focused window so that the two don't
overlap--though there's a slight difference from fvwm in that if they can't be
disjoint and onscreen then we let the focused window partially occlude the new
window.  See http://bugzilla.gnome.org/show_bug.cgi?id=166524.  Also, note that
we don't have on top and focus completely coupled, even for click-to-focus.  But
I think it is worthwhile to couple them in most cases for raise-on-click; see
http://cvs.gnome.org/viewcvs/metacity/doc/how-to-get-focus-right.txt?view=markup
for the details on where we made the tradeoff and why.  Feel free to point out
any shortcomings in it (yes, there's the obvious shortcoming that metacity
doesn't support dont-raise-on-click; I have to code a bunch of other stuff
before I can convince Havoc to support that).

Luke: Is gaim attempting to raise itself via ConfigureRequests?  If so, we could
set the DEMANDS_ATTENTION hint in Metacity when we detect that, as well as
possibly (would have to think about it some) moving the window to where it is as
least obscured by the focus window as possible; currently we ignore such
requests, which may be suboptimal.

Elijah -

I understand what Metacity is doing, and I am saying that the distinction
between what it does and what Fvwm does is _important_, and one of the (MANY)
reasons we get complaints about Gaim behavior under Metacity.  My primary
suggestion is that you pop new windows up on top, not underneath (consider that
the focused window might be "maximized"); my secondary suggestion is that
Metacity starts to learn from the traditional Unix window managers, but that's a
different topic and one which I don't have the patience to beat through.

It is (and will remain, until someone can show me otherwise) my opinion that the
_reason_ which metacity needs a way to attract more attention to windows is that
it is broken, and all of this crud that's being piled on top is simply
workarounds for the fundamental brokenness which are leading to nonintuitive
behavior (such as pop-unders) due to the complexity involved.  Fixing the
underlying brokenness will lead to better solutions, faster.  It might require
giving up on the idea that Windows has a good window management policy...

Ethan

If a report from a user might help: I routinely have windows covering
the entire desktop, and therefore trying to find a non-overlapping
region to do the popup is a worthless workaround in my case.

There are other interactions too: the Firefox issue linked above, for
example.  I'll point out that gnuserv windows popped up from my emacs
now lack focus if they happen to appear from a terminal window
(i.e. something invoked $EDITOR, but the gnome-terminal application
obviously doesn't know that).

Honestly, speaking as a user: focus behavior on the Fedora desktop is
broken right now.  I can't productively use my chat client.  I'm
typing into the wrong editor windows.  It basically sucks.  And again,
speaking as a user: I don't care that it sucks for a very good reason.
It still sucks.

Stu has double checked and we use gtk_widget_show && gtk_window_deiconify &&
gdk_window_raise for "raise on events."  I'm not sure if this makes use of
ConfigureRequests or not.

Ethan, 

;-)

It looks like we fundamentally disagree on a few points, but do note that:

(1) I had considered that the focused window could be maximized (though I
think window maximization is brain-dead behavior that is due to users
coming from MS Windows' and their bad habits from from Windows' crappy
window management policy).  That's why it's only part of the solution
(blinking taskbar, possible sound, notification applet/window of some sort
as Rob suggests, change the cursor are others).  Perhaps when we are able
to make windows translucent with the new X extensions coming out then
putting the window on top will be a viable solution.  Until then, I don't
think it is (addressed below in my link to the wm-spec-list).

(2) Stating that Metacity is inherently broken without giving reasons why
doesn't help fix it at all (you gave the pop-under as an example, but I
disagree from a usability perspective--see
http://mail.gnome.org/archives/wm-spec-list/2005-May/msg00048.html).  I
agree that Metacity is buggy, but I think it's more from a not-fully-baked
perspective rather than a design perspective.  I used to think Metacity was
designed wrong too and was planning to fork, but as I got into it I found
out it was just bugs in implementing its design (and, in some cases, a lack
of any design in a certain area, such as focus policy).  It has gotten much
better in the last year or so (though it still has work to be done as
well), but of course, peoples' impressions take much longer than that to
change...

(3) I don't know why you think traditional Unix WMs have good behavior;
personally, I think they such as much as Windows' management policy--just
in different ways.  (And yes, I've predominantly used Unix over the last 10
years and have experience with several different window managers--twm,
fvwm, fvwm95, cde, vtwm, sawfish, and others I'm sure I'm forgetting, in
addition to not-so-extensive-experience with others like blackbox, fluxbok,
windowmaker, and KWin)


Andy:
Right, but non-overlapping is just one thing to do.  We need to do the window
blinking.  And for already-existing windows (see my response to Luke) that are
urgent or want attention but not due to user interaction, we need to actually
set the DEMANDS ATTENTION hint.

I didn't see the firefox issue linked above, but I'm guessing you're referring
to its lack of forwarding startup-notification information.  Yeah, known bug. 
Sorry it isn't fixed yet (but Mozilla/Firefox is too big and scary for me to
want to look at, especially since a RedHat developer volunteered to look into
it).  I don't know what gnuserv is; I think I might know what the problem is but
I'd like to make sure I actually understand the situation; could you elaborate
on what gnuserv is (X app, gtk app, kde app, other-toolkit; when is it getting
launched, etc.) and the exact behavior you are seeing?


Luke:
Yes, using gdk_window_raise means you're using ConfigureRequest events
(gdk_window_raise calls XRaiseWindow, which results in the X server sending a
ConfigureRequest event to the WM).  I think that means that bug #2 is that
Metacity should be setting DEMANDS_ATTENTION in those cases--then you don't even
have to worry about setting any urgency hint or anything.  That should be pretty
easy to do...

Elijah,

Yes, I'm sure we (where "we" is in the broad sense, being me & my ilk vs. anyone
who thinks a DE is a good idea) ;-) disagree on many points, this is why I have
not previously filed bugs, made comments, etc. on Metacity, KWin, or other DE
window management behaviors; I have entered this discussion at Luke's behest,
because he's the unfortunate soul who has to deal with support for Gaim.  ;-) 
Because of this, my comments may or may not be directly useful to you, as I am
approaching window management from a fundamentally different perspective.  It is
worth noting, however, that I never have ANY problems with window management...

Regarding (1); I basically agree that maximized windows are a bad idea, and I
almost brought that up in the context of this discussion.  I think we have come
to different conclusions in this respect, however.  In the presence of maximized
windows (I personally do maximize exactly one window, and that is my web
browser; however, it operates on a page by itself -- my editor is vertically
maximized, but has horizontal space to the sides, and even this case is
non-problematic due to the next point), popping under is not the right solution,
in my opinion.  If I have allowed fvwm to pop up a gaim window on my web browser
page, it is because I believe there might be information in that window which I
care about; if it pops under, and I don't care about it, I have to raise it,
look at it, and then re-raise my browser (or lower and raise my browser,
whatever).  This is two window-management interactions.  If I do care about it,
I have to raise it to deal with it.  This is one window-management interaction.
 In the case that it simply popped up, if I didn't care about it I need simply
to lower it; if I do care about it, I need neither to raise nor lower it.  In
either case, a net win of one operation.

If I do _not_ maximize windows, and the window manager places intelligently,
then a spurious window placed on top occludes as little of my currently focused
window as possible, and (secondarily) as little of all other windows as
possible.  It is entirely likely, in fact, that it does not occlude any part of
the currently focused window that I care about, if it occludes it at all.  I
don't know about you, but I _often_ work in  partially occluded windows, and in
fact I value this ability.  At any rate, the point is that the popping on top is
really what I want here, too.

In neither case do I want the new window to have focus, of course.  Popup
windows which steal focus are, as previously discussed, Bad Mojo.

The translucent popup idea is not a bad one; see, e.g., iChat.  I think,
however, that (like iChat notifications) ideally these popups would be extremely
simple and to-the-point; complex windows with translucency are a usability
nightmare.  However, translucent popups are currently not on the board, so I
think we agree that we can discuss this at a later date.  ;-)

Regarding (2); first off, I think the Gnome concept of "usability" is part of
the major brokenness of Metacity, which is probably where we will have a
fundamental disconnect.  I find it hard to boil this down to any particular
individual points, because it's more of a fundamental operating concept than
individual differences.  I advocate:

* Sloppy focus
* Only interaction with window decorations can raise/lower windows (that is,
clicking "in" a window will not raise it, for example)
* New windows _never_ receive focus
* Stacking, shading, iconification, dismissal, etc. are all trivially accessible
from decorations, no "task bar" involved (although optional use is fine)

There are many other points, but I think these are the most salient to this
discussion.  The bottom line is, taken in a bundle, my environment is very
different from, say, Windows or OSX, but it is also extremely consistent and
logical.  In fact, far _more_ consistent than Windows, and conducive of a work
flow very different from that encouraged by OSX.  The Metacity approach seems to
be to provide something familiar to recovering Windows users, and it seems (to
me) to lead to a multitude of inconsistencies and illogical behaviors.  (Viz.
pop-unders.)  I understand your point that these are due to bugs, but _my_ point
is that the only reason you _have_ the bugs is that you're trying for a user
interface which will be heuristic at best.

Regarding (3); yes, Unix window managers don't universally have good behavior,
and in fact window managers which can have nearly ideal behavior are often
likewise capable of utterly inconsistent and confusing behavior (Fvwm, for
example).  However, I think there is _more_ to be learned about good UI from the
various Unix paradigms that have sprung up than the _very few_ Windows/Macintosh
paradigms that exist.

At any rate, there is such a shear between what I know and expect and what DEs
such as Gnome provide that I suspect I'm not making much sense.  Let me know if
there's anything in particular I can try to clarify...

Ethan

Gnuserv is a descendent/reimplementation of emacsserver/emacsclient.  I like it
better, for obscure reasons that aren't particularly relevant here.  It is a
tiny socket app that connects to a server subprocess of my emacs, and issues a
command to open a particular file.  Emacs then spawns a new window with the
results.  I have a launcher on my panael to run this, and it pops up with the
proper focus, but if it gets launched from a console process (e.g. CVS checkin)
it does not.

Am I really to understand that the ability of an X client (that does not already
hold the focus) to pop up a new window on the screen and be sure the user
actually sees it is being deprecated?  Are you guys 100% sure you have thought
this through?  This (asynchronous screen notification) is an ancient metaphor,
and throwing it out sounds a little too radical for my tastes, especially since
the bug you are trying to fix is about *input* focus, and not screen real estate
at all...  Basically, this sounds like exactly the kind of "too clever by half"
design that got you guys in trouble over the spacial nautilus and file selector.  

Luke: The patch I posted at http://bugzilla.gnome.org/show_bug.cgi?id=305882
should make it so that metacity sets the DEMANDS_ATTENTION hint when an app
calls gdk_window_raise() on itself, so I think that should help.  We just need
to continue working on making sure that windows with DEMANDS_ATTENTION or URGENT
hint are noticeable.  :)


Ethan: Thanks for your thoughts and responses.  I think I understand where you
are coming from, and indeed I think there is a lot to learn from your
environment and others similar to it (at least, I feel so having used a number
of them myself).  I'll try to explain the Metacity viewpoint, though as we both
stated above, it does view things from somewhat of a diametrically different
angle which will probably continue to result in totally different environments.

First, just let me state that I too am a sloppy focus user and advocate.  I have
had great success in converting lots of click-to-focus users to sloppy focus,
and they generally find that they like it *much* better.  I also like windows to
only raise on modified click (e.g. alt-click) or when clicking on the window
borders--I too value being able to work with overlapping windows.  (Permit me to
go off on a tangent momentarily, though, and mention an important point in
regards to do-not-raise-on-click which has often been neglected and has caused
several implementations to be botched: I want raising to be orthogonal to ALL
other actions.  E.g. if a user clicks on the window border in order to move or
resize the window, then the window should NOT be raised.)  I have tried to show
this to others as well, and even with those same people that love sloppy focus,
they almost universally think that do-not-raise-on-click is stupid,
"inefficient", and annoying.  It took me a while to understand why anyone could
think that...

Anyway, I do believe you never have any problems with window management in your
environment.  (Note, though, that your list of four points ignores window
placement policy which will be crucial given your other points; in particular,
Metacity's placement algorithm would be very painful for you.  Of course,
Metacity's current poor window placement policy (which optimizes the wrong
things) is even bad for users of click-to-focus & raise-on-click &
new-windows-usually-get-focus, i.e. Metacity's defaults.)  Further, I believe
most of those to use your type of environment will be *much* more efficient with
"near simultaneous" use of several windows.  ("near simultaneous" is in quotes
because I can't think of a better phrase; I'm just attempting to contrast how
people work in a "heavily overlapping" window environment with how people work
in a more Windows/OSX/default-Metacity environment; see below for more on this).
 This efficiency is primarily due to window overlapping, which brings a number
of advantages--such as close targets (think Fitts's Law.)

However, this doesn't mean I think we need to change Metacity's defaults to gain
these advantages.  While your environment is consistent and I believe it
optimizes the ability to efficiently interact with multiple windows at once, I
don't think that's the right thing to optimize in a WM meant for "the common
user."  I believe most users don't even want to interact with multiple windows
rapidly (they attempt to minimize switching between apps by comparison), and
indeed this coupled with some other usability criteria influences an awful lot
of design decisions.  Off the top of my head, I think it has caused, in whole or
in part: (1) users' distasteful fondness for maximization, (2) raise-on-click by
default in most mainstream WMs/DEs/OSes (also related to the fact that most
people prefer to have things which they are interacting with to not be obscured
at all), (3) the all-in-one bloatware (er, I mean "productivity") apps, (4) the
fact that users will attempt to manually place windows so that they are all
entirely disjoint, if possible (combined with point #2, *especially* in the case
when they want to work with those windows at the same time), and perhaps even
(5) focus-new-windows-by-default in most "mainstream" WMs/DEs/OSes.  It's a
*totally* different world than one designed to optimize efficiency of switching
between many different windows.

Finally, while I definitely agree that what Metacity is aiming its defaults for
is something which requires more work to get right, I think your claim that such
an environment is heuristic at best is an overstatement.  There are definitely
some places where heuristics will be involved, but even your environment has
inherent heuristics--even if you personally don't run across them in your daily
usage patterns (e.g. keynav and sloppy focus give somewhat conflicting
constraints and invariants, leading to some inherent corner cases; granted, I
don't run into these personally and I probably wouldn't know about them had I
not spent so much time trying to handle all focus problems and edge and corner
cases in Metacity, but they are there).

Perhaps this is just a long winded way of agreeing that there are fundamentally
different viewpoints that can't be reconciled, but hopefully it helps explain at
least a little bit what the other side of the viewpoint is.  I do agree that we
need to make sure DEMANDS_ATTENTION and URGENCY are noticeable to the user, and
that placing the window on top is an option if other methods prove insufficient.
 But, I personally think it's a suboptimal option, that the other methods will
pan out, and that we need to try them first.  I realize you and Luke may not
like that method of resolving this issue, but please bear with us and let those
annoyed users know that they should direct their frustrations in this matter at
us instead of at you.


Andy: That makes no sense to me; I don't see why it would get focus correctly
when launched from the panel but not from the console (I have a guess or two,
but I'm not real sure on them).  Could you open a bug in Gnome bugzilla against
Metacity and attach a verbose debugging log?  (See
http://developer.gnome.org/projects/bugsquad/triage/product-specific.html and
scroll down to the section on metacity to see the directions for how to do so) 
Getting the command used to launch from a console as well as the contents of the
launcher file may also help.

Your other comments are misguided; it was a the KDE window manager maintainer
(Lubos Lunak) that came up with the spec for how to handle this "focus stealing
prevention" stuff and they apparently originally had the same problem (see
comment 6) but they apparently have worked around it.  We just aren't as far
yet.  (For what it's worth, though, I dislike spatilus as well (though I just
use bash/zsh anyway so my opinion really doesn't much matter))

I think what you have essentially highlighted here is that what GNOME is
currently doing well is allowing people to carry over the habits they learned in
windows to the unix world.  In windows and in MacOSX, these habits make sense
because you only have a single desktop, the visible space is the limit to your
usable space.  In metacity and other unix desktops, these habits make far less
sense, because you can segment your work in other ways.  Setting up defaults
that mimic the windows behavior discourages users from seeing beyond the limits
they had in Windows/MacOSX.

Conversely, other defaults may annoy them at first, just as sloppy focus annoys
people at first, but many (not all) come to value the difference in interface it
entails.

To me, this argues strongly for a preference, so that users can decide that the
"harm" of an unfocused top window is less than the trouble we have attempted to
describe here. 

Elijah -

First, in the absence of new points coming up, this will probably be my last
post on this topic -- because I think you understand where I'm coming from.

Yes, I agree that window placement is also a key issue, I should have included
it in my list; as I posted above, I use [SmartPlacement, CleverPlacement] in
Fvwm.  I am not very familiar with Metacity's placement rules, as I avoid Gnome
wherever possible, but I do recall that it likes to "cascade" windows, which I
dislike.

I think the bottom line is that, yes, people tend to work in a particular
paradigm (single maximized do-everything window), but that this is not because
of any inherent "goodness" or "usability" of that design; instead, it is because
that is what has been foisted upon them by the Powers that Be.  By facilitating
this type of workflow, Gnome is not doing anyone any favors.  The learning curve
may be shortened, but the net gain is minimal.  It is my opinion is that
teaching users to expect app switching and the use of multiple applications
"simultaneously", in return for the benefit of applications that do their (now
simple) jobs extremely well and cooperate well with each other, is a major win.

At any rate, as I said, I think you understand where I am coming from.  It is
obvious that you are trying to find a workable solution, and that you recognize
where the major flaws lay and where their solutions are to be found.  The only
points of disagreement are how to direct those solutions, which is a secondary
matter.  :-)

Ethan

The libwnck and metacity patches that handle urgency and flash the taskbar help
this situation, but...

I realize this is a matter of opinion, but on my massive LCD screen, animation
within the taskbar alone is not enough to visually attract attention.  Try
completely turning off gaim's sound events and work this way.

We need to think of something to improve the situation more...

Too vague and I don't care much anymore.  If anyone is annoyed by anything
specifically open a new bug about that specific behavior.