Re: [AD] destroy_bitmap after allegro_exit and get_config_string before allegro_init

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Thu, Oct 11, 2001 at 05:47:42PM +0100, Vincent Penquerc'h wrote:
> On a parallel topic, I just remembered one thing: set_uformat must
> be called before allegro_init. allegro_init must be called before
> get_config_string. get_config_string must be called before set_uformat
> if one wants to have an option in the config file to set the text
> format to be used. The only option is to initialize allegro, read
> the text format to use, exit allegro, call set_uformat, then initialize
> allegro again. Not very clean. Unfortunately, I see no easy way out
> of this. If anyone does, comments are most welcome.

Certainly a nice situation. First I thought of separating the string
functions, but then I noticed that the problem is with allegro's internal
strings, so probably the only solution here is making set_uformat work
at _any time_.

AFAIK the problem with set_uformat is that newly generated lib's string
will be in different formats. You have of course another problem with the
"what format is the file in" in first place, but presuming that you want
this for a specific aplication is no problem on your part to presume
the user will always keep the config file or whatever in a specific
encoding, possibly suggesting encoding overrides with double extensions:
readme.utf8.txt, readme.u16.txt, or whatever in the filename.

As for the allegro problem, I think that the string issue could be solved
if Allegro was meant to use internally strings always in a specific
encoding (utf8?), and where communication with real world is needed,
either allegro or the user have to convert them to the "output encoding",
whatever it is. Another solution would be to make Allegro reconvert all
strings to the new encoding.

Is this the only problem with set_uformat or are there other limitations
in relation with Allegro's internal use of strings?

-- 
 Grzegorz Adam Hankiewicz   gradha@xxxxxxxxxx   http://gradha.infierno.org/



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/