| |
| |
TL;DR: If it's truly not possible to work around, then I
suppose it has to change.
Perhaps putchar_utf8(),
And if POSIX explicitly allows it, well then I suppose we have
to live
with POSIX and all the warts it implies.
But had 1.4.0 released with putchar() in place, I'd think
there'd be
possible workarounds.
On 3/25/24 14:00, 'Albrecht Schlosser' via fltk.coredev wrote:
What
would be wrong with renaming the Fl_Terminal::putcha() method to
avoid name clashes in the first place?
Simple: API consistency.
I implemented printf() and putchar() just to be consistent;
for a terminal widget it's kinda important to have familiar
stdio functions available.
As the designer, I figured I should indicate why it should be
the way
it is, so folks can weigh their decisions.
People seeing printf() implemented will be right to ask "why
didn't
you call the single character method putchar()?", and it just
seems
lame to have to say it's because of an obscure platform macro
issue.
But, if it's not possible to work around, then it sounds like
there's
no choice really, and it's not even up for question, other than
what to call it.
put_char() I guess?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f23a4107-4283-4e28-b24a-5aab31d894be%40seriss.com.
[ Direct Link to Message ] | |
|
| |
