Re: Handling multiple selections in a Gtk::TreeView

[Matthew Walton <matthew alledora co uk>]

Matthias wrote:
> On Thursday 25 November 2004 23:13, Murray Cumming wrote:
>
>
> > This is mentioned in the book, by the way:
> > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch08s04.html
>
>
> I have read that of course :) It is lacking important information, e.g.:
>
> 1) Is it sufficient to call selected_foreach once to bind the callback or do I 
> have to call it whenever I want to work on the selection?

You use selected_foreach every time you want to iterate over the 
selected rows. It doesn't bind anything for later. It would appear from 
recent questions on this list that this documentation needs some work to 
make this clearer. Something else for the to-do list.

> 2) When exactly is the callback function called and how I can get the selected 
> rows in order to work on them?

The callback which you pass to selected_foreach is called once per 
selected row, with a Gtk::TreeModel::iterator for each row in turn so 
that you can do something with it.

> For example it doesn't mention Gtk::TreeSelection::get_selected_rows and 
> ListHandle_Path, and how to use them and when.

It doesn't, and it should. When working with multiple selections, I find 
myself using get_selected_rows() much more frequently, to get a vector 
or list of selected rows, then iterating over that with a for loop. I 
might use selected_foreach more if C++ had anonymous functions. Really, 
which one to use depends on what you want to do - sometimes 
selected_foreach is more convenient.

> > It's called once for each row that is selected. It is synchronous,
> > meaning that it only returns when it has finished calling your callback.
>
>
> So I have to call selected_foreach in my on_selection_changed handler?

If you want to do the thing that your callback does to each selected 
item every time the selection changes, yes.

By the way, if the code doesn't follow the pattern

object.signal_something().connect(...)

then you're not connecting a signal handler which will be executed 
later, you're calling something which will be executed immediately. 
There are probably exceptions to that rule, but this isn't one of them.

> > "A Gtk::TreeModel::Path is essentially a potential node. It is a
> > location on a model that may or may not actually correspond to a node on
> > a specific model."
>
>
> *confused* And what is it used for?

Mostly paths are used for moving around trees. They refer to things that 
may or may not be in the tree - for a ListStore, obviously the only 
valid paths are to items on the top level, but for a TreeStore they 
specify things like 'item 0 of item 2 of item 4' which can actually be 
represented as a string: "4:2:0", which GTK+ uses a lot.

TreeModel::Path has a constructor which takes a TreeModel::iterator, 
which is useful when you've got an iterator and need to call a method 
that takes a path. To go the other way, you use the TreeModel's 
get_iter(Path&) method, because Path objects have no association with a 
specific TreeModel. Of course, this can return an invalid iterator if 
the path refers to a node that doesn't exist.

As to what they're used for, I find the most singularly useful thing 
about Path is

TreeModel::Path::up()

which modifies the path to point to the parent node of the current node, 
if such a node would be valid. Extremely useful for traversing trees.

> I'll give it a try. If I still can't get it to work I guess I have to bug you 
> again. :D
> Maybe, to give at least -some- constructivce criticism, you should cross-link 
> all those links you just posted in the documentation as well. In general, 
> whenever a concept is introduced which requires knowledge of further details 
> (like using sigc signals), there should be some reference, or else the reader 
> might get confused. At least I was.

The documentation does need work, we know :-)

As for using sigc signals, hopefully that's covered well enough in the 
introductory material in the book. It should not need to be documented 
elsewhere, provided people read the introductory material before 
starting to use the library - which I feel is a reasonable expectation. 
If signals and slots are not documented well enough in that material, 
that is clearly a problem and needs to be rectified, but the rest of the 
documentation should be able to assume some level of familiarity with 
the concepts and the relevant API, as it's so absolutely fundamental to 
using gtkmm in even the most trivial programs.