[Freeciv-Dev] Re: (PR#949) city report fields don't sort well

["Jason Short via RT" <rt@xxxxxxxxxxxxxx>]

Christian Knoke wrote:
> On Thu, Nov 14, 2002 at 12:24:56AM -0800, Jason Short via RT wrote:

>>The problem with the patches provided so far is that they only try to
>>treat the existing (text) fields of the city report as numerical fields,
>>by scanning them for numerical data.  Worse still, they will only work
>>for one GUI (gui-gtk).
>>
>>One alternative is to take the existing patches, and use them to provide
>>a GUI-independent comparison function.  The functions provided by the
>>patches do essentially the same thing: provide a comparison function to
>>compare two strings that may or may not be integers.  This function
>>could be used by all GUIs (at their option) to implement better sorting.
>> A combination of the two existing patches (using Raimar's comparison
>>code with Christian's GTK code) would be my preference.
>>
>>This is probably a first step.
> 
> 
> That's IMO a good thing.

I agree.  Would you like to provide a patch?  IMO it should use Raimar's 
code to compare the text fields, but the GTK elements of this function 
should be removed and it should be put into cityrepdata.c.  Then a GTK 
wrapper function is needed, along the lines of your patch.

>>But a lot more is possible, IMO.
>>
>>The above design will allow sorting of simple numeric fields, and in
>>conjunction with Tuomas Airaksinen's patch to give the city report more
>>available fields (already applied), this may be sufficient.  But
>>consider the "Surplus F/P/T" field.  Under the simple design above, this
>>field will always be sorted by the F (food) category.  While this is an
>>improvement on the current situation (sorting it alphabetically), it is
>>not what we really want.  As a gamer, what _I_ would want is the ability
>>to have this field be sorted (in either direction) according to either
>>the F, P, or T fields, or (perhaps) according to their sum.  (Note that
>>these fields can now be obtained as separate entries in the dialog, so I
>>can already get the behavior I want - but it is not grouped as nicely.)
>> When I sort the "currently building" field I would like to see it
>>sorted not alphabetically, but first by building type (alphabetically,
>>or by type; whatever) and then by turns remaining to build.  When I sort
>>the "best defenders" field (very slick idea, Tuomas) I would like to be
>>able to sort by either the best unit, or the sum of the best two units,
>>or the sum of the best three.
>>
>>With these abilities I think the city report dialog could be made both
>>simpler and more powerful.
>>
>>Doing all of this elegantly (note that the alternative solution is far
>>from elegant, so the bar is pretty low) is not easy, but I think it is
>>possible.  It is made more difficult because the different GUIs may have
>>very different interfaces: even gui-gtk and gui-gtk-2.0 are quite different.
>>
>>I've had some thoughts on how to do this, but I'd like to get others'
>>opinions on it.  First of all: would these capabilities be a good thing?
>> Secondly: how would you go about implementing it?  (Or, better yet, can
>>you provide a patch?).
> 
> 
> Yes, these would be a good thing. Problem is, to make a good usuable and
> intiutive GUI, which is not overloaded.
> 
> E.g. Raimer's sorting for F/P/T stressed the user with counting up to 8
> clicks on the same button. IMO this must be addressed for people with less
> than five years computer experience (or so, you know what I mean ...)

Right, without an intuitive graphical interface it is confusing (but no 
worse than the current situation for new players).

> There are other things which could be displayed within the city report,
> e.g. the existing buildings, the supported / stationed units, how many,
> which kinds, veterans or not ...

This is a separate issue, I think, and one that was partially addressed 
by PR#737.

> Question is, whether these things should all be placed into one dialog,
> or can they be split up in a good manner. Suggestions welcome.

Indeed.

> If you want to make good use of the CR right now, you need a 1024*768
> screen. I don't like that. If it grews even more, I like it less ;)

It's been pointed out before that freeciv is hard to use with anything 
less that 1024x768.

> Some ideas: you could make use of the right mouse button for popup menues
> (sorting/changing), and use the middle button for additional information
> to be displayed.

What is needed is a way that an arbitrary UI can interface with the 
backend code that does all the "hard" work.

jason