From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14101 invoked by alias); 30 Oct 2004 23:28:19 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 14091 invoked from network); 30 Oct 2004 23:28:17 -0000 Received: from unknown (HELO smtp800.mail.sc5.yahoo.com) (66.163.168.179) by sourceware.org with SMTP; 30 Oct 2004 23:28:17 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@64.175.251.169 with plain) by smtp800.mail.sc5.yahoo.com with SMTP; 30 Oct 2004 23:28:17 -0000 Subject: Re: SDL Interface Development From: Lincoln Peters To: Eric McDonald Cc: Xconq list In-Reply-To: <41841290.3040905@phy.cmich.edu> References: <41841290.3040905@phy.cmich.edu> Content-Type: text/plain Message-Id: <1099179160.26829.4323.camel@localhost> Mime-Version: 1.0 Date: Sun, 31 Oct 2004 04:10:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01367.txt.bz2 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 The opossum is a very sophisticated animal. It doesn't even get up until 5 or 6 PM.