public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Oliver Schmidt <oschmidt-mailinglists@gmx.de> To: cygwin-xfree <cygwin-xfree@cygwin.com> Subject: Re: XRaiseWindow for activating windows in multiwindow mode Date: Sun, 04 Sep 2011 08:52:00 -0000 [thread overview] Message-ID: <4E633C53.4040906@gmx.de> (raw) In-Reply-To: <4E62799E.2090204@dronecode.org.uk> Hi Jon, On 03/09/11 21:01, Jon TURNEY wrote: > There definitely are some problems in this area, but I'm not sure this is the > 'correct' fix, though. yes, it's some kind of workaround, but it works and is very useful for may daily work. At least the patch is very defensive, it just raises top level windows that should be on top over all other top level windows (i.e. have no previous sibling). Some programs become unusable if programmatically raised windows are not raised. Of course it would be better if the cygwin multiwindow mode would react on window manager messages, i.e. atom "_NET_ACTIVE_WINDOW" for raising windows. > The code as it stands is the product of some ... erm ... historical compromises. I tried to left it mostly at it is, but yes, one can see that the coding at this point is a little bit "historic", especially the #if 1...#else block later on in the function winRestackWindowMultiWindow.... > this out. The code which perhaps would do this is in the disabled branch of > the #if/#else/#endif in winRestackWindowMultiWindow() yes, I had the same thoughts about it, but I didn't get it to work with this uncommented code. At least this uncommented code does not invoke SetForegroundWindow, so I doubt that it would raise windows under all conditions. > The relevant thread seems to be [2] and the relevant change seems to be [3], > but I can't reconstruct the reasoning behind it. > > As discussed in the thread [2] various scenarios, e.g. AOT windows, native > windows interleaved with X windows in the native Z order, Windows with > focus-follows-mouse enabled via TweakUI all need testing after trying to fix > this, to ensure you haven't regressed them. yes, is there any one here on this thread that uses these features and can confirm that they are still working with the patch? > I'd like this patch more if you said why recursive calls can occur, > and why they must be avoided. This was not my idea: it's just copied code from the function winReorderWindowsMultiWindow, so the reasons for avoiding the recursive behaviour are the same reasons that apply to existing code. The patched function winRestackWindowMultiWindow invokes the function winReorderWindowsMultiWindow in the #if 1 code block. So my idea was to move this lock a little bit higher, because with this patch critical work is done in the invoking fucunction winRestackWindowMultiWindow now. The recursive behaviour did occur in my testing, so this condition testing for avoiding recursive behaviour was necessary in the existing code and is also necessary for the patch. I think that the recursice behaviour occurs because changes on the top level windows with native Windows-API-Calls are leading to native Windows messages that again are fed into the x server and are leading to the funcion winRestackWindowMultiWindow. But this is only a theory, it is very difficult to find theses things out under cygwin, because stack traces via function "backtrace" from <execinfo.h> and "addr2line" are unfortunately not possible with cygwin :-( At least I'm happy now with my patched cygwin x server and I'm using it every day now ;-) Best regards, Oliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
next prev parent reply other threads:[~2011-09-04 8:52 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-13 18:39 Oliver Schmidt 2011-09-03 19:02 ` Jon TURNEY 2011-09-04 8:52 ` Oliver Schmidt [this message] 2011-09-04 9:09 ` Oliver Schmidt 2011-09-04 11:18 ` Oliver Schmidt 2011-10-19 9:33 ` Michel Hummel 2011-10-21 10:36 ` Oliver Schmidt 2011-10-21 11:43 ` Michel Hummel 2011-10-21 12:26 ` Oliver Schmidt 2014-06-11 20:50 Patrick Herbst 2014-06-19 10:07 ` Oliver Schmidt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4E633C53.4040906@gmx.de \ --to=oschmidt-mailinglists@gmx.de \ --cc=cygwin-xfree@cygwin.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).