[libcaca] Time to think about an API freeze

[Sam Hocevar <sam@zoy.org>]

   Hey there. I really would like to freeze the API as soon as possible
so that we can do a release. My idea is to list everything we are
missing in the libraries, then sort it between API-dependent and API-
independent features and see whether we can implement them rapidly or
not.

   What I want is, as usual, world domination. To achieve that, we need
to have a powerful, stable API, because no one wants to rewrite software
each time the library it uses changes.

   From the top of my head and the currently rather anmaintained TODO
list, here are my plans. Not everything is really essential:

   libcucul, API-dependent:
   - brightness, contrast support for bitmaps
   - allow to select the characters that will be used for bitmap
     rendering
   - all the sprite stuff (loading, saving, blitting, transparency
     support, thinking of a storage format, etc.)
   - support for Unicode characters in the primitives (circle, lines,
     boxes, etc.)
   - bitmap output support (will require one or several custom fonts),
     maybe should be in libcaca.
   - support for more than 16 colours, maybe truecolor, maybe less
   - support for transparency (CUCUL_COLOR_TRANSPARENT)
   - ASCII/ANSI art loading functions (maybe load them as sprites)
   - old school ASCII-art handling functions, for instance mirroring
     routines that are able to change "\_o< !" into "! >o_/" or even
     into "/▔o< ¡" with Unicode support added.

   libcaca, API-dependent:
   - text edit widget with cursor support (I'm unsure about this, it
     seems pretty difficult)
   - replace the event return value with a structure so that we can put
     more information into it, such as mouse coordinates or Unicode
     characters.

   libcucul, API-independent:
   - support for double width glyphs (also needs some libcaca changes)
   - better mask support in cucul_blit()

   libcaca, API-independent:
   - Unicode support for X11 (maybe through Xft)
   - fix Unicode support for ncurses
   - Unicode support for GL
   - and Jylam wants a framebuffer output

   - [THIS PLACE FOR RENT - YOUR IDEA HERE]

   As you can see, the libcaca API will probably not change much, which
is good. libcucul however still lacks a lot of things I want. Once
we are done discussing the needed features, I suggest we just write
the prototypes for them (all the better if we can also implement them
quickly, of course) so that we can work in parallel on updating the
language bindings.

   Speaking of the language bindings, here is a list of what would be
nice to have, though it can wait long after the API freeze:
   - Perl (already here, just needs an update)
   - Python (already here, just needs an update)
   - C++ (given how object-oriented we now are, it will be a walk in the
     park)
   - C# (it's the next big thing, believe me)
   - PHP (together with the HTML output it would allow for nice web
     applications)
   - maybe Ruby, maybe Java

   And I want both test programs and documentation for each language
we have bindings for. I enjoy libcaca being slightly provocative,
technically impressive, and rather useless yet totally essential. Having
a professional documentation would add to the ambiguity.

-- 
Sam.
-- 
This is the libcaca mailing-list, see http://sam.zoy.org/libcaca/
Trouble unsubscribing? Please contact <sam@zoy.org>
List archives are at http://sam.zoy.org/libcaca/threads.html