Re: Custom icons + MouseUp fix
Hi Earle, The DLL hook is fairly straightforward to use, but is intrusive on the rest of a system, (MS don't really recommend using them!) MSDN however have lots of stuff on hooks e.g. http://msdn.microsoft.com/library/en-us/winui/WinUI/WindowsUserInterface/Win dowing/Hooks/AboutHooks.asp I've got one working in a separate DLL, but it isn't fit for public consumption and often goes bang! Harold's Morse program shows the potential power of hooks, and will really annoy any one within earshot if you have big woofers hanging on your pc! On using the standard Windoze cursors instead of the SW DIX one. Don't we have to use Hardware cursors to do this, or use Sprite Layer alternatives to the Pointer Layer routines in miDCInitialize(pScreen, g_winPointerCursorFuncs)? Or are you proposing converting X cursors on the fly using something similar to the Icon convert and still use miPointerAbsoluteCursor calls to place them. How can we tell which X cursor is in play on a client? I must admit I'm a little green in this area and keep going round in circles going through the porting docs, making pennies drop! Luckily, unlike icons, there are only a finite number of standard X cursor shapes to deal with, so a map could be used for these perhaps? Colin
Re: Custom icons + MouseUp fix
Hi, I been looking into replacing the mouse timers in multiwindow mode. Reference:- http://cygwin.com/ml/cygwin-xfree/2003-05/msg00591.html One interesting quick-fix, to improve out-of xwindow mouse responsiveness to reduce 'transition pointer artefacts' on leaving xwindows, is to reduce the value of MOUSE_POLLING_INTERVAL from 500 to 10ms! Tried this with load of xterms and xeyes open and it works for me (XP on a 500MHz Pentium III). Colin
Re: Custom icons + MouseUp fix
Howdy Colin! At 08:14 PM 6/17/2003 +0100, you wrote: I been looking into replacing the mouse timers in multiwindow mode. One interesting quick-fix, to improve out-of xwindow mouse responsiveness to reduce 'transition pointer artefacts' on leaving xwindows, is to reduce the value of MOUSE_POLLING_INTERVAL from 500 to 10ms! Tried this with load of xterms and xeyes open and it works for me (XP on a 500MHz Pentium III). That's something I tweaked too, but it didn't really seem to do much for me, probably since most of my jobs were remote (WM_TIMER is only given if there's nothing else for Windoze to do IIRC). Are you looking at the hook DLL? I've been swamped with other things so haven't done more than look at the sample code Harold did for that Morse beeper. One other minor thing I think might be simple to do is replace the SW diX cursor with the standard Windoze cursor: All the Xbitmap-WinIcon code can be used almost directly, and this'll reduce CPU load when moving the mouse over an active window. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Hi Earle, Just to say this patch works fine for me. Thanks Colin
Re: Custom icons + MouseUp fix
Earle, Any reason we shouldn't install a message hook when the user presses and holds a mouse button or modifier key? On a related note, what is up with winmultiwindowwindow.c/winTopLevelWindowProc()/WM[NC]MOUSELEAVE and the SetTimer call? This must have been something that Kensuke did without me looking too closely :) It looks like it is used to move the X cursor out of the screen view when the user moves the mouse out of the X window... but it never calls KillTimer in the processing of WM_TIMER, which is strange. It looks like this could also be used to move the mouse cursor if it shows up over another X window... but that should be handled by the WM_MOUSEMOVE processing for that new window. Do you see any reason we can't get rid of these timers? I would really like to avoid them if possible. Harold Colin Harrison wrote: Hi Earle, Just to say this patch works fine for me. Thanks Colin
Re: Custom icons + MouseUp fix
Howdy Harold, At 11:45 PM 5/30/2003 -0400, you wrote: Any reason we shouldn't install a message hook when the user presses and holds a mouse button or modifier key? I'm not sure what you mean by this, do a mouse capture? This may change the semantics, because then any drop-target window won't get any mouse messages since only one window is allowed to see the mouse moves/buttons. On a related note, what is up with winmultiwindowwindow.c/winTopLevelWindowProc()/WM[NC]MOUSELEAVE and the SetTimer call? This must have been something that Kensuke did without me looking too closely :) It looks like it is used to move the X cursor out of the screen view when the user moves the mouse out of the X window... but it never calls KillTimer in the processing of WM_TIMER, which is strange. It looks like this could also be used to move the mouse cursor if it shows up over another X window... but that should be handled by the WM_MOUSEMOVE processing for that new window. Do you see any reason we can't get rid of these timers? I would really like to avoid them if possible. I think what he was trying to do was to update the mouse position in the root window when the mouse isn't over any X window, since you only get mousemoves if the mouse is over your window. Removing the timers would kill things like xeyes and the drag-n-drop icon movements in some of the KDE/QT/whatever apps. In multi-window-mode the root window would then only get messages when the mouse was inside the client area of one of the apps... Even if he doesn't KillTimer, since he is reusing the event id it shouldn't cause any kind of leak. And he does kill it on a mousemove on the initiating window. However I think he has a bug here, it seems he will create a timer for each X window, not one for the entire application. You can test this by restarting the server and running xeyes. Move your cursor around on the desktop, outside the window and see how the eyes only update once per second or so. Now, open up 20 x terms and move your mouse through each, just to start their timers. Finally, with those 20 windows up move your mouse outside them on the Windoze desktop and you'll notice the eyes are following in real time, much faster than before. As bugs go it's pretty benign, and would take another global variable to hold the timer ID to fix... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Howdy Harold, let me just say thanks for the efforts you've been giving while trying to herd cats^Wpatches... At ***02:37 AM*** 5/29/2003 -0400, you wrote: 11) Try, in vain, to maintain a uniform coding style and variable/function naming convention. I am mostly winning the curly-brace (curly braces on separate lines please), indenting (emacs ... Please replace local source with source from test release, reapply local patches to test source, and submit new patches as needed. :) I have made lots of style fixes to the source, so you might as well replace all files... otherwise diffs will be useless for me as they were quoting hundreds of lines of source that were logically equivalent but stylistically different. [Anybody about to send me a diff command that ignores whitespace, don't... that isn't what I am looking for.] All the old changes look to work great! I got my Debussy and NCVerilog icons, title bars, etc. without a single change. I am also attaching what I hope is a style-conforming patch for the missed mouseup messages. The problem is that Windows will not give you a WM_[LMR]BUTTON[UP/DOWN] unless the mouse is over a window you own. To get around this I put in a check in the WM_TIMER which is already in there to kludge WM_MOUSEMOVEs when the pointer is not in an X owned window. It's gone through 2 days of me beating on it for real work and it seems OK. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com buttonrelease.diff.bz2 Description: Binary data
RE: Custom icons + MouseUp fix
Howdy Colin, glad to hear it's working 100%. The original problem was the endianness of Windoze 1-bit bitmap when using a non-32-bit wide destination. I think the code was writing into the unused portion of the 32-bits and you got garbage in the real mask part. I found some kde apps on a linux box and did some peeking, it seems that not many register a small 16x16 icon, and that konqueror, for example, only gives a 16x16 icon in its _NET_WM_ICON property anyway. Very strange, maybe that _NET_ICON thing isn't commonplace? Things like KPAINT, KCALC, and KILLUSTRATOR (great name, the kill-ustrator) have big icons by default in WM_HINTS. Today I also got to test a fix for the missed ButtonRelease problem (dragging an Xterm scrollbar outside of its window and releasing the button does not tell Xterm it was released, leading to interesting problems). One thing I had to do that I don't like is to use a local copy of what the winmultiwindowwindow.c thinks is the button state. (i.e. LBUTTON=down, MBUTTON=up, RBUTTON=up) It did seem to work the entire day of hard use w/o any problems, but I have the suspicion that it might sometimes get out-of-sync w/the X server and send two ButtonReleases. That'd be better than the present situation but could still cause problems with pasting twice... Is there a simple mi* or dix* call to get this info directly instead of keeping a cached copy? I did a grep but didn't find anything promising. You can't call XQueryPointer() since that's only legal for a client to do. I suppose I could post something to the WM thread but that's a real ugly kludge. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Earle, Whatever you do, don't send a patch for the mouse release fix until I can make another test release. I am getting swamped with patches here. Thanks. Harold Earle F. Philhower III wrote: Howdy Colin, glad to hear it's working 100%. The original problem was the endianness of Windoze 1-bit bitmap when using a non-32-bit wide destination. I think the code was writing into the unused portion of the 32-bits and you got garbage in the real mask part. I found some kde apps on a linux box and did some peeking, it seems that not many register a small 16x16 icon, and that konqueror, for example, only gives a 16x16 icon in its _NET_WM_ICON property anyway. Very strange, maybe that _NET_ICON thing isn't commonplace? Things like KPAINT, KCALC, and KILLUSTRATOR (great name, the kill-ustrator) have big icons by default in WM_HINTS. Today I also got to test a fix for the missed ButtonRelease problem (dragging an Xterm scrollbar outside of its window and releasing the button does not tell Xterm it was released, leading to interesting problems). One thing I had to do that I don't like is to use a local copy of what the winmultiwindowwindow.c thinks is the button state. (i.e. LBUTTON=down, MBUTTON=up, RBUTTON=up) It did seem to work the entire day of hard use w/o any problems, but I have the suspicion that it might sometimes get out-of-sync w/the X server and send two ButtonReleases. That'd be better than the present situation but could still cause problems with pasting twice... Is there a simple mi* or dix* call to get this info directly instead of keeping a cached copy? I did a grep but didn't find anything promising. You can't call XQueryPointer() since that's only legal for a client to do. I suppose I could post something to the WM thread but that's a real ugly kludge. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Howdy Harold, At 12:04 AM 5/29/2003 -0400, you wrote: Whatever you do, don't send a patch for the mouse release fix until I can make another test release. I am getting swamped with patches here. Thanks. OK, truce! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Okay, test release posted. Please replace local source with source from test release, reapply local patches to test source, and submit new patches as needed. :) I have made lots of style fixes to the source, so you might as well replace all files... otherwise diffs will be useless for me as they were quoting hundreds of lines of source that were logically equivalent but stylistically different. [Anybody about to send me a diff command that ignores whitespace, don't... that isn't what I am looking for.] Harold Earle F. Philhower III wrote: Howdy Harold, At 12:04 AM 5/29/2003 -0400, you wrote: Whatever you do, don't send a patch for the mouse release fix until I can make another test release. I am getting swamped with patches here. Thanks. OK, truce! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Custom icons + MouseUp fix
Harold L Hunt II wrote: Okay, test release posted. Please replace local source with source from test release, reapply local patches to test source, and submit new patches as needed. :) Harold, can you import your local tree to the cvs on sourceforge? So we can easily do updates and keep the merging problems at a minimum. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
