Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: server console cleanup patch v2
Home

[Freeciv-Dev] Re: server console cleanup patch v2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: server console cleanup patch v2
From: Reinier Post <rp@xxxxxxxxxx>
Date: Tue, 8 Jan 2002 18:11:06 +0100

On Tue, Jan 08, 2002 at 01:07:31PM +0100, Per I. Mathisen wrote:

[among other things]

> > > but since this struct is not used for lookups during
> > > the game, there is no need to encode the ruleset info into a new format.
> >
> > There will be if the client GUI to set server options is to support
> > server options that do not exist at the time the client is compiled.
> 
> No. Look, what I suggest is a GUI dialog which is a tree widget, where
> each option is added as a node on run-time, and each node is interpreted
> on the fly to generate a GUI interface for the option. Think Windows
> "regedit" or MacOS NetInfo editor.
> 
> This is not very hard to do, because of the very intelligent way the
> registry works. To quote common/registry.c a bit, even the complex
> tabular format is be broken down into easily represented types:

Yes.  Sorry, I thought you were referring to the structs in stdinhand.c.
 
>  89   - Tabular format:  The lines:
>  90       foo = { "bar",  "baz",   "bax"
>  91               "wow",   10,     -5
>  92               "cool",  "str"
>  93               "hmm",    314,   99, 33, 11
>  94       }
>  95   are equivalent to the following:
>  96       foo0.bar = "wow"
>  97       foo0.baz = 10
>  98       foo0.bax = -5
>  99       foo1.bar = "cool"
> 100       foo1.baz = "str"
> 101       foo2.bar = "hmm"
> 102       foo2.baz = 314
> 103       foo2.bax = 99
> 104       foo2.bax,1 = 33
> 105       foo2.bax,2 = 11
> 
> Since they are broken down in this manner, they can easily be dynamically
> rebuilt into GUI controls that are more human readable than a mere list of
> values.
>
> > > The client must encode the data in a GUI-dependent fashion, though.
> >
> > ?? Why?
> 
> Because the data has to be stuffed into a tree widget. That doesn't mean
> the data can't be represented in some other way as well, but I don't
> think that is necessary.

Is this tabular format what you mean by "GUI-dependent"?
I thought you meant it would differ for Xaw, GTK+, Amiga ...

[...]

[interactive command line control]
> That would not be too hard, but I don't see the need for it.
> 
> > Not for civserver.freeciv.org use.  We have a wrapper there that talks with
> > civserver over stdin/stdout.
> 
> Ok. It would not be too hard to rewrite server/stdinhand.c to use the new
> setup. Or rip it out to create a new controller program like Raimar
> suggested. I am undecided on which is better.

As far as I can see this is only the next step.  Above you deal with
server->client communication; this can be implemented and used for a read-only
GUI.  The next step is to decide how to communicate update requests from
the GUI commands to the server.  This can also use a syntax based
on the registry file format.  Then you can have an update interface
for registry items.

The next step would be to make server/stdinhand.c operate on registry data
structures as well.  /set and /show would either die or be adapted to work
on arbitrary bits of registry.  I'd prefer them to live on because command
line control is very convenient (especially for wrapper scripts).

  Truly,

-- 
Reinier


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