> > I see the GEM as a package. The VDI is the low-level stuff, the AES is the
> > high-level stuff.
It's a rather unfortunate split in places, though, IMO.
I agree completely with earlier posts here, that for example rectangle
management belongs outside the AES proper (compare with X, for instance
(which in itself is more like the VDI than the AES, but it does handle
windows)).
> > I wouldn't like the AES to have to deal with various formats of /dev/mouse
> > or
> > /dev/keyboard. Drivers and hardware-dependant I/O are the VDI's domain I
> > think.
> >
> What's the difference between accessing the hardware through a MiNT-device
> and a VDI-device? I'd rather see as much hardware as possible handled by the
> kernel, instead of cluttering the VDI with it. Having to deal with the
> graphics card is enough IMO.
I agree.
In any case, the standard VDI keyboard/mouse functions are insane! ;-)
(Not to mention unsuitable for a multitasking system since there is no
way to do something like fselect on them.)
> > And the AES should use the VDI for its input, otherwize mouse accelerators
> > installed with the vex_motv() VDI function won't work.
Nor will programs that do animated cursors and such.
> No big loss. The speed of the cursor should be configured in the device
> instead. Ditto with screensavers. After all, what's the point of designing a
Given that people have very different ideas about what a good mouse
accelerator should do, the device needs to be rather flexible.
> MP-friendly and clean AES and VDI if you allow applications to hook into
> internal vectors?
Those vex_ functions definitely should be banned.
Naturally, that would require that other ways are available to do (at least
some of) what they are currently used for, though. Does anyone know what,
besides the acceleration and animated cursors?
--
Chalmers University | Why are these | e-mail: rand@cd.chalmers.se
of Technology | .signatures | johank@omicron.se
| so hard to do | WWW: rand.thn.htu.se
Gothenburg, Sweden | well? | (fVDI, MGIFv5, QLem)