On 11/11/05, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Adi Oanca <adioanca@xxxxxxxxx> wrote: > > > > this bug... (a view never receives B_EXITED_VIEW? :O ) > > > Yes, that was the problem. Once I added this, the problem went > > > away. Might be > > > the wrong place for the fix (though it is quite a failsafe place), > > > but the > > > problem was there. IMHO, this stuff could be handled on the client > > > side. Why > > > waste CPU cycles in the server for this? But I can have a look at > > > _ProcessMouseMovedEvent(), though I seem to remember Axel saying > > > something > > > about taking on event handling next. > > Input handling stuff is just fine. Unless if you don't agree with > > my work... > > ( don't you remember NEW_INPUT_HANDLING define? ) > > > > Axel, just wants to move this functionality in another class and > > make the cursor thread a reality. > > > > At least I don't see what Axel could do to this area. Axel? > > Well, I don't know yet either - but I'll certainly have a look when I'm > there. Moving some functionality into the client is definitely > desirable, I think. > > > Why we do this on server side? If done on client side, you can't > > send B_EXITED_VIEW to a view if you exited a window's area quickly. > > Yes, but that's probably no reason to move that functionality > completely away from the client. B_ENTERED_VIEW also is not guaranteed to work if implemented on client side. (The mouse made a trip outside our window and back again exactly on fLastMouseMovedView). I have tried to move this client side. When I wrote BWindow I tried to do that there. Haven't succeeded. This functionality is something which I think you cannot move to client side. But, then again, maybe you guys are smarter. ;-) Drawing! is one thing I think should be made client side. :-) Some part of clipping also. > Especially when the client messaging > starts to not use ports anymore, this will greatly speed up messaging. Umm... nice, nice! When? bye, Adi.