Re: TreeView

[Ed Leaver <eleaver sterlingseismic com>]

On Thu, 2006-01-26 at 09:29, Bob Caryl wrote:
> Leandro Fanzone wrote:
>
> > Along with Caryl, I will give my opinion about it, having used both 
> > CList and TreeView over a number of years. Probably both are the two 
> > possible extremes of what one really needs. CList was far too 
> > simplistic, but quick enough to throw a list of something "right now" 
> > in a dialog. TreeView, on the other hand, is far too complex, baroque 
> > as nothing is in gtk(mm), though excellently wrapped in C++, it is 
> > still very dificult to understand (especially if you have to customize 
> > it a liitle), and I found myself ending up copying/pasting code from 
> > past projects to make it work, and writing more generic code to 
> > achieve the usual things: numeric/string columns with validations, 
> > with all the usual stuff to add them.
> > I think, for the first comer, it's appallingly overwhelming to learn 
> > enough to be a scholar especialized in TreeView just to show a small 
> > list of data, which is something quite usual for any application out 
> > there. If we add to that the serious performance problems TreeView has 
> > with large amounts of rows, well, it seems to be reasonable to have 
> > CList back, if only to have an option, both for the newbie, for the 
> > quick-and-dirty stuff, and for the "I need the simplest and faster one 
> > to show a zillion of rows". My two (argentinean peso) cents here.
> >
> > Leandro.
> >
> It has been about 12 months since I first got involved with gtkmm (after 
> trying gtk first), and I must say I found the Gtk::TreeView 
> implementation confusing having come from windows and the CList.   I 
> have to agree that it was daunting.  However, once I got a handle on it, 
> I find it to be a very useful tool.  I love the ability to switch 
> Gtk::TreeModel's in and out of the same Gtk::TreeView.  Because I have 
> not had a situation that required displaying "zillions of rows", I 
> cannot comment on that except to say that I don't think the display of 
> that much data in a GUI makes a lot of sense in the real world.  <Bob 
> dons his asbestos suit>.
>
> Bob
Well Bob, displaying that much data in the "real world" (where ever that is) does make sense, at least if you implement the display as a hierarchical TreeView. Think about displaying the file system on the largest gawdawful multi-node data processing lashup one can imagine. I know, that example really is for use of a TreeView, not a ListView.  Point is, you can end up displaying (or have the potential to display) literally tens of thousands of rows of information, each row being easy for the user to access (log-arithms are cut from trees, you know:) and interpret.

And yes, when the tree grows that big, Gtk::TreeView can become downright sluggish. But as a rejoinder and agreement with some of your previous comments, I have found, over the two and a half years I've used them, the Gtk::TreeModel/Gtk::TreeView pair to be one incredibly flexible and powerful  combination. I use them everywhere, even where a ListModel/ListView would do, simply to keep things consistent. And their Column Record (Gtk::TreeModelColumn<T>) templates can hold anything. Sure, when I first started out I restricted myself just to ustring's and ints, like in the examples, and used int fields as an offset into various row and file information vectors. Which is still an OK way for my app to handle them, as that row information can be expensive to compute and placing it in a separate STL container makes it independent of a particular TreeModel. But later on I became more adventurous (read desperate) and added things like Gtk::TreeModelColumn<std::map<whatever> >  m_data_map; or Gtk::TreeModelColumn<C_ArchiveDiskDatabase::C_HeaderInfo> m_hdrinfo;
where C_HeaderInfo is a pretty arbitrary C++ class. Yes, I still copy some C_HeaderInfo identifier string to an ordinary Gtk::TreeModelColumn<ustring> m_id_string member in order to display it, although if I were to learn enough about CellRenderer I could probably figure out how to display such stuff directly. 

So I've still got lots more to learn. And I fersure can't say that Gtk::TreeView performance is sufficient for every application, or that some apps might benefit from something simpler, or simpler wrappers. I do know that for my own needs I've been extremely happy to have a universal do-anything TreeModel/TreeView combo that works well and with the same syntax everyplace I need to use it.  

Yes, I know you all have different applications with different needs, and your mileage does indeed vary. So I can't say your suggestions and criticisms are not justified. I do want Murry and the Gtk+ folks to know that someplace Out Here Gtk::TreeModel/TreeView are being put to good effect, by people who are very glad to have them. So Thanks! 

P.S> Obligatory Dirty Wish List Dept:
I frequently want to iterate over every item in a TreeModel in a single loop, and the (seemingly) reasonable way to do this would be e.g.
Gtk::TreeModel MyModel;
for(TreeIter iter = MyModel.begin(); iter!=MyModel.end(); iter++){
   (do something constructive with iter)
} 

But I haven't been able to figure out how to do this directly: one can iterate over e.g. for(TreeIter iter=MyModel.children().begin(); iter!=MyModel.children().end(); iter++){
  (do something constructive with iter)
}

but that only gets the top level of the hierarchy. One can of course recurse on the children's children. One can also do f'rinstance something like

//***********************************************************************************
class MyClass{
public:
   vector<TreeIter> m_iter_vec;

   bool store_iter(const TreeIter & iter){
       m_iter_vec.push_back(iter);
       return false;
   };
  Gtk::TreeModel MyModel;
};

MyModel.foreach_iter(sigc::mem_fun(*this,&MyClass::store_iter));

for(vector<TreeIter>const_iterator iter=m_iter_vec.begin(); iter!=m_iter_vec.end(); iter++){
    (do something constructive with *iter)
}
//*************************************************************************

I do the above sort of thing often enough that I'd think such an iterator over an entire TreeModel would (or "should" :) be part of the Gtk::TreeModel class itself, but if it is, I can't find the documentation. I'll also admit to not knowing how to implement such a direct whole-tree iterator myself. Any suggestions? Thanks!

Ed Leaver

---

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list