[no subject]

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


>  - Get rid of (some) global variables and states. E.g. `text_mode()'
> could be an argument to `textout()' rather than a global variable. (I've
> never understood why background and foreground color should be treated
> differently in the API.) I don't know if it is worth the effort though.

I wholeheartedly agree. I'd be glad to help there :)

-- 
Vincent Penquerc'h 

------_=_NextPart_001_01C1616E.CC17B500
Content-Type: text/html;
	charset="windows-1252"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: [AD] official beta (Re namespace again)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; &gt; Why ? everything in alcompat.c can be defined out by </FONT>
<BR><FONT SIZE=2>&gt; OLD_ALLEGRO_API,</FONT>
<BR><FONT SIZE=2>&gt; &gt; and thus not defining it would essentially link against an </FONT>
<BR><FONT SIZE=2>&gt; empty file.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Do you mean:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; (1) alcompat.c is in liballeg.a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; (2) alcompat.c is in liballegcompat.a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; (3) the user has to add alcompat.c to his project</FONT>
<BR><FONT SIZE=2>&gt; ?</FONT>
</P>

<P><FONT SIZE=2>I mean (1).</FONT>
</P>

<P><FONT SIZE=2>&gt; If (1) or (2), then #defining OLD_ALLEGRO_API in your own source file</FONT>
<BR><FONT SIZE=2>&gt; has no effect on the library. If (3), then it still requires </FONT>
</P>

<P><FONT SIZE=2>Right. This would be a switch in allegro building, like, say, build the</FONT>
<BR><FONT SIZE=2>lib with support for this or that feature. But then, I see a counter</FONT>
<BR><FONT SIZE=2>argument there, which I had not thought of:</FONT>
</P>

<P><FONT SIZE=2>&gt; This pretty much requires a new name for allegro.h and liballeg.a,</FONT>
<BR><FONT SIZE=2>&gt; because people may want both 5.* and 4.0 installed at the same time.</FONT>
<BR><FONT SIZE=2>&gt; What about allegro5.h and liball5.a ?</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; Ah yes. One wishes for references. We could possibly do something</FONT>
<BR><FONT SIZE=2>&gt; &gt; about that with those:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; int &amp;allegro_mouse_x = mouse_x;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No, this only works in C++, not C.</FONT>
</P>

<P><FONT SIZE=2>Which is why I only wished :)</FONT>
</P>

<P><FONT SIZE=2>&gt; Well, if we compile two libraries in any case, then what do </FONT>
<BR><FONT SIZE=2>&gt; we gain over</FONT>
<BR><FONT SIZE=2>&gt; having them in two separate distributions (4.0 vs. later), as </FONT>
<BR><FONT SIZE=2>&gt; in Peter's</FONT>
<BR><FONT SIZE=2>&gt; 2nd suggestion? This is practically the same as what you </FONT>
<BR><FONT SIZE=2>&gt; propose, except</FONT>
<BR><FONT SIZE=2>&gt; we don't need any compatibility header.</FONT>
</P>

<P><FONT SIZE=2>It kind of bothers me to have this fork, for no reason that compels me.</FONT>
<BR><FONT SIZE=2>Having a branch with unprefixed stuff that will have to be maintained</FONT>
<BR><FONT SIZE=2>(somehow), without a foreseable end. Merging patches from the HEAD might</FONT>
<BR><FONT SIZE=2>prove more and more troublesome as HEAD evolves, becoming a real burden.</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; I seem to not find this post. Can anyone forward it to me please ?</FONT>
<BR><FONT SIZE=2>&gt; &gt; I have answers to it, but not Peter's first one, I must have deleted</FONT>
<BR><FONT SIZE=2>&gt; &gt; it somehow (I only have &quot;[AD] to prefix or not to prefix (sigh)&quot;)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; OK, I'll forward it (so other people can stop forwarding it now :-).</FONT>
</P>

<P><FONT SIZE=2>Got it, cheers :)</FONT>
</P>

<P><FONT SIZE=2>From this original post:</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp; - Get rid of (some) global variables and states. E.g. `text_mode()'</FONT>
<BR><FONT SIZE=2>&gt; could be an argument to `textout()' rather than a global variable. (I've</FONT>
<BR><FONT SIZE=2>&gt; never understood why background and foreground color should be treated</FONT>
<BR><FONT SIZE=2>&gt; differently in the API.) I don't know if it is worth the effort though.</FONT>
</P>

<P><FONT SIZE=2>I wholeheartedly agree. I'd be glad to help there :)</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Vincent Penquerc'h </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1616E.CC17B500--



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