Complete.Org: Mailing Lists: Archives: freeciv-dev: November 1998:
Re: [Freeciv-Dev] FreeCiv Shareware competitor
Home

Re: [Freeciv-Dev] FreeCiv Shareware competitor

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: John Goerzen <jgoerzen@xxxxxxxxxxxx>
Cc: Mitch Davis <mjd@xxxxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] FreeCiv Shareware competitor
From: Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx>
Date: Sat, 7 Nov 1998 16:04:46 +0100 (MET)

On 6 Nov 1998, John Goerzen wrote:

> Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx> writes:
> 
> > It would also open up for writing an interface to popular scripting
> > language.
> > What about a Perl or Python interface for writing you own helpers ?
> 
> 1. Portability.
> 2. Complexity.
> 3. Size.
> 4. Speed.
> 
> I think that about sums it up :-)
> 
> (Granted, #1 is somewhat weaker than the others)

I don't get it...

1) Seperating the GUI (widgets and stuff) from the rest
   of the client code would make it very easy (or at least
   easier) to write a new UI.  Could be a scripting ui or
   the next fancy gui toolkit coming up (or some ugly M$
   toolkit).

2) Seperating the code this way might not decrease the overall
   complexity.  More complexity will be put in the framework
   code, but the two remaining parts (the gui and the game-stuff)
   should each be less complex than the current all-in-one
   client.

3) Practically the same as #2. But I don't think that the added
   size will be very large.

4) Hmmm.  as #3.


As I see it #1 and #2 would be great properties for freeciv.
#3 and #4 should not bring around any big annoyances.
The win is definitly #1.  Having multiple UI's are generally
what makes any client good.

AFAIK what we are discussing here is the way ALL Open Source
projects should go.  We have so many great applications. If
they all were designed like this, then it would be much easier
doing what the KDE folks are doing with lots of apps.

-- 
/Esben  (bart@xxxxxxxxxxxxxx)

: But for some things, Perl just isn't the optimal choice.

(yet)   :-)
             -- Larry Wall in <199702221943.LAA20388@xxxxxxxx>



[Prev in Thread] Current Thread [Next in Thread]