[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libcaca] Re: Time to think about an API freeze
Sam Hocevar wrote:
From the top of my head and the currently rather anmaintained TODO
list, here are my plans. Not everything is really essential:
I-just-woke-up-and-I-need-a-coffee comments :
libcucul, API-dependent:
- allow to select the characters that will be used for bitmap
rendering
Throwing a silly idea, on several drivers (libcaca related, so), there's
a way to change the character set. I'm thinking here about graphical
drivers (X11, OpenGL, mostly), but also some text drivers (conio,
kernel, as VGA font is easily alterable). It remains a problem for the
other drivers (SLang, ncurses, win32, network), as there's no way (to
me) to change it. It was my silly idea of the day.
- bitmap output support (will require one or several custom fonts),
maybe should be in libcaca.
in fact it fits perfectly with idea of framebuffer driver. Like network
driver, which uses ANSI exporter to get a displayable representation of
the current canvas, the framebuffer driver could use a bitmap output.
And it'll pave the way for more generic formats, such as png, jpg, etc
(although I don't think that's the goal of libcucul/caca to handle such
formats)
- support for more than 16 colours, maybe truecolor, maybe less
One big lack in libcaca is that it doesn't handle grayscale only
outputs. It makes a grayscale image look quite ugly compared to aalib.
Think about ASCII output, for example, or B&W devices (old monitors,
mainly, but printers, and tiny LCD displays, too).
- 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.
Good luck man, you'll transform a pure ascii sprite (\_o<) to unicode
one (/▔o<), and appart from having a generic UTF8 font with limited
characters set dealing with all known ascii "rotations", it'll be hard.
Not to mention all drivers can't support unicode.
libcaca, API-dependent:
- text edit widget with cursor support (I'm unsure about this, it
seems pretty difficult)
We already talked about this, I'll keep the think I'm working on secret
for now, but yes, it'll be difficult without having a libcaca driven
event loop. Or it'll just suck. Ideas are welcome.
libcucul, API-independent:
- support for double width glyphs (also needs some libcaca changes)
Again, that'll be quite straightforward for graphical drivers (X11,
OpenGL, Framebuffer), but nearly impossible on text ones. More infos are
welcome.
libcaca, API-independent:
- Unicode support for GL
Needs a font, we'll really need to embbed one in the core.
- and Jylam wants a framebuffer output
Already discussed;
- [THIS PLACE FOR RENT - YOUR IDEA HERE]
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)
The "just" word is maybe a bit misused. Talking about python binding for
example it'll take hours, there's now a lot of work, and two separate
libraries to work on. I guess that's the same problem for Perl one, but
anyway, it needs to be done. I was just talking about "just" word :)
- C++ (given how object-oriented we now are, it will be a walk in the
park)
I can handle this one if noone else is interrested.
- C# (it's the next big thing, believe me)
It'll be a walk in the park as well, I'll take care about this one for sure.
- PHP (together with the HTML output it would allow for nice web
applications)
PHP bindings looks to be a pain is the ass to write, not to mention PHP3
(forget this one?), PHP4, PHP5, PHP6 (not released yet IRRC)
- maybe Ruby, maybe Java
Feel free :)
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.
So we need a real documentation. I mean, we already have a doxygen one,
but we need some PDF's, 1 or more Powerpoint slides for Imagina, a bunch
of technology evangelist (we maybe know a fat one, but until we get
$100.000,00 we won't be able to hire him) (and for that we'll need to
take a .com domain and add a blog for each developper)
My conclusion : there's a lot of work, but API in itself seems quite
stable, I guess a release is not that far, talking about days or weeks.
--
--
Jean-Yves Lamoureux
--
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