Re: SDL Interface Development

[Lincoln Peters <sampln@sbcglobal.net>]

On Sat, 2004-10-30 at 15:15, Eric McDonald wrote:
>    With the help of a powerful scrying tool known as Google, I have 
> apparently discovered an easy way out: ParaGUI, 
> http://www.bms-austria.com/projects/paragui/
> It looks to have most every GUI element that I would want and it would 
> undoubtedly shave _months_ off the development of the SDL interface.
> However, like most things, this comes at a price.

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!

> 
>    The price is twofold:
> (1) The ParaGUI API is in C++. This means that Xconq's SDL interface 
> would have to be converted to C++ and things going to and from the 
> kernel would have to be carefully declared extern "C". I am tempted to 
> say this is worth the trouble. I realize that this would break Xconq's 
> tendency toward C89 compliance. However, the "damage" would be limited 
> to a single user interface, and the kernel should escape unscathed.

I think that using C++ in Xconq would be beneficial in the long run for
more reasons than just ParaGUI.  I know that if I was ever going to
tackle a problem like AI programming, I would be *very* reluctant to do
so in a language that is not object-oriented.

> (2) ParaGUI has a number of dependencies: Freetype, zlib, libpng, and 
> Expat. None of these should be a problem on most modern Linux 
> distributions. On Windows, these all are available, thanks in part to 
> the Gimp on Win32 project and other reasons. However, any required DLL's 
> would have to be bundled with the Windows installer thereby increasing 
> its size, perhaps significantly. Some of the space could probably be won 
> back once we get to a point where the Tcl/Tk interface no longer needs 
> to be provided. Also, I could provide a separate complete install and 
> upgrade install. Of course, anyone wishing to do SDL interface 
> development on the Win32 platform would have to seek out the necessary 
> libraries and headers and install them. Documentation could help aid 
> that quest, but the extra work could still be considered an extra 
> hurdle. On non-Linux, non-Win32 platforms some compilation of the 
> necessary libs would probably be required.

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.

> 
>    A while back ago, we considered SDL_Pango for handling of 
> international and exotic text. Pango (which SDL_Pango obviously 
> requires) is not without dependencies either. So I think point (2) is 
> something worth considering. How much should Xconq be able to stand 
> alone? And how much should we cave in to rapid development at the 
> expense of raising the hacker "cost of entry", so to speak?

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.


There is probably a simple way to reduce the size of the Windows
installer, at least for those users who already have the packages that
Xconq depends on, but I'm not yet sure how that would be done.  Maybe if
someone would port apt-get to Windows...

---
Lincoln Peters
<sampln@sbcglobal.net>

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