From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-12-11 01:33:39
On Wed, Dec 11, 2002 at 01:06:41AM +0100, Christian Groessler wrote:
> A null textcolor will only work _sometimes_, i.e. depending on the
> choice of background color.
Ok, you're right. Seems I've overlooked something.
The difference between the color mode on the Atari and that of a pure
monochrome machine is that the Atari can change the background color, while a
monochrome machine can't. So if one makes the background color white for
example, standard white text gets unreadable.
Since conio does only support two color models (one being "color" and the
other "monochrome") there are not many solutions. Probably the best one would
be to make bgcolor empty as well. This makes the Atari a pure monochrome
machine (as far as conio goes, that is).
> So you will anyway need ifdefs to correctly support the Atari. You
> might not notice this if calling textcolor work, if textcolor is
> missing, you'll notice immediately.
Conio supports two color models: Color and monochrome. So a multi platform
program will always have to cope with these two models. If the Atari supports
the monochrome model, it is not necessary to add specific #ifdefs for the
Atari, because these #ifdefs are already in place for the other monochrome
machines. If we don't make textcolor empty, we need Atari specific code.
Please have a look at the existing multi platform code. All this code (which
was developed independently by several people) uses calls to textcolor(), both
for color and monochrome machines. If the Atari platform omits the textcolor
function completely, the most easy solution to keep the code portable is to
add an empty textcolor function - which perverts the whole removal. Why should
we remove the function from the library just to add it later as an empty
function in the application to make the code compile?
> The reason I'm bitching so much, is that I still don't see the
> benefit of having an empty textcolor() and a new textluminance() over
> having a textcolor() which behaves differently on the Atari.
Having a textcolor that behaves differently is not an option. If we start
adding functions that behave differently, we'll break the whole portability
goal.
But I'm open to other suggestions. If you find a way to make colors work in a
way that needs no Atari specific code in an application, and keeps functions
consistent across platforms, I have no problem with it. I've outlined the most
obvious solution above (making bgcolor empty as well), but this must not be
the only solution.
I'm sorry about that, and please note that it is not my intent to cripple the
Atari. In fact, I'm quite unhappy about the outcome, because I know that the
acceptance of conio does also rely on how closely it is modelling the
capabilities of the real machine. However, one of the most important rules is
to keep the APIs clean, and in this case I see no other possibility as to use
only a subset of what the Atari is able to do.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-12-11 01:33:46 CET