[Pkg-xfce-devel] Bug#507716: Bug#507716: Bug#507716: Bug#507716: xfwm4: broken "focus follows mouse" behavior on raise
corsac at debian.org
Fri Dec 5 22:42:42 UTC 2008
forwarded 507716 http://bugzilla.xfce.org/show_bug.cgi?id=4679
On ven, 2008-12-05 at 12:29 -0600, Jason Kraftcheck wrote:
> Yves-Alexis Perez wrote:
> > Ow, please, don't be like that. *You* have a problem, so *you* should
> > provide all informations about your problem so we can do something about
> > that.
> The patch I sent with my original PR fixes the problem.
It fixes the problem for you, maybe. Nobody knows what it'll do on other
installs. Except for example the upstream developper.
> > And, basically, giving one single piece of information won't help
> > anybody. And I asked about “focus” stuff (tada, that's because you have
> > a _focus_ problem) so you could have guessed in the first place.
> Perhaps I could have guessed. But if you wanted to know focus-related
> settings, you could have just asked for that rather than asking which
> settings I tried changing and then complaining that I didn't guess what you
> intended to ask.
No. I asked you to check (to *verify*) how were the other settings. EOT
> > In your case, you would like something a bit that “Don't automatically
> > focus windows when they are raised”, I think.
> Such an option shouldn't be necessary. "focus-follows-pointer" means that
> whatever window contains the mouse pointer has focus. Moving the focus to
> some other window because of an CWStackMode event is wrong.
Except that some window are legitimate to have focus in that case. Some
don't, and that's why there is the “focus stealing prevention” too.
> > I'm not a wm expert, but I don't think there is such a thing as “raised
> > on top” event for a window. I assume that what you send (with
> > emacsclient or nedit-nc) is a “focus” event, so in this case it would be
> > ok to focus it.
> A CWStackMode configureWindow request asks the WM to change the position of
> the client window in the stacking order (ordered list of which window is in
> front of which if they should overlap). It is conceptually distinct from,
> for example, a call to XSetInputFocus. There often is no distinction
> between the two when a Window manager is operating in "click-to-focus" mode,
> as clicking on a window both raises it above all others and gives it the
> keyboard focus.
> Other window managers that I've used behave the way I am saying that xfwm4
> should, including: blackbox and derivatives, the WM was under CDE on
> Solaris, and x.org with no window manager running.
> > Please open a bug on Xfce bugzilla (http://bugs.xfce.org) on xfwm4
> > component (4.4.2 version) asking about that and providing all
> > informations necessary. (and forward the bug number to this bug report)
That's what you should have done in the first place. Well, with
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20081205/b6afcbf1/attachment.pgp
More information about the Pkg-xfce-devel