Re: [cc65] Mouse API Proposals

Hi,

>> > >> 2. Coordinate mapping
>>
>> Just another idea regarding coordinate mapping. I don't know if it's a good
>> one, but it came over me :-)
>>
>> How about having separate drivers for conio that do the mapping and others
>> that don't? The conio drivers could be generated from the same set of
>> sources using a few .defines. This would mean that you just pay for this
>> feature if you want it, the mouse API and kernel stay as they are.
>>
>> The disadvantage is the growing number of drivers, but I think this is
>> manageable, especially since there usually are not separate sources.
>
> i prefer this approach a lot over "fat" drivers.

I'm somewhat puzzled why everybody talks about the mouse drivers. What
does the mouse driver have to do with text or graphics mode display
and the user program preferences regarding pixel vs. char resolution?

Beside that - going down the road Uz pointed out would mean that for
consistency reasons setting the bounding box and setting the cursor
pos would have to happen char based as well. THIS would mean a fat
driver (without the option to get rid of actually unused functionality
at link time). One cannot just have the whole mouse driver work with
chars because the mouse would become way to sensitive/fast...

Result: The mapping code in question...
a) does - at least from my perspective - not belong to the driver - it
has just nothing to do with the role of the driver which is
abstracting the input device used.
b) does not belong to the mouse kernel as it is far from platform-independent
c) does not belong to the mouse callbacks as it isn't called by the
mouse driver (it's just that on the Apple II the mapping code is
basically identical)

So maybe it's just two ordinary functions (probably in the conio library) ?

Best, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.