[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Since I've heard you plan to release quickly 4.1.11, may I suggest strongly
> that you rename d_ctext_proc in d_ctext_proc_ex. Because it is a *big*
> difference. I was quite surprised to see text half outside the alloted
> area.
The question is, why do you set a "normal" width for d_ctext_proc()? The
string will be partially outside of the box whatever width you choose. So I
assumed that the width used with d_ctext_proc() is almost always 0 or 1.
Note that this is necessary to properly center the dialog.
> There's an attached patch that defines d_ctext_proc_ex with the new
> behavior and d_ctext_proc as a deprecated function. Note that this patch
> still breaks compatibility on gui_ctext_proc (i.e. client code that wants
> to set gui_ctext_proc need to re-write their function).
This is unfortunate, but the current behaviour of d_ctext_proc() _is_ broken.
I think that, because of the assumption above, the compatibility breakage
will be relatively minor for legacy Allegro programs. I should have written
a blurb in api._tx though (patch attached).
> My own opinion (for what it's worth) is not to apply my patch but to revert
> the patch on ctext proc to the old implementation (even if it's not very
> wise and creates problems with centre_dialog).
It's actually worse than that: we really need a true bounding box for the new
GUI mouse scaring logic. Otherwise we left artifacts on the screen.
> Oh well...
Yes, I would probably have said that too :-)
--
Eric Botcazou
--- /home/eric/cvs/allegro/docs/src/api._tx Tue May 20 19:09:20 2003
+++ allegro/docs/src/api._tx Thu Jun 26 20:52:12 2003
@@ -97,6 +97,10 @@
file_select_ex() now treats '(+)d' as it does for any other attributes in
the extension string which is passed to it: only directories are included
and, among them, only those with the correct set of attributes.
+<li>
+ d_ctext_proc() now behaves like d_text_proc() and d_rtext_proc(), that is
+ it takes into account the bounding box to calculate the position which the
+ string is centered around. It previously used only the x field.
</ul>
@heading