maemo.org Bugzilla – Bug 4640
Last modified: 2010-03-15 20:53:27 UTC
You need to
before you can comment on or make changes to this bug.
HildonTouchSelector needs a get_active_iter() function, like GtkComboBox:
At the moment it just has a get_active() that returns an int (which GtkComboBox
has too). But developer really need to deal with the underlying GtkTreeModel
via GtkTreeIter, not an int. That's particularly true for language bindings.
This is also inconsistent because other HildonTouchSelector functions deal with
There is hildon_touch_selector_get_selected () for this:
* @selector: a #HildonTouchSelector
* @column: the column number we want to get the element
* @iter: #GtkTreeIter currently selected
* Sets @iter to the currently selected node on the nth-column, if selection is
* set to %HILDON_TOUCH_SELECTOR_SINGLE or %HILDON_TOUCH_SELECTOR_MULTIPLE with
* a column different that the first one. @iter may be %NULL if you just want
* test if selection has any selected items.
* This function will not work if selection is in
* %HILDON_TOUCH_SELECTOR_MULTIPLE mode and the column is the first one.
* See gtk_tree_selection_get_selected() for more information.
* Returns: %TRUE if @iter was correctly set, %FALSE otherwise
* Since: 2.2
hildon_touch_selector_get_selected (HildonTouchSelector * selector,
gint column, GtkTreeIter * iter)
Is hildon_touch_selector_select_iter() the setter for this? If so, I guess that
should be called hildon_touch_selector_select_iterset_selected_iter() instead.
Otherwise, to make the relationship clearer, the documentation for both
functions should mention the other function.
Created an attachment (id=2095) [details]
Update HildonTouchSelector documentation
(In reply to comment #2)
> Is hildon_touch_selector_select_iter() the setter for this? If so, I
> guess that should be called
> hildon_touch_selector_select_iterset_selected_iter() instead.
> Otherwise, to make the relationship clearer, the documentation for
> both functions should mention the other function.
I don't think it's a good idea to change the API at this point, so
what do you think about this patch?
Well, API additions should be OK in minor versions, as they are in GTK+. So I'd
personally keep this open in case there is ever a new minor (x.something.y)
But, that's certainly a helpful hint. Thanks. I'd even deprecate these methods,
and any other index-based ones.
(In reply to comment #5)
> Well, API additions should be OK in minor versions, as they are in
> GTK+. So I'd personally keep this open in case there is ever a new
> minor (x.something.y) version.
The problem is that if people start using this new function when the
next Maemo update is out, applications would not be compatible with
earlier firmwares and users would be forced to update. This has
already happened in the PR1.1 update and I wouldn't like it to happen
again without a good reason:
I'd wait to change an API like this (which doesn't add new
functionality) until breaking backwards compatibility is unavoidable.
So I'll just update the docs by now.
Thanks for the report.
It will be available in libhildon 2.2.12
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).
Sorry for the bugmail noise (you can filter on this message).