Re: [AD] GUI - d_ctext_proc, file_select_ex, gui_textout_ex

[Esaelon@xxxxxxxxxx]

In a message dated 6/15/03 9:30:20 AM Eastern Daylight Time, 
elias@xxxxxxxxxx writes:

>  > >  Does this fix the problem?
>  > Nope.  See, the text is centered on the x.  The scare_mouse_area() code 
>  Not in my version, there it centers around the center:
Interesting.  Must be new since 4.1.9...


>  So, if your box is from (0,0) to (100,10), then the text is centered
>  around (50,0). You just have to make sure w is big enough, like with any
>  other GUI element. 
Another bit I don't get.  Why does Allegro GUI allow objects to draw outside 
of their specified size on the screen?  Seems it would be fairly 
simple/logical for it to back up the old clip rectangle and call set_clip() before/after 
sending MSG_DRAW.  It would cause problems with objects that refused to set a 
proper size before drawing, but honestly, the problems caused by NOT having a 
proper size set are no better.

>  True. I don't think it's worth adding yet another textout function
>  though. But maybe a general way to retrieve the dimensions of any GUI
>  element could be made, and this could then be used in your case.
>  Something like: get_minimum_dimensions (DIALOG *d, int *w, int *h). And
>  if you pass a DIALOG with proc == d_text_proc, it would return the
>  desired w and h. For other dialogs, like d_bitmap_proc, it would pass
>  the bitmap dimensions. For most dialogs, there would be a border added.
>  Not sure what custom dialogs should return though. Maybe implement it
>  with 2 new message D_GET_MIN_W and D_GET_MIN_H? I'm just thinking aloud
>  though, not sure it would be that useful..
That seems like a pretty decent idea.  Another could be a message for helping 
objects deal with screen mode changes, or at least screen depth changes - 
but, I guess, at the moment that's not such a big deal with Allegro's GUI API, as 
it does not really have a manager for multiple active (i.e. background) 
dialogs.

Then again, there's also my gripe about not being able to restrict the range 
of available modes for gfx_mode_select* (and the API compatibility trouble of 
adding a new mode since there already is an _ex version), as well as the fact 
that dialog objects, at least the standard set, can not seemlessly switch from 
palettized to truecolor modes; as the color entries are assumed to be native 
for the mode, and hence would have to be recomputed for all active dialog 
objects.  My suggestion would be something along the lines of a dialog flag of the 
sort D_COLORS_PALETTIZED/D_COLORS_TRUECOLOR, or D_COLORDEPTH_#.  This spawns 
more API  compatibility problems... unless you have another flag in the same 
set, a default such as D_COLORS_NATIVE (compatible with current depth).

>  Heh, yes, I noticed when I was searching for the post.. seems Eric
>  already has a fix for it.
Good to hear.  Eagerly awaiting 4.1.10 release.


More later,
Charles Bilyué