Re: Thoughts for discussion & info request

> > And this is why I prefer that the server just be named /dev/mouse. Rather
> > than have a boundless number of names for the mouse (Logitech/Microsoft/
> > Mouse Systems/..., one- two- and three-button, bus and serial, ...) it'd be
> > nice if the mouse server just presented a uniform /dev/mouse and then did
> > what was necessary to make it fly. For instance, synthesizing a third
> > button if it's missing.
>
> FWIW, I still prefer making the emulation of a 3rd button selectable via the
> FS_WSTAT mechanism, with the server reporting the number of buttons via
> FS_STAT. I've come across quite a few programs that assume that either the
> left or the right button can be pressed at the same time as a middle button
> (if it's present) - forcing the emulation can break things under these
> circumstances. BTW, I remembered my objection to using multiple names - it
> meant adding directory manipulation code to the mouse server where none
> previously existed. The fd server already had this code, so the additions
> to handle additional "files" was pretty straightforward.
>
>
> Regards,
> Dave
>

As I've said. To change the behavior in this way lead to unneccessary
complicated client code.

  (You need to set up the behavior at startup instead of having it )
  (working anyway. )

Sure this solution is the one of traditional Unix like systems and so
we may be more familliar with it.

But VSTa isn't a unix like system. It may be made to behave so, but
than it'll lost some benefits. (At the other hand it will be needed to
do so for the reason of keeping well know and good applications
working.)

But in c/s systems, as in other object systems, it is better to have
such things solved by simply renaming some stuff.
Received on Tue Aug 16 04:33:10 1994