Re: SDL Interface Development

[Eric McDonald <mcdonald@phy.cmich.edu>]

Lincoln Peters wrote:

> Well, it certainly looks like it would save a lot of coding, and would
> be more efficient than trying to use GTK+ and SDL in the same
> application!

Yes. This is true.

> I would imagine that having access to these packages would prove useful
> beyond enabling us to use ParaGUI.  I remember that it was previously
> discussed that using fonts in SDL can be awkward; I suspect that
> Freetype would dramatically simplify that.  It would also be good if we
> could transition the image library from GIF files to PNG files (thus
> freeing Xconq of certain troublesome patent issues), and libpng should
> allow us to do just that.  Although I'm not sure if zlib or Expat would
> offer any immediate noticeable benefit.

The fonts issue was simply that we needed a way to actually display the 
Pango-processed fonts on a SDL surface. SDL_Pango solves this issue, and 
Pango itself can utilize Adobe Type I, TrueType, X11 bitmap, etc... 
fonts; IIRC, some of this support comes from Pango using the Freetype 
library. So, I think that it is likely that Freetype will end up being 
among the deps for Xconq whether or not we put ParaGUI to use.

As far as libpng goes, __yes, I agree that this is a good thing. I 
believe that I mentioned some time in the not too distant past that 
utilizing libjpeg, libpng, etc... would be a good idea and would enable 
us to utilize a wider range of image formats. libpng is particularly 
useful if we want to link it into Xcscribe so that we can include unit, 
terrain, etc... images in the HTML help files.

And, if we ever did anything with the SVG library, then we could utilize 
scalable images. But, I think that putting the various libs to work is 
all a bit down the road still.

> It seems to me that lots of programs already use Pango for
> internationalization, so I don't see any harm in using it to do the same
> with Xconq, aside from the increase in size of the Windows installer.

Well, other programs certainly use it and many other external pieces of 
software. But, I have noticed that Xconq seems to tend towards 
"self-sufficiency". It does its own reading of GIF and Windows Bitmap 
files. The CVS repository on 'sources.redhat.com' has older versions of 
Tcl and Tk, and an old curses implementation which can be checked out.

I think that a reasonable compromise would be for me to take some time 
out and package stable releases of the various dependencies as both 
source and Linux ix86 binary RPM packages and in Windows installers. 
Since this has not been done at all in the case of some of the pieces of 
software, I am sure that their respective developers would probably 
appreciate this as well. But, what the Xconq project would gain from 
this is that if someone wanted to join our development efforts, he/she 
would have ready access to all the prereq packages and the packages 
would match those which Xconq was being developed against.

As far as the Windows installer goes, we will just have to see how much 
it grows. It may not be all that much, if the Win32 version of Freelords 
that I unzipped earlier today is any indicator. Most of the prereq DLL's 
that were included in its zip file were pretty small, and using LZMA 
compression (as I do with NSIS2), they would likely get the bajeebus 
squeezed out of them.

> The opossum is a very sophisticated animal.  It doesn't even get up
> until 5 or 6 PM.

The opossum's timing also corresponds to when most motor vehicles are 
generally done being moved for the day, so that it can safely slip under 
them and lick road salt from them, thereby further catalyzing the 
rusting process....

Eric