Re: Handling multiple selections in a Gtk::TreeView

Matthias wrote:
On Thursday 25 November 2004 23:13, Murray Cumming wrote:

This is mentioned in the book, by the way:

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


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


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.

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