[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thu, 2004-07-22 at 13:23 -0700, Robert Ohannessian wrote:
> Perhaps we(*) should move towards A5 instead?
> http://alleg.sourceforge.net/future/keyboard.txt
>
> At least some of it can be implemented on top of the current A4.
>
> For example,
>
> bool al_key_down(AL_KBDSTATE *state, int keycode)
>
> This would be just like the al_key() you proposed, except we leave the
> first parameter (state) reversed for future use - must be NULL in A4.
>
>
Yes, I was already browsing through http://alleg.sf.net/future/ before,
and a lot of things could go in. Angelo already offered to put in his
config system. Actually, even things like your GFX API could for the
most part be done with the A4 drivers, so we at least would have that
API. I also discovered there a completely prefixed A4 API by Grzegorz,
something which I'd apply at once. I'm getting confused of A4/A5 now
though..
(*) <- That's the main problem. Who is "we"? Someone needs to do better
than the allegro_new module or Peter and you with your A5 core
implementations. So I'm afraid looking towards A5 is simply out of the
questions, by lack of someone to do it.
Which brings us back to A4. Where we have Peter's vicious circle. Which
we can only break out of (with the current developer situation) in two
ways, both of which have something good and something bad:
1. Don't improve API, but stay backwards compatible.
2. Improve API, but don't stay backwards compatible.
Or, well, Peter formulated it like this:
> Improve the API incrementally. Maintain compatibility wherever
> reasonable.
Which is very wisely formulated, and very open to interpretation :)
I'd interpret it as, improve the API, just like e.g. myself want to do,
with all the ideas of improvement so far, including prefixing - but keep
a compatibility header (and maybe even a compatibility .c) around, so
4.0.0 apps will keep working. Ben or maybe someone else before suggested
to make "include <allegro.h>" include the compatibility stuff, and make
"include <alleg42.h>" not include it, which would solve the problem of
the compatibility being default or not.
--
Elias Pschernig