From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28681 invoked by alias); 31 Oct 2004 06:34:00 -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 28672 invoked from network); 31 Oct 2004 06:33:59 -0000 Received: from unknown (HELO gencom001.gencom.us) (208.45.97.129) by sourceware.org with SMTP; 31 Oct 2004 06:33:59 -0000 Received: from localhost (localhost [127.0.0.1]) by gencom001.gencom.us (Postfix) with ESMTP id 388C77DBC for ; Sat, 30 Oct 2004 23:34:33 -0700 (PDT) Received: from gencom001.gencom.us ([127.0.0.1]) by localhost (gencom001.gencom.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11099-10 for ; Sat, 30 Oct 2004 23:34:14 -0700 (PDT) Received: from [192.168.0.100] (home [67.171.201.213]) by gencom001.gencom.us (Postfix) with ESMTP id DEAAC7DB1 for ; Sat, 30 Oct 2004 23:34:13 -0700 (PDT) From: "D. Cooper Stevenson" Reply-To: cstevens@gencom.us Organization: GenCom To: xconq7@sources.redhat.com Subject: Re: SDL Interface Development Date: Sun, 31 Oct 2004 06:54:00 -0000 User-Agent: KMail/1.6.2 References: <41841290.3040905@phy.cmich.edu> In-Reply-To: <41841290.3040905@phy.cmich.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410310637.52853.cstevens@gencom.us> X-Virus-Scanned: by amavisd-new at gencom001 X-SW-Source: 2004/txt/msg01370.txt.bz2 On Saturday 30 October 2004 22:15, Eric McDonald wrote: > Today I was thinking about everything that still needs to be done on > the SDL interface. There's a lot. > > 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/ Okay. > 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". > (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. I think the benefits simply outweigh the size concern. I stress that we'll need to be disciplined about making Xconq as lean as possible to avoid 'cruft.' > 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. Right. [snip] > 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? Ideally the SDL GUI builder would compile the SDL code such that only libsdl were required for Xconq (save libpng, etc.) If the hacker cost of entry were a bit high, I think that's okay if we discipline ourselves, as you outlined, to provide Howto documentation to facilitate them. I am willing to commit to writing this documentation. > > One last note, I am not saying that moving to ParaGUI is without > work. Probably a widget would have to be created to contain the main map > and minimap. But, it looks like we get things like themes (font sets, > background images and gradients) quite easily, and this is something we > all wanted from/expect of the interface. Oh, of course. Their will certainly be bumps. I think that getting some interfaces up that really look sharp-even if they are in development-could definitely attract quality developers. This irons out bugs quicker and the cycle repeats itself by attracting more developers. In short, the benefits in my view seem to far outweigh any potential negatives so long as we are disciplined to adhering to quality quality standards while developing the port. -Coop