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: Fri, 13 Nov 1998 17:33:21 +0100 (MET)

On 10 Nov 1998, John Goerzen wrote:

> I think you're misunderstanding what I'm saying.  With that message, I 
> was not writing against multiple UI's (my opinion on those is that
> time could be better spent elsewhere, but it's not a big deal).

But there seem to be a lot of people interested in doing freeciv
development, so why not do this as well :-)

> I was 
> instead writing against "linking" in Perl or Python code into the
> program.

And I agree with you.  The GUI clients should not link with Perl or
Python.  There should be several seperate UI clients.

And this is the central idea.  Write the abstract client layer ONCE
and make a nice API.  Then you can "easily" write multiple clients
(GUI's, client-side AI's, helpers and general-purpose scripting UI's)
based on the freeciv client API.



> Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx> writes:
> 
> > 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>
> > 
> 
> 

-- 
/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]