From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16817 invoked by alias); 19 Nov 2003 22:08:11 -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 16810 invoked from network); 19 Nov 2003 22:08:10 -0000 Received: from unknown (HELO outbound28-2.lax.untd.com) (64.136.28.160) by sources.redhat.com with SMTP; 19 Nov 2003 22:08:10 -0000 Received: (qmail 21838 invoked from network); 19 Nov 2003 22:08:09 -0000 Received: from 66-52-250-209.sttl.dial.netzero.com (HELO vangogh) (66.52.250.209) by smtpout01.lax.untd.com with SMTP; 19 Nov 2003 22:08:09 -0000 From: "Brandon J. Van Every" To: "xconq" Subject: RE: OT Python stuff (was RE: Python in Xconq) Date: Wed, 19 Nov 2003 22:14:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <20031119153130.GM387@adlp.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-SW-Source: 2003/txt/msg00808.txt.bz2 Bruno Boettcher wrote: > > uhm perl-gtk, perl-tk? There is also Py + tk, pygtk, pySDL, pyKyra... basically Python has all those typical bindings too. Everyone is going to have their favorite language. If we can't settle on someone else's language, then we need interop capabilities. Which furthermore implies an architecture where that's possible / reasonable without pouring blood on the table. I think a major OO-ification of the code base needs to happen to make it usable / extensible to people who aren't intimately familiar with it already. We need an OO migration path. Nobody has the resources to swallow the problem all at once, there are hundreds and hundreds of functions to contend with. Eric McDonald wrote: > > (1) Richard mentioned to me yesterday that each additional piece > of external software that becomes an Xconq dependency is an > additional annoyance. If you build tkconq then you need Tcl/Tk, > and if you build sdlconq then you need SDL. Do we really want to > say that we also need Perl (which is fairly ubiquitous on Linux, > but not necessarily so on other platforms) or Python (which is > admittedly a nice language, but still not as widespread as Perl, > AFAICT)? If you are a developer, and there are docs on how to install all these packages, and they actually work, then you have no buisiness complaining. If you are a game player, then everything has to install as one big app, so that people don't have to chase it. Python has to be embedded, Perl has to be embedded, TCL has to be embedded.... Cheers, Brandon