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

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

On Fri, 2002-11-29 at 04:55, Christian Knoke wrote:
> On Thu, Nov 28, 2002 at 10:33:42PM -0800, Jason Short via RT wrote:
> > 
> > [jdorje - Sat Nov 16 22:26:58 2002]:
> > 
> > > This patch provides what I consider the best features of Raimar's and
> > > Christian's patches, to implement a simple method of field sorting.
> > 
> > Here is a new patch with an important bugfix.
> > 
> > If there are any better ideas/patches for a solution to the immediate
> > problem, I would like to hear them.  But it should (1) be simple! and
> > (2) separate the non-gui-specific code into cityrepdata.c.
> 
> Thank you for your patch, which I tried with HEAD CVS.
> 
> Is this meant for stable CVS as well? Then it's ok so far, for HEAD
> I have some issues:

I had not considered whether it should go into 1.14 as a bugfix. 
Opinions?

Read the previous part of the thread (RT ticket).  This is intended as a
quick fix.  I don't think an intermediate fix is worth it.  I would like
to see a full fix, but this needs more thought (see below).

> The good thing is that I can have even multiple ranked sorting, when
> I sort for the second criteria first, and the first second, by clicking
> on the appropriate column headers.

This is not guaranteed; it's just a byproduct of GTK+-1.2's sorting
method that it preserves the old order.

> The bad thing: I can't sort the numbers in the project column at all
> (my patch was clearly superior in this).

Yes.  And yet your patch wasn't a full fix.  There are still many
sorting capabilities that it doesn't allow.

What we need to decide is what behavior we want.  What should the city
list provide?  Are there different options?  Then we can think about a
way to implement it for all GUIs.  It may not be possible for all
clients to implement the same system, but with a well-designed system
they should all be able to have similar behavior.

> Column width: The narrow (one number) columns suffer the problem
> that you don't know what they contain (because the column header
> is only 1 letter or so), or, the are too wide, using up neccessarely
> wanted space, is the header is more explanatory. So the city report
> becomes even more cryptic than it is now.

Yes, the individual columns are more confusing than the combined columns
(e.g., F/P/T).

> Possible solutions: 1) two independent lines of column headers like
> this:
> 
> --------------------------------------------
>     |    Workers    | 
> --------------------------------------------
>     | H | C | U | A |
> --------------------------------------------
>     | 0 | 4 | 0 | 0 |

This actually looks like a great interface.  But I doubt it is (easily)
possible in all GUIs, particularly GTK.

> 2) Tool tips for the column headers

I don't think that's possible in GTK.

> If the column headers were more explanatory, you might even choose to
> remove the combined columns (F/P/T) at all.

Yes, the above system could easily replace the F/P/T.  It puts the
columns into groups.

But it is questionable whether a particular GUI can implement this.  If
it can't, what should it do instead?

One issue is whether the groups have to be disabled/enabled as a group,
or whether it's possible to enable individual columns in the group.

> I want to point out, that as long as you have these combined columns,
> you could offer a sorting method for them as well (8-:

Yeah, but that takes a lot of code and doesn't offer the full
functionality.  And without thinking about the interface ahead of time,
it is likely to be very counterintuitive under some GUIs.  For instance
gui-gtk and gui-gtk-2.0 have a very different interface for sorting
columns.

> I couldn't find out what the numbers stand for in the Best attack / Defense
> coulmns: 5/3/-  except the first column which is obviously the A value.
> Tool tips would help here, too.

Yes, they would.  These values are the defensive values of the three
best defensive units in the city.

> Last thing is the plus sign the Gold numbers have. I feel it's irritating.

That's not a design issue - just remove the "+" from
client/cityrepdata.c.

-----

Some other things I'd like to see in the interface:

- Persistent sorting.  Sorting by one column and then another should be
possible.  This works under gui-gtk with my patch, but this is
coincidental.  To make it official it needs to be supported in
cityrepdata.c.

- Ability to use icons instead of text.  The "H" (happy) column should
also provide a pointer to a sprite symbolizing a happy citizen (perhaps
just the happy citizen sprite).  Supporting GUIs can use this instead of
"H".  For F/P/T I believe this will require new sprites.

- Ability to choose which element of a field to sort by.  _If_ the
combined fields are kept around (your grouped field system is much
better IMO), then it should be possible to sort by either F, P, or T
from the F/P/T field, in either direction.

jason