Help with Gtk TreeModel RowReference problem...



Howdy folks...  I'm stuck trying to find a non-horribly-hackish way to do something...  So here goes...

I have a ListStore containing records (rows) of the usual kinda thing, date, description, a few other fields.

Selecting a row in the TreeView, brings up a dialog with that records details, and a couple actions that can 
be performed on that record; delete, postpone, apply changes, etc.  If the record is modified, those changes 
should be reflected in the dialog.  Likewise if the row is deleted totally, actions like deleting the record 
should be disabled (or changed to "add" instead).

What is the least-hackish way of attaching such awareness?

At present, I'm stashing a unique record number (a monotonically incrementing counter) in each row.  When a 
dialog is opened, I file the dialog pointer in a GTree under the unique record number.  TreeModel signal 
handlers then simply have to check the GTree to see if there's anything interested, and the signal is 
propagated to handlers for the dialog.  This does, however, waste one long per record, plus the corresponding 
GTree structures.

I also have a RowReference attached to each dialog to make it easy to apply changes back into the ListStore, 
but there doesn't appear to be any way to leverage that row reference to do what I need.  Which makes this 
feel like I'm busy re-inventing the wheel.  Not only does the TreeModel already sift through row references 
to find the one(s) that need changing, but then , in a manner, I sift through dialog boxes to find the one(s) 
that need changing.  If there were a way to propagate the TreeModel signals through the row reference, I 
could use the existing mechanism to do what I need.

Alternatively, which seems to be the least hackish way at present, I'll probably end up having to take a look 
into how row references work themselves, and re-producing that mechanism on my own.  Unless someone knows of 
a better way?  I'd like to hear how other people do this sort of thing?  Is it worth building a TreeModel 
around some other data structure, for example?  Doing that would allow me to avoid the annoyance of passing 
data in and out through the ListStore interface.


Fredderic



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]