From: Luke S. <lsc...@us...> - 2005-05-11 21:46:59
|
Warren asked that we, as gaim, outline how we expect window management to be handled, focusing on new windows & urgency, as per the long discussions in #gaim over the last 2 or 3 days, in light of metacity's move from causing gaim to always steal focus to having windows pop under. I wrote up the following as an inital draft, please comment. I do not expect everyone will entirely agree, and I certainly am not attempting to cover every case, whole specs have been written on this sort of thing. I just want a basic idea of what we are looking for, what other window managers are providing for us that metacity currently is doing in a substandard (compared to other linux window managers) way. Naturally, the microsoft solution is not necessarily right or wrong, but is, rather, utterly irrelevent to this discussion. luke * window focus should only be transfered from one window to another by the direct action of the user. * The WM does not know when a new window is user initiated or not. * The application that requests the new window does know * In the case of new application launch, this yields a useful result: you can start several things in the background (or on login) and not have your focus jerked around as they start. * new windows should be created at the top level unless specifically requested otherwise by the starting application. Placement should reflect some overall policy of the WM, preferably a policy that the user understands and can predict. Remembering previous placement is a reasonable, but not required, part of said policy. * Applications which currently have focus should be able to determine if a window said application has created gets focus or not. It should be able to do so without changing the level at which the window is created. * Applications which do not have focus should not be able to pull focus from another application in a way that the user cannot disable or modify. Changes to individual applications at a source code level should not be necessary for this behavior. |
From: Michael R H. <bu...@su...> - 2005-05-12 17:57:42
|
On Wed, 2005-05-11 at 17:45 -0400, Luke Schierer wrote: > Warren asked that we, as gaim, outline how we expect window > management to be handled, focusing on new windows & urgency, as per > the long discussions in #gaim over the last 2 or 3 days, in light of > metacity's move from causing gaim to always steal focus to having > windows pop under. >=20 > I wrote up the following as an inital draft, please comment. [I realize this is slightly OT, and not quite the comment you were looking for] Just curious, why not simply make gaim set the "demands attention" hint which both KDE/GNOME/freedesktop are committed to supporting (as opposed to the "urgent" hint which they aren't)? Right now libwnck bolds the title of windows that set that hint. I'm all in favor of gaim doing the best it can be, regardless of the DE (or lack thereof) the user chooses to run it under, but this seems like one area where simply adhering to the spec and leaving the matter up to the DE designers is a win for users in terms of overall consistency. Apologies if the "demands attention" hint has been discussed to death on IRC, but I don't live in the channel. mike --=20 Michael R Head <bu...@su...> GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) |
From: Luke S. <lsc...@us...> - 2005-05-12 18:06:45
|
On Thu, May 12, 2005 at 01:57:02PM -0400, Michael R Head wrote: > On Wed, 2005-05-11 at 17:45 -0400, Luke Schierer wrote: > > Warren asked that we, as gaim, outline how we expect window > > management to be handled, focusing on new windows & urgency, as per > > the long discussions in #gaim over the last 2 or 3 days, in light of > > metacity's move from causing gaim to always steal focus to having > > windows pop under. > > > > I wrote up the following as an inital draft, please comment. > > [I realize this is slightly OT, and not quite the comment you were > looking for] > > Just curious, why not simply make gaim set the "demands attention" hint > which both KDE/GNOME/freedesktop are committed to supporting (as opposed > to the "urgent" hint which they aren't)? Right now libwnck bolds the > title of windows that set that hint. > > I'm all in favor of gaim doing the best it can be, regardless of the DE > (or lack thereof) the user chooses to run it under, but this seems like > one area where simply adhering to the spec and leaving the matter up to > the DE designers is a win for users in terms of overall consistency. By implementing "urgent" we are implementing the ICCCM spec which has been a spec for 13 years (or there abouts). the "demands attention" stuff was created by gnome and kde because they fail to understand the ICCCM spec and would rather do their own thing and write a new spec than take the time to look at how other projects have implemented the existing spec and follow the existing spec. Several of us are considerably less than pleased to see this development, and less than thrilled with the idea of encouraging it (by giving it greater acceptance). Still, Etan expressed some interest in eventually adding "demands attention" support much like we have urgency support, in the message notification plugin. > > Apologies if the "demands attention" hint has been discussed to death on > IRC, but I don't live in the channel. that's fine, this email was written in an attempt to consolidate those discussions in a form that I can present to redhat & gnome. luke > > mike > -- > Michael R Head <bu...@su...> > GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) |
From: Etan R. <de...@ed...> - 2005-05-12 18:44:42
|
On Thu, 12 May 2005, Luke Schierer wrote: I have comments to make on Luke's original email but they are going to take more time than I have at the moment so this email is going to come first, responses inline. > > [I realize this is slightly OT, and not quite the comment you were > > looking for] > > > > Just curious, why not simply make gaim set the "demands attention" hint > > which both KDE/GNOME/freedesktop are committed to supporting (as opposed > > to the "urgent" hint which they aren't)? Right now libwnck bolds the > > title of windows that set that hint. > > > > I'm all in favor of gaim doing the best it can be, regardless of the DE > > (or lack thereof) the user chooses to run it under, but this seems like > > one area where simply adhering to the spec and leaving the matter up to > > the DE designers is a win for users in terms of overall consistency. > > By implementing "urgent" we are implementing the ICCCM spec which has > been a spec for 13 years (or there abouts). the "demands attention" > stuff was created by gnome and kde because they fail to understand > the ICCCM spec and would rather do their own thing and write a new > spec than take the time to look at how other projects have > implemented the existing spec and follow the existing spec. Several > of us are considerably less than pleased to see this development, and > less than thrilled with the idea of encouraging it (by giving it > greater acceptance). Still, Etan expressed some interest in > eventually adding "demands attention" support much like we have > urgency support, in the message notification plugin. The point here, as Luke has pointed out, is not that gaim is unwilling to implement _NET_WM_STATE_DEMANDS_ATTENTION but rather that the libwnck people have decided that the Urgency hint is not worth their time to implement and that _NET_WM_STATE_DEMANDS_ATTENTION is all that they care about. It is this decision that I personally find the most obnoxious when coupled with the 'demand' that we support _NET_WM_STATE_DEMANDS_ATTENTION. I had originally objected more strongly to the mere existance of _NET_WM_STATE_DEMANDS_ATTENTION but having thought about it further I can see the use for a flag that the window manager can set on a window to indicate that in doing its job of managing windows this window was not given the attention it might have wanted and therefore tasklists/pagers/the application itself/etc. might want to be aware of that. Given this I think it would probably make more sense for _NET_WM_STATE_DEMANDS_ATTENTION to be a wm settable property only (though that's a discussion for the freedesktop people). Back to the point at hand though, the issue at the core here is that libwnck does not support the ICCCM required Urgency hint. When they do gaim will bold/flash/whatever they choose to do with it correctly. > luke > > > > > mike > > -- > > Michael R Head <bu...@su...> > > GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) -Etan P.S. I'm planning to look into getting libwnck to listen for changes in Urgency in the same manner as it looks for changes in _NET_WM_STATE_DEMANDS_ATTENTION, more as a proof of concept than anything I expect to be acceptable to upstream, but it will at least be a start. I'll send mail if/when I get to that. |
From: Michael R H. <bu...@su...> - 2005-05-12 19:29:07
|
On Thu, 2005-05-12 at 14:44 -0400, Etan Reisner wrote: > On Thu, 12 May 2005, Luke Schierer wrote: > The point here, as Luke has pointed out, is not that gaim is unwilling > to implement _NET_WM_STATE_DEMANDS_ATTENTION but rather that the libwnck > people have decided that the Urgency hint is not worth their time to > implement and that _NET_WM_STATE_DEMANDS_ATTENTION is all that they care > about. It is this decision that I personally find the most obnoxious > when coupled with the 'demand' that we support > _NET_WM_STATE_DEMANDS_ATTENTION. hehe ;-) Of course you're right. And it is obnoxious, but the freedesktop spec is what it is, and GNOME and KDE are what they are. If that's the way the wind is blowing, why not blow along with it? What use is supporting a spec that nobody else (or few others) supports, and inversely, what use is not supporting a spec that everyone (or most others) supports? I've applied the metacity and wnck patches that support the urgency hint by blinking the taskbar, and it's definitely nice to have: http://www.people.virginia.edu/~mse5q/blink/ And for the record, I asked debian to apply it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D291079 Just for everyone that hasn't read "their side" of the story on Urgency vs. Demands Attention, here's a link to the their explanation of why they felt they needed to supplant a long-existing spec that already seems to do what they want: http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html Here's what they say about Urgency: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#URGENCY =20 Urgency =20 Windows expecting immediate user action should indicate this using the urgency bit in the WM_HINTS.flags property, as defined in the ICCCM.=20 =20 =20 And demands attention: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2507241 _NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or with the window happened. For example, it may be set by the Window Manager if the window requested activation but the Window Manager refused it, or the application may set it if it finished some work. This state may be set by both the Client and the Window Manager. It should be unset by the Window Manager when it decides the window got the required attention (usually, that it got activated). I don't completely buy their argument, but like I said, the spec is what it is, and it's where the window managers are heading, IMHO. Plus, Demands Attention does seem more in line with what gaim wants to do (according, of course, to the freedesktop wm-spec). Over and out, mike --=20 Michael R Head <bu...@su...> GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) |
From: Luke S. <lsc...@us...> - 2005-05-12 19:47:38
|
On Thu, May 12, 2005 at 03:28:24PM -0400, Michael R Head wrote: > On Thu, 2005-05-12 at 14:44 -0400, Etan Reisner wrote: > > On Thu, 12 May 2005, Luke Schierer wrote: > > The point here, as Luke has pointed out, is not that gaim is unwilling > > to implement _NET_WM_STATE_DEMANDS_ATTENTION but rather that the libwnck > > people have decided that the Urgency hint is not worth their time to > > implement and that _NET_WM_STATE_DEMANDS_ATTENTION is all that they care > > about. It is this decision that I personally find the most obnoxious > > when coupled with the 'demand' that we support > > _NET_WM_STATE_DEMANDS_ATTENTION. > > hehe ;-) > > Of course you're right. And it is obnoxious, but the freedesktop spec is > what it is, and GNOME and KDE are what they are. If that's the way the > wind is blowing, why not blow along with it? What use is supporting a > spec that nobody else (or few others) supports, and inversely, what use > is not supporting a spec that everyone (or most others) supports? fvwm2 and xfce are not small window managers, both are fairly popular. both support urgency. Several others do also, I have never bothered to try to keep a full list of who does and who does not. do *either* support _NET_WM_STATE_DEMANDS_ATTENTION? I'm pretty sure fvwm2 doesn't. In point of fact, do anyone *besides* kde and gnome support it? They are not the whole of the unix world remember, just the bulk of the desktop environment subset. luke > > Over and out, > mike > -- > Michael R Head <bu...@su...> > GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) |
From: Brian J. T. <bj...@co...> - 2005-05-12 20:36:37
|
Luke Schierer wrote: >On Thu, May 12, 2005 at 03:28:24PM -0400, Michael R Head wrote: > > >>On Thu, 2005-05-12 at 14:44 -0400, Etan Reisner wrote: >> >> >>>On Thu, 12 May 2005, Luke Schierer wrote: >>>The point here, as Luke has pointed out, is not that gaim is unwilling >>>to implement _NET_WM_STATE_DEMANDS_ATTENTION but rather that the libwnck >>>people have decided that the Urgency hint is not worth their time to >>>implement and that _NET_WM_STATE_DEMANDS_ATTENTION is all that they care >>>about. It is this decision that I personally find the most obnoxious >>>when coupled with the 'demand' that we support >>>_NET_WM_STATE_DEMANDS_ATTENTION. >>> >>> >>hehe ;-) >> >>Of course you're right. And it is obnoxious, but the freedesktop spec is >>what it is, and GNOME and KDE are what they are. If that's the way the >>wind is blowing, why not blow along with it? What use is supporting a >>spec that nobody else (or few others) supports, and inversely, what use >>is not supporting a spec that everyone (or most others) supports? >> >> > >fvwm2 and xfce are not small window managers, both are fairly >popular. both support urgency. Several others do also, I have never >bothered to try to keep a full list of who does and who does not. do >*either* support _NET_WM_STATE_DEMANDS_ATTENTION? I'm pretty sure fvwm2 >doesn't. > > xfwm4 (xfce's WM) does support _DEMANDS_ATTENTION, but our taskbar currently doesn't do anything with it. I'm actually surprised to learn here that gnome and KDE both don't support normal ICCCM urgency (xfce has for the better part of a year now). >In point of fact, do anyone *besides* kde and gnome support it? They >are not the whole of the unix world remember, just the bulk of the >desktop environment subset. > > I don't believe anyone else does support it, but since the only place this discussion matters is the desktop world (personally I think it applies equally to full DEs as well as WMs), it's still significant that the two majority desktop shareholders do support it. I thought this part of the post[1] Mike linked was interesting, and, IMHO, made sense: "I used a _NET_WM_STATE_DEMANDS_ATTENTION property. I first thought about using the Urgency hint from ICCCM, but I eventually decided not to. I wasn't sure if it would be ok to set this hint from the WM, and moreover the meaning of this state is actually somewhat opposite to being urgent." If you look at it that way, a window that actually is setting the urgent hint, *should* be activated immediately. A window that is merely "demanding attention" shouldn't. Then again, you can make the argument that focus-stealing in all cases is bad (which I might agree with), which means the urgent hint is useless, so you might as well just repurpose the urgent hint. -brian [1] http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html |
From: Etan R. <de...@ed...> - 2005-05-12 20:35:24
|
On Thu, 12 May 2005, Michael R Head wrote: > I've applied the metacity and wnck patches that support the urgency hint > by blinking the taskbar, and it's definitely nice to have: > http://www.people.virginia.edu/~mse5q/blink/ > And for the record, I asked debian to apply it: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291079 Thanks for the link to those patches, I'd thought I rememberd them existing but then figured that I must have been mistaken when I couldn't find them and only found the demands attention blinking patches in the various bugtrackers. > Just for everyone that hasn't read "their side" of the story on Urgency > vs. Demands Attention, here's a link to the their explanation of why > they felt they needed to supplant a long-existing spec that already > seems to do what they want: > http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html The one paragraph in that email that I see about Urgency I mostly agree with. But note that it's specifically referring about the case where the wm decides to not focus/show/raise/etc. the window and as such needs to mark the window as needing attention, and not the case where the client wants to draw attention to the window. Which if you want to reserve Urgency for the client should be the sole purpose of _DEMANDS_ATTENTION. > Here's what they say about Urgency: > http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#URGENCY > > Urgency > > Windows expecting immediate user action should indicate this > using the urgency bit in the WM_HINTS.flags property, as defined > in the ICCCM. For comparison the ICCCM states that: The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user. I would argue that timely and immediate aren't exactly the same thing. One can either understand the wm-spec text as indicating a change in the meaning of the hint (which I don't particularly think is a good idea or a good change) or as indicating a misunderstanding/misreading of the immediacy of 'timely'. But this again requires the intervention of the wm-spec people and perhaps this should be brought up on wm-spec list for discussion. > And demands attention: > http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2507241 > > _NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or > with the window happened. For example, it may be set by the > Window Manager if the window requested activation but the Window > Manager refused it, or the application may set it if it finished > some work. This state may be set by both the Client and the > Window Manager. It should be unset by the Window Manager when it > decides the window got the required attention (usually, that it > got activated). > > I don't completely buy their argument, but like I said, the spec is what > it is, and it's where the window managers are heading, IMHO. Plus, > Demands Attention does seem more in line with what gaim wants to do > (according, of course, to the freedesktop wm-spec). I agree completely that according to the reigning Gnome/KDE view of things gaim should by all rights be setting _NET_WM_STATE_DEMANDS_ATTENTION, I don't however agree that gaim is doing anything wrong, nor do I necessarily agree that the Gnome/KDE view is correct. All gaim wants to do is notify the user that their IM windows needs paying attention to, how exactly it goes about doing this isn't much a concern of ours. The problem here is that we have a way to do it that is being ignored and we are being told to go do something else. > Over and out, > mike -Etan |
From: Ethan B. <ebl...@cs...> - 2005-05-12 21:07:27
|
Michael R Head spake unto us the following wisdom: > Of course you're right. And it is obnoxious, but the freedesktop spec is > what it is, and GNOME and KDE are what they are. If that's the way the > wind is blowing, why not blow along with it? What use is supporting a > spec that nobody else (or few others) supports, and inversely, what use > is not supporting a spec that everyone (or most others) supports? Of course, he is right. And, in fact, ICCCM (which the Gnome people, at least, are ignoring -- although I understand that KDE supports URGENCY) is THE spec for window management. Some fly-by-night made-up fd.o post- ing of a hack to fix the focus policy they screwed up themselves is NOT. Those "few others" and "nobody else" you so cavalierly threw out are the window managers which _do_ support the standards; and, not surprisingly, the ones you'll find people with staggering amounts of clue using. (Before anybody cries, yes, there are also clueful gnome and kde users =2E.. although I don't understand how.) Gnome and KDE are, in fact, the newcomers to window and desktop management, and the fact that they're still catching up to a 1993 standard is testament to this. > Urgency > =20 > Windows expecting immediate user action should indicate this > using the urgency bit in the WM_HINTS.flags property, as defined > in the ICCCM.=20 For the record, the ICCCM actually says that the UrgencyHint "indicates that the client deems the window contents to be urgent, requiring the timely response of the user. The window manager must make some effort to draw the user's attention to this window while this flag is set." This seems to be 100% appropriate for our (the Gaim) use case. > _NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or > with the window happened. For example, it may be set by the > Window Manager if the window requested activation but the Window > Manager refused it, or the application may set it if it finished > some work. This state may be set by both the Client and the > Window Manager. It should be unset by the Window Manager when it > decides the window got the required attention (usually, that it > got activated). This window-manager-managed bit is the only thing which I see about DEMANDS_ATTENTION that is at all interesting. Given that there _are_ applications which try to do foolish things such as focus themselves, and that the Urgency hint is clearly defined to be client-controlled, having an equivalent hint which is manipulable by the window manager is not unreasonable. However, this is not necessary to reflect the Gaim sementics -- which is, we have a window which is known _to the client_ to need attention in a "timely" fashion. > I don't completely buy their argument, but like I said, the spec is what > it is, and it's where the window managers are heading, IMHO. Plus, > Demands Attention does seem more in line with what gaim wants to do > (according, of course, to the freedesktop wm-spec). "Window managers" are not heading that direction, because this is a response to poor window management. Window managers don't need this hack. Desktop environments which lack sufficient window management seem to need this hack. And, regarding specs ... THEY WROTE THE SPEC. I could write a spec stating that DEMANDS_ATTENTION is not to be used under any circumstances ... would you cite that, too? Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Michael R H. <bu...@su...> - 2005-05-12 20:24:17
|
On Thu, 2005-05-12 at 15:46 -0400, Luke Schierer wrote: > fvwm2 and xfce are not small window managers, both are fairly > popular. both support urgency. Several others do also, I have never > bothered to try to keep a full list of who does and who does not. do > *either* support _NET_WM_STATE_DEMANDS_ATTENTION? I'm pretty sure fvwm2 > doesn't. >=20 > In point of fact, do anyone *besides* kde and gnome support it? They > are not the whole of the unix world remember, just the bulk of the > desktop environment subset. You're right, I do come at this debate with DE-centric view of the X landscape (despite having used wmaker for many years).=20 Still, I think there is merit in supporting specs supported by both GNOME and KDE. These are the default environments most new (and old!) linux users will be presented with. There are an awful lot of development resources being poured into both of these projects, and they get a lot of eyes and mouse clicks. Put another way, should I really have to switch to fvwm2 for nicely integrated notification to work? Put yet another way, why spend a lot of time coding around the admitted deficit in the current version of metacity's window managment, when they support a way of notifying the user?=20 Compliance of the entire fd.o wm-spec is tracked at the bottom of this page:=20 http://www.freedesktop.org/wiki/Standards_2fwm_2dspec I checked the source file linked for fvwm. It currently does not support "demands attention". But that's really besides the point. Does it have to be an xor situation? Can't both be supported side-by-side? I wasn't intending to waste everyone's time with the old DE-centric vs. WM-centric X debate, so let me rephrase my point:=20 Is it easier to add code that sets _NET_WM_STATE_DEMANDS_ATTENTION or to try and get GNOME and KDE to properly support the Urgent hint? =20 And I also understand that your original post on this subject was about how gaim should be acting. I guess my response to that is, why not punt to Metacity since they're the ones causing the problem?=20 > luke --=20 Michael R Head <bu...@su...> GPG: http://www.suppressingfire.org/~burner/gpg.key.txt (ID 23A02B1F) |
From: Etan R. <de...@ed...> - 2005-05-12 20:42:23
|
On Thu, 12 May 2005, Michael R Head wrote: > Still, I think there is merit in supporting specs supported by both > GNOME and KDE. These are the default environments most new (and old!) > linux users will be presented with. There are an awful lot of > development resources being poured into both of these projects, and they > get a lot of eyes and mouse clicks. These projects do have a tremendous amount of development resource poured into them, and as such as trivial a patch as making Urgent bold the taskbar in the same way that DEMANDS_ATTENTION does would seem to be something that should have gotten done already. The fact that this is not the case is my main concern here. > Put another way, should I really have to switch to fvwm2 for nicely > integrated notification to work? Put yet another way, why spend a lot of > time coding around the admitted deficit in the current version of > metacity's window managment, when they support a way of notifying the > user? We aren't coding around anything, and in fact if we chose to support DEMANDS_ATTENTION just so that metacity/libwnck would start working we would in fact have started coding around the metacity/libwnck deficit. > Compliance of the entire fd.o wm-spec is tracked at the bottom of this > page: > http://www.freedesktop.org/wiki/Standards_2fwm_2dspec > > I checked the source file linked for fvwm. It currently does not support > "demands attention". > > But that's really besides the point. Does it have to be an xor > situation? Can't both be supported side-by-side? A wm most certainly can (and in fact should) support both, that's the heart of the issue here, metacity/libwnck *is not* supporting both. I have no problems making gaim support both, I have problems doing so before the main offenders calling for us to support both fail to do so themselves. (Especially when they are projects significantly larger than the one I'm working on, with many times the resources available to them.) > I wasn't intending to waste everyone's time with the old DE-centric vs. > WM-centric X debate, so let me rephrase my point: > > Is it easier to add code that sets > _NET_WM_STATE_DEMANDS_ATTENTION or to try and get GNOME and KDE > to properly support the Urgent hint? This isn't about ease of solution it's about getting everyone to do the right thing. If I was convinced that metacity/libwnck was going to solve their end of the problem in the immediate future I would almost certainly begin 'fixing' gaim for our side of the issue. -Etan |
From: Ethan B. <ebl...@cs...> - 2005-05-12 20:30:18
|
Luke Schierer spake unto us the following wisdom: > * window focus should only be transfered from one window to another by > the direct action of the user. > * The WM does not know when a new window is user initiated or not. > * The application that requests the new window does know > * In the case of new application launch, this yields a useful > result: you can start several things in the background (or > on login) and not have your focus jerked around as they > start. I agree with the above. I also have some sympathy for the fd.o idea (at least, when I heard it, it was attributed to them) that a window which was NOT requested by the user should have some sort of indication of this status; e.g. a new Gaim window triggered by a spurious message. However, having _not_ had this for the past decade of using X11, I have never actually needed it in my own environment, because my window man- ager obeys the above principles. > * new windows should be created at the top level unless specifically > requested otherwise by the starting application. Placement should > reflect some overall policy of the WM, preferably a policy that the > user understands and can predict. Remembering previous placement is > a reasonable, but not required, part of said policy. I agree here, as well. Window stacking and focus policy should be at least somewhat decoupled. In my own environment, they are totally decoupled. > * Applications which currently have focus should be able to determine > if a window said application has created gets focus or not. It > should be able to do so without changing the level at which the > window is created. I sort of agree here; a hint to this effect would be reasonable. Hints are, however, just that -- and I would ignore this one, myself. > * Applications which do not have focus should not be able to pull > focus from another application in a way that the user cannot disable > or modify. Changes to individual applications at a source code > level should not be necessary for this behavior. This is absolutely the point I would stick on. Focus stealing is NOT acceptable in ANY fashion. New windows should not steal focus, and applications should not be allowed to steal focus from other applica- tions manually. I know it's a bold thought in 2005, but window managers should do the window management. (And -- listen up, gnome people -- they should actually DO the management.) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Peter L. <spa...@si...> - 2005-05-12 21:18:26
|
Hi! Luke, I couldn't agree more. As a basic set of requirements, you've done well to list them. As far as my own thoughts, please read what Ethan said in reply. He beat me to the points I wanted to make. Regards, Pete. Luke Schierer wrote: <snip> > * window focus should only be transfered from one window to another by the direct action of the user. > * The WM does not know when a new window is user initiated or not. > * The application that requests the new window does know > * In the case of new application launch, this yields a useful result: you can start several things > in the background (or on login) and not have your focus jerked around as they start. > * new windows should be created at the top level unless specifically requested otherwise by the starting > application. Placement should reflect some overall policy of the WM, preferably a policy that the > user understands and can predict. Remembering previous placement is a reasonable, but not required, > part of said policy. > * Applications which currently have focus should be able to determine if a window said application has > created gets focus or not. It should be able to do so without changing the level at which the window > is created. > * Applications which do not have focus should not be able to pull focus from another application in a > way that the user cannot disable or modify. Changes to individual applications at a source code > level should not be necessary for this behavior. |
From: Warren T. <wt...@re...> - 2005-05-16 07:26:28
|
Is this all? Does anyone want to summarize the gaim team position on this issue before sending, or do you want to just send the entire thread? Warren Togami wt...@re... |
From: Luke S. <lsc...@us...> - 2005-05-16 13:02:15
|
On Sun, May 15, 2005 at 09:26:19PM -1000, Warren Togami wrote: > Is this all? Does anyone want to summarize the gaim team position on > this issue before sending, or do you want to just send the entire thread? > > Warren Togami > wt...@re... I am sorry, I was out of town this weekend, and was not able to follow up on this thread. I was also expecting (hoping for) a reply from Etan & Sean. Luke |
From: Sean E. <sea...@gm...> - 2005-05-16 16:44:06
|
On 5/16/05, Luke Schierer <lsc...@us...> wrote: > I was also expecting (hoping for) a reply > from Etan & Sean. I didn't reply just because I pretty much agree 100%. I'm struggling to think of something to add: * If window positions are remembered, and multiple windows are created with the same Role, they should be "cascaded," not placed at the same location. * Transient alert dialogs should not be given focus, be placed at the top-level (as specified above), but they should not be always on top until closed, such that you never lose one behind other applications. I don't really care about NEEDS_ATTENTION and URGENT and whether they're duplicating the same features or why NEEDS_ATTENTION was deemed necessary or whatnot, but I'd like to see someone in "the know" explain the two of them and when each should be used. -s. |
From: Etan R. <de...@ed...> - 2005-05-16 21:21:18
|
On Wed, 11 May 2005, Luke Schierer wrote: > * window focus should only be transfered from one window to another by the direct action of the user. > * The WM does not know when a new window is user initiated or not. > * The application that requests the new window does know > * In the case of new application launch, this yields a useful result: you can start several things > in the background (or on login) and not have your focus jerked around as they start. I agree. If, however, people feel that there should be a way for an application to request focus on mapping that's fine. Such a specification should be written such that it is an opt-in concept, not an opt-out one (or one that requires all applications to follow for it to work). For example, given our experience with metacity (and the focus stealing prevention spec) the fact that gaim does not do anything to accomodate the spec used to cause all of our windows to be on top and focused, and now causes all our windows to be popped up underneath other windows. This is really an unacceptable way to design a new specification, especially when dealing with something as old as X and which has legacy applications which one wants to continue to have act correctly. If the purpose of this spec is to only make windows that really want focus on map to get it than require that *those applications* set the property to some agreed upon value or set of values, and that anything which does not is going to be treated in a wm consistent and non-annoying fashion (i.e. not given focus on map, but also not hidden and therefore requiring further specification to function usefully). > * new windows should be created at the top level unless specifically requested otherwise by the starting > application. Placement should reflect some overall policy of the WM, preferably a policy that the > user understands and can predict. Remembering previous placement is a reasonable, but not required, > part of said policy. I mostly agree with this, however I can certainly imagine the case where a wm which supports absolute Z-levels would want to group windows by class, instance, or other criteria and as such I can certainly accept the idea that a wm would have a policy which doesn't put windows on the top level at all times. When the wm put a window in a non-obvious place it should then indicate this to the user somehow. (This by the way is where I think the _NET_WM_STATE_DEMANDS_ATTENTION stuff has merit, to be the property of a window that the wm sets when, according to policy, a window was not given the visibility it, or the user, might otherwise have been expecting.) > * Applications which currently have focus should be able to determine if a window said application has > created gets focus or not. It should be able to do so without changing the level at which the window > is created. I agree 100%. Since I do not know of any currently existing method to have an application indicate this to the wm there is certainly room for a specification to clarify how this should be done. I do not however think that _NET_WM_USER_TIME in it's current overloaded and (to my mind) poorly designed state is viable for this. I would suggest something along the lines of a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property. > * Applications which do not have focus should not be able to pull focus from another application in a > way that the user cannot disable or modify. Changes to individual applications at a source code > level should not be necessary for this behavior. I likewise agree 100%. I think that this is again a place where the _NET_WM_STATE_DEMANDS_ATTENTION property has merit, it should be used to indicate that a window was created or requested focus and was not given it to comply with the window managers policies on focus and as such attention should be paid to it shortly. (As an example, my window manager has a small activity notification bar which appears at the top left of the screen when a window is created on a desktop other than the one you are currently viewing. It also uses this activity notification bar to indicate when a window has set the Urgency hint. -Etan |
From: Luke S. <lsc...@us...> - 2005-05-17 00:49:32
|
I have updated my master copy of these ideas at http://gaim.sf.net/luke/windowstuff to reflect the ideas I have seen presented in this thread. If no further objections, clarifications, or enhancements are made by tomorrow morning (EDT), I will pass this on to Warren as per his request (which started this thread). luke On Mon, May 16, 2005 at 02:46:37PM -0400, Etan Reisner wrote: > On Wed, 11 May 2005, Luke Schierer wrote: > > > * window focus should only be transfered from one window to another by the direct action of the user. > > * The WM does not know when a new window is user initiated or not. > > * The application that requests the new window does know > > * In the case of new application launch, this yields a useful result: you can start several things > > in the background (or on login) and not have your focus jerked around as they start. > I agree. If, however, people feel that there should be a way for an > application to request focus on mapping that's fine. Such a > specification should be written such that it is an opt-in concept, not > an opt-out one (or one that requires all applications to follow for it > to work). For example, given our experience with metacity (and the focus > stealing prevention spec) the fact that gaim does not do anything to > accomodate the spec used to cause all of our windows to be on top and > focused, and now causes all our windows to be popped up underneath other > windows. > This is really an unacceptable way to design a new specification, > especially when dealing with something as old as X and which has legacy > applications which one wants to continue to have act correctly. If the > purpose of this spec is to only make windows that really want focus on > map to get it than require that *those applications* set the property > to some agreed upon value or set of values, and that anything which > does not is going to be treated in a wm consistent and non-annoying > fashion (i.e. not given focus on map, but also not hidden and therefore > requiring further specification to function usefully). > > > * new windows should be created at the top level unless specifically requested otherwise by the starting > > application. Placement should reflect some overall policy of the WM, preferably a policy that the > > user understands and can predict. Remembering previous placement is a reasonable, but not required, > > part of said policy. > I mostly agree with this, however I can certainly imagine the case where > a wm which supports absolute Z-levels would want to group windows by > class, instance, or other criteria and as such I can certainly accept > the idea that a wm would have a policy which doesn't put windows on the > top level at all times. When the wm put a window in a non-obvious place > it should then indicate this to the user somehow. (This by the way is > where I think the _NET_WM_STATE_DEMANDS_ATTENTION stuff has merit, to be > the property of a window that the wm sets when, according to policy, a > window was not given the visibility it, or the user, might otherwise > have been expecting.) > > > * Applications which currently have focus should be able to determine if a window said application has > > created gets focus or not. It should be able to do so without changing the level at which the window > > is created. > I agree 100%. Since I do not know of any currently existing method to > have an application indicate this to the wm there is certainly room for > a specification to clarify how this should be done. I do not however > think that _NET_WM_USER_TIME in it's current overloaded and (to my mind) > poorly designed state is viable for this. I would suggest something > along the lines of a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property. > > > * Applications which do not have focus should not be able to pull focus from another application in a > > way that the user cannot disable or modify. Changes to individual applications at a source code > > level should not be necessary for this behavior. > I likewise agree 100%. I think that this is again a place where the > _NET_WM_STATE_DEMANDS_ATTENTION property has merit, it should be used to > indicate that a window was created or requested focus and was not given > it to comply with the window managers policies on focus and as such > attention should be paid to it shortly. (As an example, my window > manager has a small activity notification bar which appears at the top > left of the screen when a window is created on a desktop other than the > one you are currently viewing. It also uses this activity notification > bar to indicate when a window has set the Urgency hint. > > -Etan > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
From: Gary K. <gr...@re...> - 2005-05-16 22:59:10
|
On Wed, 2005-05-11 at 17:45 -0400, Luke Schierer wrote: > Warren asked that we, as gaim, outline how we expect window > management to be handled, focusing on new windows & urgency, as per > the long discussions in #gaim over the last 2 or 3 days, in light of > metacity's move from causing gaim to always steal focus to having > windows pop under. >=20 > I wrote up the following as an inital draft, please comment. >=20 > I do not expect everyone will entirely agree, and I certainly am not > attempting to cover every case, whole specs have been written on this > sort of thing. I just want a basic idea of what we are looking for, > what other window managers are providing for us that metacity > currently is doing in a substandard (compared to other linux window > managers) way. >=20 > Naturally, the microsoft solution is not necessarily right or wrong, > but is, rather, utterly irrelevent to this discussion. >=20 > luke >=20 >=20 > * window focus should only be transfered from one window to another by th= e direct action of the user. > * The WM does not know when a new window is user initiated or not. > * The application that requests the new window does know > * In the case of new application launch, this yields a useful result: yo= u can start several things > in the background (or on login) and not have your focus jerked around = as they start. > * new windows should be created at the top level unless specifically requ= ested otherwise by the starting > application. Placement should reflect some overall policy of the WM, p= referably a policy that the > user understands and can predict. Remembering previous placement is a = reasonable, but not required, > part of said policy. > * Applications which currently have focus should be able to determine if = a window said application has > created gets focus or not. It should be able to do so without changing= the level at which the window > is created. > * Applications which do not have focus should not be able to pull focus f= rom another application in a > way that the user cannot disable or modify. Changes to individual appl= ications at a source code > level should not be necessary for this behavior. >=20 I agree will all of this, but would like to add that I am of the opinion that creating new windows on anything but the top level is more annoying than them taking focus. When you start an application, or open a new window, or the application creates a window that wasn't initiated by the user, you want to be able to see it and take care of it. But if it is displayed on a lower level, then you won't necessarily see it created, especially if your "taskbar" is set to autohide. Now you have to go and dig for said window, instead of alt-tab back to the window from which the focus was stolen from. Anyways, that just my two cents. --=20 Gary Kramlich <gr...@re...> |