Axel Dörfler wrote: >>>use UpdateIfNecessary() is not GetMouse() itself but the context >>>it's >>>usually used in (MouseDown()). >> >> I'm not too happy with this method. I think it does not respect >>the logic, in general. I just asked for mouse coordinates, not for a >>UI >>update. The fact is that I can call GetMouse() from everywhere in >>window's >>context and not actually wanting to update the UI. > > GetMouse() does not ask for an UI update either, it just makes sure > they are processed when there is an =5FUPDATE=5F message in the queue. Yes that we know. What I asked, and Stephan seems to ask the same thing, is why(the reason) do we process update requests in a method that queries for mouse status? If no good reason emerges, maybe we should remove this functionality from GetMouse() in R2. >> IMO, in R2 this method should only return mouse location and >>buttons. What do you think=3F Also I think we should remove support for >>synchronous controls in R2. Opinions=3F > > I'm not sure about this. We should investigate this with every > application that needs it, and if the same could be achieved in > asynchronous mode. Stefano and Marc told us some good reasons. :-) But then again, why is it that we have this method if polling is required and BLooper/BMessage mechanism is ignored. Maybe it would be best that we have a general/global function to return mouse status and remove BView::GetMouse() altogether. > What I am sure of, however, is that we should switch to asynchronous > mode by default, and only allow synchronous mode if specifically asked > for. Second that. Also, if our studies show that we don't necessarily need synchronous mode in a BLooper type thread, we should drop synchronous support. >>>I thought DoUpdate() does that already=3F Or was that only the plan=3F >> >> No, no... DoUpdate() calls Draw() methods for every view that's >>inside the invalidated rect. >> DoUpdate() must not be modified, instead we should ask >>synchronously >>the server if it has an invalid region to pass to us, and force a 2nd >>update >>if one supplied. (DoUpdate() still has to be cleaned up. :-) Will do >>that >>someday) > > That would be fine by me, too :-) OK, I'll add a TODO in there. :-) bye, Adi.