Re: [AD] Proposal for first step towards new api

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2001-12-18, Sven Sandberg <svsa1977@xxxxxxxxxx> wrote:
> Grzegorz Adam Hankiewicz wrote:
> >  http://alleg.sourceforge.net/future/allegro_new_api_draft_one.txt 
> 
> Here are some of my thoughts:
> 
> A good start, though I agree with Vincent about internals and with Eric
> about `init()', `exit()' and platform specific identifiers. I also
> disagree with Henrik about using `alvar_' for variables and `aldef_' for
> macros (it doesn't add any useful information anyway; see also the ahack
> document about hp_q_r2mzw_hungarian notation :-) Also, good idea to
> prefix `line()', `arc()' & co with `draw_'.

I agree with all of that, and also Laurence's naming scheme.

> Another idea I just got is to make a distinction between `al_font_8x8'
> (which is the 8x8 font that comes with Allegro and is semantically
> read-only) and `al_gui_font' (which defaults to `al_font_8x8' and can be
> changed if you want the gui to use another font). This can be
> particularly useful for add-ons that need the 8x8 font, plus it seems
> more logical.

Good idea, although it remains to be seen if the GUI will get a major
overhaul, e.g. if we support multiple dialogs (as discussed a while
ago on the guibrella list), then a single global is not enough.

> Does `i_love_bill' still make sense? I remember we discussed this a
> while ago but I don't remember if we came to any conclusion.

Probably good to internalise it.

> Is `xor_mode()' still useful? I don't mean we should remove the ability
> to draw xor'ed, I mean we should force people who draw xor'ed to use
> `drawing_mode()', because I think it is a too uncommon thing to do to
> have a shortcut for it.

I hope it gets removed.

I'd also like to remove `drawing_mode' completely, and only support
what are currently DRAW_MODE_SOLID and DRAW_MODE_TRANS.  But I'm
biased because I never used the XOR or pattern drawing modes.

Also, I think there is too much of a difference because 8-bit
translucency and other colour depths.  Maybe something to change,
if possible.

> Do you think we should change e.g. `int key[]' to 
> `inline int al_key_is_down(int)' or something like that? It seems a bit
> more logical because you shouldn't write to it and it's not _that_ time
> critical.

Or maybe just `al_key_down'.  But I think it's a good idea (functions
are better than variables in lots of ways).

> I also think it can be good to wait a little more to actually implement
> everything, until 4.0 feels more stable, so that we reduce the number of
> bugfixes that need to be applied to both prefixed and non-prefixed
> versions. Sure, it will be a nice improvement, but if we lived with the
> old API for years it can't hurt to keep it a month or so more. It's not
> like it seems likely that people are going to forget about it :-) But
> it's of course still a good idea to discuss it.

Anyone object?

Also, would a separate CVS module for 5.0 be better than to branch off
4.0?


Just a little more:

I don't like how there are both `al_exists' and `al_file_exists'.
(I know I said being lazy is good, but that's excessive :-)

I prefer `al_file_select' to `al_show_file_selector'.  It would match
`al_gfx_mode_select' better (as it does now).

`al_gfx_mode_select' and `al_gfx_mode_select_ex' can be collapsed into
one, by checking if the `color_depth' parameter is NULL.

I'll stop too for now and wait for draft two.