Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2003:
[Freeciv-Dev] Re: (PR#2607) city report fields still don't sort perfectl
Home

[Freeciv-Dev] Re: (PR#2607) city report fields still don't sort perfectl

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdwheeler42@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2607) city report fields still don't sort perfectly
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Tue, 23 Sep 2003 21:21:22 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Tue, 23 Sep 2003, Jason Short wrote:

> On Tue, 23 Sep 2003, Christian Knoke wrote:
>
> > On Tue, Sep 09, 2003 at 08:56:26AM -0700, Jason Short wrote:
> > >
> > > [jdorje - Tue Sep  9 15:39:33 2003]:
> > >
> > > > Sorting is done numerically for numeric fields, and alphabetically for
> > > > text fields.  The problem is some fields are combination fields
> > > > (generally containing multiple numbers) that are sorted alphabetically.
> > >
> > > OK, I take it back.
> > >
> > > The combination field is the fundamental problem, but there's also a
> > > problem in that only gui-gtk implements numerical comparisons.  Also, I
> > > believe combination fields are sorted as numbers rather than text -
> > > which is better but still not a real solution.
> >
> > Long time ago I have made a little patch which did combined alpha/numerical
> > sorting; it splitted the string into pieces at the slashes.
> >
> > I still think this was an improvement of the current situation, which is
> > annoying IMHO.
> >
> > If you think that to I might be able to do an update of that patch.
>
> I don't want a patch that's a hack and doesn't solve everything.  But I
> can imagine that something like this could give good behavior.  We need to
> be able to sort by any field in the combination, in either direction.
>
> I imagine this would mean sorting would have to be done entirely by
> freeciv, so that client/cityrepdata.c tracks both the field being sorted
> by and the direction of sort.  The typical GUI interface of clicking on
> the header to toggle the direction of sort would instead toggle between
> all of the possible sorting methods.

Don't you just need a comparison function with the appropriate arguments?
I fail to see why the data must be stored in client common. Even it at
least the GTK+ 2.0 would have absolutely no problem with you keeping the data
there.

IIRC the only data currently stored in the GtkTreeModel in the GTK+ 2.0
client for the city report is the city pointer and id. A display function
callback (cityrep_cell_data_func) takes care of getting the useful data
from those into the cells. Interesting no?

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa




[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] Re: (PR#2607) city report fields still don't sort perfectly, Vasco Alexandre da Silva Costa <=