From: Patrick H. <pa...@in...> - 2005-06-27 15:19:07
|
jhe...@la... wrote: [snip] >>>and other strange behaviours. >> >>Could you be more specific? > > At the beginning I was a bit confused about why tweek didn't try to start > when the name service was down and but later I realized that it had to do > with the configuration file I was using (it was self-made and didn't > include nor the rtrc neither the perf_mon config elements). But it was > surprising that when the name service was up, tweek tried to start and it > hung the application; even, the omni0rb4-nameserver processes aborted > sometimes (it might not be very robust). I think that omniNames itself is quite robust. It has had years of development and widespread use to become stable and mature. It sounds like the code is not being compiled correctly, though I cannot say how or why. It may be a compiler bug, or it may be that omniORB needs more testing on AMD64 hardware. If it is an omniORB problem, then questions about it should be posted on the omniORB mailing list. [snip] >>Allen Bierbaum has (had?) some patches to do just that, but I think he was >>still trying to figure out how to implement the equivalent behavior on >>Windows. Or perhaps it was the other way around. You are welcome to >>submit >>patches of your own if you like, but it would be important for the same >>keyboard/mouse configuration to be usable on X11 and Win32. > > So, can I suppose that functionality will be available soon? I don't know. It is up to Allen to find time to finish his changes and commit them--assuming he even still has them. As always, if someone else has changes to submit that would address this deficiency, then those changes would be welcome. >>>And another suggestion is that it would be interesting the >>>posibility of disabling keyboard autorepeat with a configuration option >>>in >>>the KeyboardMouseDevice element. >> >>Could you elaborate on how this would be useful? I don't recall anyone >>ever >>asking about this before, but I have generally tried to avoid the >>keyboard/mouse handling code in Juggler. It is some of the oldest code in >>Juggler, and it has only recently received some fresh attention. > > I'm going to develop a scientific visualization application, and the idea > is that it should work in desktop computers as well as in an inmmersive VR > system. So, for the desktop version I'd like to have control over the > keyboard and mouse input in order to give a more usable interface that the > simulated wand. After considering things better I've realized that such a > low level control in keyboard input has no much use if I can control the > mouse allright. > > >>>Suppose I wanted to do it by my self creating a device plugin, what are >>>the guidelines to make it?. I've looked at the device driver authoring >>>guide but there aren't any displays implied in there so I don't see it >>>clear enough >> >>I don't understand what you mean by "displays implied" in this context. > > I mean that in other devices you acquire the input from some source you > can determine and it's fully over your control inside te driver. But for > keyboard/mouse input there are displays_windows around. If you make your > own input window for your driver there is no much trouble, but if you want > to use the display window used for graphic output (as it can be done with > the current device) I don't understand very well how to do it. > Anyway that's not important if I can suppose that mouse wheel is expected > to work in a near future. Have you looked at the VR Juggler /Configuration Guide/ and its explanation of how to configure keyboard/mouse input from a graphics window? Aside from the shortcoming of not recognizing the mouse scroll wheel input, the keyboard/mouse input handler should do what you need without requiring modifications. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |