I really find the whole idea of app-centered window management complex. Your suggestion really makes sense when e.g. writing a mail in Evolution, or editing an image in GIMP - i.e, when there's a main window and child ones, or dialogs.

But with OpenOffice or Firefox, I consider my windows as completely independent documents. I may have 5 open text documents, and I really don't think of them as being the same app. Not to mention that raising all OpenOffice windows wouldn't have any effect, since I would only see the topmost one. But this would break the chronological order, meaning next Alt+Tab would not raised previously focused window - or do we need an exception? Doesn't make much sense.

The idea of grouping by app is interesting, but I don't feel like we have a clear and unique model of what an app is. So maybe we should play with window types to guess what The Right Thing is in every case? There's also the question of whether windows are fullscreen or not, which means users will manage them very differently. Just a few thoughts...

(In reply to comment #1)
> The idea of grouping by app is interesting, but I don't feel like we have a
> clear and unique model of what an app is.

I don't think that's the problem. I would say that the idea of grouping by *task* is interesting, but we don't have a good model of what a task is. We know exactly what an app is, it's just that as you said above, it often doesn't seem to make sense to group by that.

What if we made an API for applications to tell us what to group by? That sounds like it'd solve the problem.

I assume you mean, have an API for the app to say "you should group my windows together" (like Gimp) or "you shouldn't" (like OpenOffice, Firefox). But that's not right, because you can have multiple documents open in Gimp.

OTOH, if we wanted to do "when the user raises any *document* window, raise all of that application's *non-document* windows along with it", we could already do that with the window hints we have now.

(In reply to comment #0)
> One of the problems right now is that when I activate an app in either of those
> areas it seems somewhat mysterious that only one of the potentially many
> windows for an app will appear.  This means that often the wrong one will
> appear

To me, this is just proof that the entire "app-based" idea does not match your mental model of the desktop. The phrase "the wrong one will appear" doesn't make any sense unless there was a specific "right one" that you were thinking of. Raising all the application's windows as a unit isn't going to change the fact that the wrong one is going to be on top.

(In reply to comment #4)
> I assume you mean, have an API for the app to say "you should group my windows
> together" (like Gimp) or "you shouldn't" (like OpenOffice, Firefox). But that's
> not right, because you can have multiple documents open in Gimp.

I don't think the GIMP really works to have multiple *unrelated* documents open at once ... since they share the same set of toolbars, and various bits of state. Basically the entire set of GIMP windows represents a project. But designing around multi-window GIMP is probably not a great idea.

There are several levels of API around grouping mulitple windows together.

 - GTK+ has the concept of window group which are used to split modality. (gtk_window_group_add_window()) This is basically exactly the concept we want here, since if the user considers to windows unrelated, it's bizarre (and will look broken) to have a modal dialog for one window block the other windows. Firefox was, to my memory, the first app to use this API, and each toplevel firefox window is in its own window group. As I recall, GTK+ window groups aren't exported out to X in any fashion.

 - There is an X concept of window group (window_group field of WMHints structure, see XSetWMHints man page or ICCCM). How this is set by apps and how it is interpreted by window managers is a bit unexplored territory, though it's been there since the early days of X11. There is gdk_window_set_group() for this - which some apps use in a scattershot fashion. (Google codesearch seems to mostly show people splitting windows out into their own window group, presumably to deal with window managers that were grouping windows too strongly.)

It might just work to hook GTK+ window groups up to X window groups by default.
 
> OTOH, if we wanted to do "when the user raises any *document* window, raise all
> of that application's *non-document* windows along with it", we could already
> do that with the window hints we have now.

The idea isn't really restricted to dialogs, or to GIMP tool palettes - I think it would help to raise Evolution and open composer windows together. The basic thinking, I see it as:

 - If you have full-screen maximized windows, then you don't really care what gets raised behind the window you select - it's irrelevant.

 - If you don't have full-screen maximized windows, then if alt-Tab fails (doens't guess right), there's a good chance that you'll be able to see the window you really wanted and click on it.

The only real downside is if you have some configuration like:

 Firefox          Composer window
 window with
 data

 Main evolution
 window

And you want to switch between firefox and the composer window and leave the main evo window buried. Maybe if we get the side-by-side snapping gesture that would be a signal that the two windows are closely related and should be pulled out of application-based heurisitics.

(In reply to comment #6)
> I don't think the GIMP really works to have multiple *unrelated* documents
> open at once

I've never done it, but then, I don't think I've ever had two unrelated OpenOffice documents open at the same time either, because I don't use either Gimp or OpenOffice very much. But I assumed that people who use gimp every day would sometimes have unrelated documents open.

>  - If you have full-screen maximized windows, then you don't really care what
> gets raised behind the window you select - it's irrelevant.

Not entirely true; it affects what window will be selected when you close/minimize the front window.

>  - If you don't have full-screen maximized windows, then if alt-Tab fails
> (doens't guess right), there's a good chance that you'll be able to see the
> window you really wanted and click on it.

It would be nicer to just make alt-tab not fail in the first place.

I think this behavior has been implemented, no?

We do it in some circumstances, but not others. (Eg, if you select a specific window from the Alt+Tab dialog, we only raise that one window.)

(Don't mark bugs NEEDINFO when you want information from developers. NEEDINFO basically means "hide this bug from developers until the reporter responds".)

(In reply to comment #9)
> We do it in some circumstances, but not others. (Eg, if you select a specific
> window from the Alt+Tab dialog, we only raise that one window.)

Exactly in what circumstances do raise all windows? I've been hit by this behavior and am still not sure what I do wrong (while I expect it to bring only a specific window).

(In reply to Dan Winship from comment #9)
> We do it in some circumstances, but not others. (Eg, if you select a
> specific window from the Alt+Tab dialog, we only raise that one window.)

Right, but IMHO raising a single window when selecting one window makes sense to me (why else pick a particular window?), independent from whether we stick with the selecting-an-app-brings-up-all-windows behavior.

So I don't see any value in keeping this open, future discussions about behavior changes should happen on gitlab ...