> > I think there ought to be a method for the application to grab the mouse.
> > QuakeForge has a method for this under its option menu which isn't present
> > for the GGI target.
> However I'm considering adding functionality to do this. Mainly
> because no Quakeforge target should be better than the GGI one. ;-)
ROTFL ...
> The idea is that we do it with *SendEvent() and
> GII_CMDCODE_PREFER_RELCOORD and GII_CMDCODE_PREFER_ABSCOORD, and
> thus make it a quite useful functionality for non-games also.
Yes.
> This way we also doesn't add a single byte of code to inputs that
> don't have functionality to do this.
> What do you think Andy? Sounds good?
Yeah ... Definitely.
I'm just pondering the thought, if we should add that functionality to
LibWMH, as it is designed to do the windowing-related stuff, but on the
other hand it doesn't quite seem to be the right place ...
However it would have the advantage of knowing what target it is running
on (as it is an extension) and thus be able to only send the codes when
the functionality is available and give nice error codes, if not.
This way we could keep the call a private feature of the X input libs
(i.e. we don't need to alloc from the public command numberspace).
While someone does that, he might as well want to introduce a method to
define the cursor shape of the window system in use. That would be very
handy for a GUI toolkit, as you could then avoid the use of soft cursors
when running on a window system.
Marcus: Just decide what you like better. Both implementation possibilities
(straight away as commands for direct application use or via LibWMH) seem
o.k., so just do the one you like better.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
