headers
Jon TURNEY | 3 Sep 2011 21:01
Picon
Favicon
Gravatar

Re: XRaiseWindow for activating windows in multiwindow mode

On 13/08/2011 19:39, Oliver Schmidt wrote:
> as reported in
>
>    http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
>
> windows are not raised from the Cygwin X Server in multiwindow
> mode, if a program wants to programmatically activate a window.
>
> I played around and figured out that the problem can be solved by
> invoking the windows function SetForegroundWindow if a top level
> window is to be restacked and has no previous sibling.
>
> I enclose the patch in this email. It works fine for me, but
> I'm not sure if it has any side effects for other configurations
> or usage patterns.

Thanks for looking into this, and for the patch.

There definitely are some problems in this area, but I'm not sure this is the 
'correct' fix, though.

The code as it stands is the product of some ... erm ... historical compromises.

If I am reading the code correctly, it looks like currently no attempt is made 
to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow()) 
to the native Windows window Z-order, and the comment in [1] seems to bear 
this out.  The code which perhaps would do this is in the disabled branch of 
the #if/#else/#endif in winRestackWindowMultiWindow()

The relevant thread seems to be [2] and the relevant change seems to be [3],
(Continue reading)

Permalink | Reply | 7 comments |
headers
Oliver Schmidt | 4 Sep 2011 10:52
Picon
Picon

Re: XRaiseWindow for activating windows in multiwindow mode

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oliver Schmidt | 4 Sep 2011 11:08
Picon
Picon

Re: XRaiseWindow for activating windows in multiwindow mode

some additions to my last mail:

On 04/09/11 10:52, Oliver Schmidt wrote:
> 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,

After looking again at the code, I must correct my above statements: now
I think, that it's not the native Windows function SetForegroundWindow
that is calling the recursive behaviour.

It's still the already existing code in the function
winReorderWindowsMultiWindow that is causing recursive behaviour: in
this existing code the function ConfigureWindow is invoked (this is not
a native Windows function, it seems to be some x server function). So
the invocation of this function is triggering the x server to invoke
winRestackWindowMultiWindow recursively.

But these are still theories. At least the recursive behaviour is not
introduced by the patch, it was already there in the existing coding ;-)

Best regards,
Oliver

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Schmidt | 4 Sep 2011 13:17
Picon
Picon

Re: XRaiseWindow for activating windows in multiwindow mode

It's me again ;-)

On 9/3/2011 9:01 PM, Jon TURNEY wrote:
> 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.
> 
> [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html

I'm not sure if I'm correctly reproducing the above usage scenario
"always on top", but I did the following under Windows 7 and XP:

1) downloaded and installed http://www.abstractpath.com/powermenu/
2) launched a xclock or a native Windows program (e.g. Internet
Explorer) and select "Always on top" with right mouse click on the
window's titel bar
3) programmatically launched and raised other x top level windows
4) Everything works: the checked windows stay top level, the
programmatically raised windows became top level amongst all other "non
always top level" windows and get keyboard focus and activated window frame.

I was also able to minimize and restore the "always on top window"
without any problems. Moreover the "redraw windows while moving and
sizing" hack
 http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html
does also work with the "always on top" feature enabled for the
foreground and background window. Also mixtures of cygwin x server
windows with native Windows applications all with "always on top"
feature enabled are working.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jon TURNEY | 5 Sep 2011 15:35
Picon
Favicon
Gravatar

Re: AltGr key mostly fires an additional CONTROL key

On 15/08/2011 13:53, Oliver Schmidt wrote:
> I also had problems with the AltGr key. These could reliably
> be reproduced by holding the AltGr for some seconds (causing
> Windows generating auto repeat events).
>
> Unfortunately the test version at
>
>    ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2
>
> doesn't fix this problem for me.
>
> I discovered that the mechanism in winkeybd.c function
> winIsFakeCtrl_L had a problem if PeekMessage cannot obtain
> the next Alt_R message because it is not there.
>
> I prepared a patch that remembers the last Ctrl_L event and
> reacts on a later following Alt_R. It was also necessary to
> alter the order in winWindowProc in winwndproc.c: the invocation
> of winIsFakeCtrl_L had to be done before discarding auto-repeated
> key presses.
>
> The attached patch is against the sources of xserver-cygwin-1.10.3-1.

Thanks for the patch.  The approach of remembering if the last keyevent was a 
Ctrl-L and reversing it if it was fake because it's followed by a AltGr is a 
good one, which hadn't occurred to me, and it clearly better than assuming the 
AltGr keyevent message will be available some fixed time after the Ctrl-L one.

(I had considered buffering the Ctrl-L keyevent until we could determine a 
AltGr wasn't going to be coming after it, but that would be more complex to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oliver Schmidt | 6 Sep 2011 09:44
Picon
Picon

Re: AltGr key mostly fires an additional CONTROL key

Hi Jon,

On 9/5/2011 3:35 PM, Jon TURNEY wrote:
> comments, as what this code is trying to do is slightly obscure, and I
> assume that the old comments about TweakUI being the cause of this are
> just wrong (as you don't mention that you have it installed)

Yes I didn't test it with Tweak UI and I ignored the comments on Tweak
UI. I also think that the old "sleep(0)" workaround for Tweak UI is now
not necessary with the new patch. But I kept the changes as minimal as
possible and tried to keep existing code as much as it is.

>> diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
>> +  static Bool   hasLastControlL = FALSE;
>> +  static UINT   lastMessage;
>> +  static WPARAM lastWparam;
>> +  static LPARAM lastLparam;
>> +  static LONG   lastTime;
> 
> I was going to suggest using static  MSG lastMsg, but then I noticed
> that lastWparam, lastLparam are completely unused...

yes, they are now unused editing relicts from my testing phase...

>> +
>> +          if ((lastMessage == WM_KEYDOWN || lastMessage ==
>> WM_SYSKEYDOWN)
>> +              && lastTime == lTime)
> 
> Why is it necessary to check that the last message was WM_(SYS)KEYDOWN
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jon TURNEY | 7 Sep 2011 14:25
Picon
Favicon
Gravatar

Re: Can't paste text or type blind keys when mouse is out of the window

On 07/08/2011 10:05, Paul Maier wrote:
> when xterm has keyboard focus, but mouse pointer is outside of the window (or
> even on Window's blue title bar):
>
>
> - all blind keys are ignored:
>
>    o  instead of 'à' (key '`' then 'a') you get just a normal 'a'
>
>    o  can't type '^' character (on a German keyboard done with blind '^' key then space)
>       ->  you will just get the space instead
>
>    o  same with '`' or '´': all blind keys are affected
>
> - can't paste text with the mouse
>
> - all other keys work as expected

Thanks for reporting this issue and the clear reproduction step.

I can reproduce this problem.  I can also reproduce it under XWin in windowed 
mode with twm, but not on Xorg on Linux, so this seems to be XWin specific, 
but not related to multiwindow mode WM, which is a real puzzler.

I assume that you see the same behavior with other X applications, i.e. it's 
not xterm-specific?

> The XWin.logs are the same regardless if mouse is inside or outside,
> but I notice a small difference in xev's output.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jon TURNEY | 7 Sep 2011 15:15
Picon
Favicon
Gravatar

Re: minimize redraw events after resizing/moving windows in multiwindow mode

On 20/08/2011 23:11, Oliver Schmidt wrote:
> in multiwindow mode the modal moving/resizing of windows causes a lot of
> redraw events send to the X clients after the userse releases the mouse
> button. During the moving/resizing client windows are not redrawn as long as
> the mouse button is pressed. But all redraw/resizing events are queued and
> executed step after step after moving/resizing ends.
>
> Some clients collect and combine multiple redraw or resizing events, other
> clients (e.g. xterm) simply execute each redraw or sizing event.
>
> The enclosed patch minimizes the events for clients to only one event after
> the user releases the mouse button to end the moving/resizing. This improves
> the user experience and reduces strange screen flickerings especially on slow
> platforms.

Thanks for the patch.

I've applied it to my git tree [1], so it will appear in the next cygwin X 
server release (probably 1.11.0-1)

[1] 
http://cgit.freedesktop.org/~jturney/xserver/commit/?h=cygwin-release-1.11&id=784ef7472904cbac6ea49d8cf0e489820372a90d

--

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon TURNEY | 7 Sep 2011 17:05
Picon
Favicon
Gravatar

Re: redraw windows while resizing/moving windows in multiwindow mode

On 20/08/2011 23:41, Oliver Schmidt wrote:
> the following patch is a quick & dirty hack to enable redrawing of windows
> while the user moves or resizes the window.
>
> This patch should be seen as experimental proof that this can be done with
> only small changes in the source code.

This is fine as a proof of concept, and it would be nice to handle this better 
and do X window updates during the Windows modal resizing loop, but I don't 
think I can apply this patch.

> The main problem with window resizing/moving under Windows is, that in the
> function invocation stack dix/Dispatch -> os/WaitForSomething -> WakeupHandler
> -> hw/xwin/winWakeupHandler -> Windows/DispatchMessage ->
> hw/xwin/winTopLevelWindowProc the Windows function DispatchMessage does not
> return while the user resizes/moves a window. This function only returns after
> the user releases the mouse button. However the dix/Dispatch functions must be
> run to allow the clients to process the queued redraw/resizing events.

Well, in fact, no X events are processed while in the modal resizing loop, so 
for e.g. if you have ico running in another X window, it stops updating while 
an xterm window is being resized.

Note that there are other modal loops in Windows message handling, I think 
moving the scrollbar also involves one (which can happen in windowed mode with 
the -scrollbar option)

> The enclosed hack simply moves the invocation of DispatchMessage in
> winWakeupHandler outside WaitForSomething into Dispatch and breaks up the
> Dispatch function into a loop and inner dispatch handling that can be called
(Continue reading)

Permalink | Reply | 2 comments |

Gmane