After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704698 - Visible UI bugs when calling gtk_tree_view_set_cursor in one special case
Visible UI bugs when calling gtk_tree_view_set_cursor in one special case
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2013-07-22 17:57 UTC by Jonas Platte
Modified: 2018-04-15 00:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case (4.99 KB, text/plain)
2013-08-03 08:05 UTC, Kjell Ahlstedt
Details
Test case for gtk+4 (5.02 KB, text/plain)
2018-02-15 16:21 UTC, Kjell Ahlstedt
Details

Description Jonas Platte 2013-07-22 17:57:32 UTC
This bug effects gtk+ 3.x – I only use 3.4 and 3.6 (indirectly through gtkmm) – but I am sure it belongs here as I discussed it on the gtkmm mailing list (https://mail.gnome.org/archives/gtkmm-list/2013-July/msg00036.html)
To reproduce the bugs, do the following:

Write a signal handler for the signal "edited" of GtkCellRendererText used to create a editable cell in a GtkTreeView that starts editing the same cell again using gtk_tree_view_set_cursor with start_editing set to true.

Then run the program, start editing the cell and confirm (or should it be cancelling?) the editing by clicking somewhere else. You'll notice that the editing will start again somehow, but you will no longer be able to confirm your input and the new entry will not disappear when you select another row.
Comment 1 Murray Cumming 2013-08-02 08:19:44 UTC
I've seen similar weirdness myself sometimes. I generally work around this by doing the call outside of the signal handler, by doing it in an idle handler. For glibmm/gtkmm, see Glib::signal_idle():
https://developer.gnome.org/glibmm/2.34/classGlib_1_1SignalIdle.html

However, it would still be nice to have a simple C example that showed this problem.
Comment 2 Kjell Ahlstedt 2013-08-03 08:05:08 UTC
Created attachment 250750 [details]
Test case
Comment 3 Matthias Clasen 2018-02-10 05:26:45 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 4 Kjell Ahlstedt 2018-02-15 16:21:29 UTC
Created attachment 368376 [details]
Test case for gtk+4

I think the behavior has changed a bit since the bug was filed, but the issue
has not been fully fixed. I leave it to the reporter to decide if it's worth
migrating the bug to gitlab.

The test programs print critical messages.

In gtk+ 3.22:
(example:30999): GLib-GObject-CRITICAL **: 17:12:38.050: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

In gtk+ 4:
(example:30850): Gtk-CRITICAL **: 17:02:11.151: gtk_css_node_insert_after: assertion 'previous_sibling == NULL || previous_sibling->parent == parent' failed
Comment 5 Matthias Clasen 2018-04-15 00:37:58 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new