|
Okay I just wanted to make sure because
my former bug reports got responses very quickly.
And you're absolutely right about how much great work all
contributors do. I hope to some day I'll contribute code too :)
Am 01.08.2013 20:37, schrieb Kjell Ahlstedt:
Yes, it's normal that no one responds
to a bug report within 10 days. The response time varies
enormously. Some bugs get a response within hours and a fix
within a few days, others get no reaction for years. Remember
that most work here is done by volunteers. We pick the piece of
work that we find interesting. Isn't it marvellous that so much
great code is written in this way!
I don't recommend increasing the importance. Normal is
just right for this kind of bug. It might help, if you supply a
test case. I might attach a shrinked version of the test case I
made. I just copied one of gtk+'s tests and made some small
changes. It contains a lot of stuff that's not relevant to the
test of the bug.
What could really speed of response is if you can supply both a
test case and a patch that shows how to fix the bug. But even
then, there is no guarantee for a quick response.
Since this is, corrrectly, a gtk+ bug, you should perhaps ask on
the gtk-devel-list or gtk-app-devel-list, but I think you would
get similar answers there. There are now 275 open GtkTreeView
bugs.
Kjell
2013-08-01 19:51, Jonas Platte skrev:
2013-07-03 07:59, Kjell Ahlstedt
skrev:
2013-06-30 20:40, Jonas Platte
skrev:
Hello,
I'm having a little problem with editable cells: I have a
validity check for data entered into a editable cell, and
if it fails, I want to give the user another try to enter
something into that same cell.
To get the focus to the previously edited cell again after
showing an error message, I use TreeView::set_cursor with
the last parameter start_editing set to true (while in the
signal handler for signal_edited of the cell renderer).
The problem is that, when confirming the input by clicking
somewhere outside the cell, the UI gets messed up: the
entry for the edited cell is there as it should (and its
content is reset as it should), but can't be confirmed or
aborted anymore. I get the following error message on the
command line:
Gtk-CRITICAL **: gtk_container_remove: assertion
'gtk_widget_get_parent (widget) == GTK_WIDGET (container)
|| GTK_IS_ASSISTANT (container)' failed
Is it just not allowed to use set_cursor while handling
the confirmation of editing a cell or is this a bug I
should file?
I can confirm that the same thing happens with one of the
example programs in the gtkmm tutorial,
https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/treeview/editable_cells
If the input in the cell is finish by pressing Enter, no
critical message is printed. If the input in the cell is
finish by moving to another cell, the critical message is
printed.
It looks like a bug, but I don't know if it's a gtkmm bug or
a gtk+ bug.
Kjell
I made some changes to the gtk+ test
gtk+/tests/testtreeedit.c. A pure gtk+ application shows the
same bad behaviour as a gtkmm application.
If you file a bug (or have already done so), make it a gtk+
bug.
It may not be trivial to fix. If it can't be fixed, it should
at least be documented that gtk_tree_view_set_cursor() and
gtk_tree_view_set_cursor_on_cell() (and thus
Gtk::TreeView::set_cursor()) can't be used in a
GtkCellRendererText's edited signal handler.
Kjell
|
