Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2004:
[Freeciv-Dev] Re: (PR#8528) Move text building functions into one file
Home

[Freeciv-Dev] Re: (PR#8528) Move text building functions into one file

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8528) Move text building functions into one file
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Tue, 20 Apr 2004 11:10:20 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8528 >

On Tue, Apr 20, 2004 at 10:58:29AM -0700, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8528 >
> 
> > [i-freeciv-lists@xxxxxxxxxxxxx - Fri Apr 16 17:07:54 2004]:
> > 
> > The gui-fs has a lot of text building functions. The mapview has
> > already 300 lines and this will double in size. Most of them are
> > various labels and tooltips. I want to have this extracted from the
> > "core" mapview. Either in client/gui-fs/text.c or client/text.c.
> 
> A good concept.  I'm not sure if the file name is good, but I can't
> really think of a better one.  text_common seems unnecessarily long.

Hehe. This time I suggest a short time and also people don't like it ;)

> I don't really like the overuse of macros in text.c.  A macro just to
> declare a buffer?

AND set it to the empty string. The macros are really there to ease
the rest of the functionbodys.

> I also don't like the large number of static arrays.  When you look at
> an individual function a static array seems like a good choice.  But we
> have a large number of static arrays of constant size.  When one string
> needs the array to be longer (and it will) all arrays will have to be
> made longer.  Currently there are 13 arrays of size 256 = 6k.  Where is
> the cutoff point where these arrays are not worthwhile?  10k?  50k?  1M?
>  Will we reach that point?  I don't know, but it seems ugly.

I agree.

> The alternative is to have the caller pass in a buffer and bufsz.  This
> takes a little more code but frees up some memory.  Is this a good
> trade-off?

No.

> Another alternative is to have just one buffer for the whole file.  This
> seems very error-prone.

It is.

I will think about a dynamic allocated buffer. And a static pointer.


> I'd like to give variables more consistent names.  Instead of
> (xtile,ytile) or (x,y) for a map position we should use (map_x,map_y).

Ack. I just moved it around.

> Aside from these localised issues I think it should go in soon.  Of
> course it's not very helpful unless we convert other GUIs to use it
> as well.

Good.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Microsoft does have a year 2000 problem. I'm part of it. I'm running Linux.




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