From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17713 invoked by alias); 31 Oct 2004 18:08:26 -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 17705 invoked from network); 31 Oct 2004 18:08:24 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 31 Oct 2004 18:08:24 -0000 Received: from [192.168.181.128] (unknown[67.176.41.158](misconfigured sender)) by comcast.net (rwcrmhc13) with ESMTP id <20041031180823015007age8e>; Sun, 31 Oct 2004 18:08:24 +0000 Message-ID: <41852A0E.3090002@phy.cmich.edu> Date: Sun, 31 Oct 2004 18:23:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Elijah Meeks CC: Lincoln Peters , Xconq list Subject: Re: SDL Interface Development References: <20041031061316.25283.qmail@web13126.mail.yahoo.com> In-Reply-To: <20041031061316.25283.qmail@web13126.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01376.txt.bz2 Elijah Meeks wrote: > There are only two worries I'd have with this move, > both of which are posed, I acknowledge, from a > position of relative ignorance: > > 1. We'll lose all the work done in SDL, right? No, not at all. ParaGUI works on top of SDL. I am simply proposing it to gain us some more leverage as far as GUI elements go. As of present, the SDL interface has simplistic implementations of panels and of buttons, and naught else. We are sorely lacking scrollable text for messages (which currently go to stdout), and the necessary tools to build decent setup and preferences screens. This is _not_ a rewrite. It is an augmentation. Yes, there will be some work involved in getting the C++ interface to link with the C kernel, but not that much. It is essentially a matter of marking interface functions as having C linkage, and making sure that all of the kernel includes are marked that way as well. > 2. Forcing the average user to load a bunch of > external programs. It took me awhile to get > comfortable with open-source software, coming from a > Win32 background. Loading TCL/TK, in the case of > XConq, or GTK in the case of Gimp, while pretty > standard fare for a Linux user, is very intimidating > for someone used to loading a single piece of software > to run on Windows. So if it can all be packaged as a > single install and be relatively seemless, this isn't > a big deal, but otherwise, it'll be an added hurdle > for an audience that is notable hurdle-adverse. I understand the limitations of the typical Windows user. In the past, I have faced that group of people both as a systems administrator and as a software developer. This is one of the reasons I created the Windows installer with the necessary DLL's bundled with it. You'll recall that, prior to the Windows installer, Hans only released zip archives of the Windows build once in a blue moon, and it was up to user to acquire and install Tcl/Tk. I am not anxious to return to that time. If some deps are added as a result of using ParaGUI with the SDL interface, then I will include the necessary DLL's in the installer. I do not expect this to be a big problem. As an user of the Windows installer, you should not expect that life will again become more difficult. As far as Win32 developers are concerned, I think that we can expand on the idea of standardized prereqs that I suggested yesterday. Not only can we provide the packages that are being used for Sdlconq development, but they can precompiled and put in a separate installers. I would probably target the current version of MinGW32; people using VC++ would still have to go about making their own .lib files if the MinGW32 ones proved insufficient for some reason. Eric