This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Server Test 88


Howdy Lev,

More interesting stuff with timers, held keys, held mouse buttons:
Firstly, the timer doesn't even get created every time. I can demonstrate
this by starting xwin with just one xterm, and running xeyes. Normally if
I move the mouse out of the xterm then about half a second later the x
cursor gets deleted and the xeyes continue to update. But if I move the
mouse really quickly out of the xterm (helps that I have mouse sensitivity
set at the highest setting) then sometimes the cursor is not deleted and
xeyes don't update until I move mouse back into the xterm. So occasionally
the timer is not created, it seems. As a secondary phenomenon, if I do
this fast movement out of the xterm while at the same time holding a mouse
button, then the windows mouse cursor not shown either (ie the mouse is
invisible) until I release the click.

Yup, I've seen this too, but it's not something I've ever been able to make happen except on purpose. Strange! This has bee there since the early days I think, you may want to check the mouseleave processing.

Secondly, the recent fix whereby all x keys get forced released on losing
focus doesn't seem to be strictly correct either. If I put focus on my
xterm and then hold, say shift or control, and while holding it click on
the desktop to remove focus from xterm and then click back on the xterm,
the xterm behaves as if shift and control are not pressed. Of course this
is rarely a problem but perhaps it could be an issue if there are any X
applications that make use of shift-drag/drop or control-drag/drop, etc,
like windows does. Might also be a problem for people using the windows
accessibility options such as "sticky keys".

True, but what you describe seems to be a real corner case, no? By clicking you've change to a non-X app and any X drag-n-drop should be cancelled, right? A workaround would be to put in a check in the WM_ACTIVATEAPP to send keydowns for any modifiers current pressed when you change from a Windoze to X app...

So, all things considered, the message hook idea sounds better than using
a timer, and while you're at it, you could do the right thing(tm)
concerning keydown, keyup instead of just force-releasing all keys.
With this, might it in fact be possible to remove most of the
event-handling stuff out of each client-window message loop and just use
the hook to pass these messages directly to the root window. (Ie install
the hook once, at server-startup, and then you receive all the mouse and
keboard events, just like in the non-rootless, non-multiwindow case). I
don't know enough about the multiwindow implementation to know if this is
sensible.

That's much easier said than done, I fear. You crash xwin.exe, you just restart it. If you crash your hooking DLL, you could end up killing other apps. Plus, that gives you one more asynch process to work with and keep happy. I'm also not sure that you can do message hooking under NT based OSes: under 95 et al you had 1 message queue for all apps, but under NT et al you have 1 message queue per main window. I could be wrong on this but I'd check it out before starting to hack away just in case.

Icons now work for me. No offense, but they're fairly ugly though. The
'big' version I get when alt-tabbing is OK for some (like xclock, oclock,
xload) and not so good for others (xtriangles, xrubik, xfig), but the
smaller versions that go in the window's title bar and on the taskbar,
they're really not so good. Is this because the X apps I'm testing with
(xclock, oclock, xload, xditview)  only contain a large-version icon and
we have to scale it down ourselves (whereas presumably native windows apps
have both small and large icons available)? Would the current
icon-handling code we have deal with creating both small and large icons
in the cases that both were available? If indeed we are scaling the icons
ouselves, is there a nicer way to do the filtering (its a tiny image and
only gets created very infrequently, so shouldn't be a big performance
concern even if there's some real image-processing stuff going on here).

You're using the wrong apps! :) Apps created after about 1990 or so seem to all have higher color icons, you're looking at the original X consortium apps ported from X10, using 1 bpp icons. Other apps like Mozilla or the KDE suites look much nicer, you should give them a try. You can also use the xwin.ini to override some icons, check the ml archives for more info. Try konqueror if you can, it's got pretty spiffy icons.

As for the scaling, check out the bottom of winmultiwindowwindow.c.  Feel
free to put in a nice 2d filter, but it'll really only make a difference
for xcalc.  X apps normally only have one icon size specified, and that size
can be almost anything.  Some of the QT(KDE?) apps have an additional
extension where they specify multiple icons per app, but I have no idea
how to get Windoze to grok a multi-sized on-the-fly created icon.  It was
a real pain getting it to take a single-sized on-the-fly one!


-Earle F. Philhower, III earle@ziplabel.com cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]