Re: Handling multiple selections in a Gtk::TreeView

["Murray Cumming" <murrayc murrayc com>]

> 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?

Yes, you need to call it whenever you want to examine the selection. It is
not a signal. It calls your signal once for each row that is selected, and
then it returns. It does what the documentation says that it does, and it
does not do anything else. Sorry, it is that simple.

> 2) When exactly is the callback

It is called when you call selected_foreach() and it is not called any
more after selected_foreach() returns.

> function called and how I can get the
> selected
> rows in order to work on them?

A selected row is provided as a parameter to your callback.

> For example it doesn't mention Gtk::TreeSelection::get_selected_rows

Yes, it does:
http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreeSelection.html#a16

> and
> ListHandle_Path, and how to use them and when.

>> 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?

Yes, that would make sense.

>> This is documented:
>> http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreeSel
>>ection.html#a16
>
> Along with your further explanation, I think I've now understood it, but
> honestly, from that description alone I didn't understand the concept.

When you think that you have understood, please make a suggestion for
improvement. A patch would be even nicer:
http://www.gtkmm.org/bugs.shtml#CreatingPatches

[snip]
>> "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?

It is used to identify a row position. However, at the time you actually
use it, there might not actually be a row at that position. You usually
need to convert TreeModel::Paths to TreeModel::iterators to do anything
useful with them. I personally wish that the API used paths less than it
does.

I guess that this documentation
http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreePath.html
should hint that you can convert a path to an iter with
Gtk::TreeModel::get_iter().

However, the TreeModel documention already says "One can convert a path to
an iterator by calling Gtk::TreeModel::get_iter().", and you really should
read that.
http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreeModel.html

>> Hopefully it makes sense now.
>
> I'll give it a try. If I still can't get it to work I guess I have to bug
> you
> again.

This is not so difficult and there are many examples. Please try a little
searching and experimentation. This is probably your first gtkmm project,
so you should expect that there are some basic techniques to learn, which
are used quite consistently throughout the API. I have tried to make these
basic techniques obvious for beginners in the book, but I welcome
improvements.

> 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.

I have tried to do this where it makes sense, but I am not perfect. This
sounds like something that you could do very easily:
http://www.gtkmm.org/bugs.shtml#CreatingPatches

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com