[ANNOUNCEMENT] Server Test 88

[Earle F. Philhower III]

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