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 710195 - [PATCH] GtkTreeView: Fix issues when removing a column
[PATCH] GtkTreeView: Fix issues when removing a column
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2013-10-15 15:43 UTC by Olivier Brunel (jjacky)
Modified: 2016-06-06 14:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GtkTreeView: Fix issues when removing a column (1.48 KB, patch)
2013-10-15 15:43 UTC, Olivier Brunel (jjacky)
none Details | Review

Description Olivier Brunel (jjacky) 2013-10-15 15:43:55 UTC
Created attachment 257364 [details] [review]
GtkTreeView: Fix issues when removing a column

When removing a column from a treeview, _gtk_tree_view_column_unset_tree_view()
gets called. This would use gtk_container_remove() to remove the button (from
column header) from the treeview.

In addition to a memory leak (the button never being unreferenced), this would
cause quite a few issues in the treeview, where wrong window/button would be
used on remaining columns, going from visual/UI glitches to segfaults.

This is because the button wasn't added to the treeview via GtkContainer, the
treeview was set as parent of the button (via gtk_widget_set_parent() from
gtk_tree_view_column_create_button()). Therefore, the proper way to "undo" this
is call gtk_widget_unparent() on the button.
Comment 1 Matthias Clasen 2016-06-06 02:26:12 UTC
Review of attachment 257364 [details] [review]:

If you look at the remove() implementation in gtktreeview, you'll see that it special-cases column buttons and does the right thing.
Comment 2 Matthias Clasen 2016-06-06 02:27:14 UTC
Unless you show a testcase that demonstrates the problems you claim, I don't think this is needed
Comment 3 Olivier Brunel (jjacky) 2016-06-06 14:03:39 UTC
Right; let me just say, since I found this a bit amusing: When I opened the bug, and provided a patch fixing it, back in 2013, this was most definitely a bug; it just got ignored.

Then, months later in 2014, someone else opened a bug for the same issue[1], but they probably had a gtk dev phone number or worked in an office next by, anyhow it got looked at and fixed.
As I mentioned then in that bug, it was a duplicate of this very one (just fixed a bit differently) and therefore this one could be closed as well; Of course nothing happened.

Years go by, it's now 2016 and, yes, you're right, the problems I "claim" aren't there (anymore), but not quite because I didn't look at the remove() implementation close enough...

Anyhow, sure, "NOTABUG".


[1] https://bugzilla.gnome.org/show_bug.cgi?id=724891
Comment 4 Matthias Clasen 2016-06-06 14:05:50 UTC
There's only so many people doing gtk bug triage (mainly me), and there's 2500 bugs open. Its just the way it is...
Comment 5 Olivier Brunel (jjacky) 2016-06-06 14:15:12 UTC
Right; It's just most bugs I've opened or contributed patches to went ignored, even after asking for reviews on IRC or via mail to the gtk-devel ML... so I don't bother anymore. I'm sure this isn't the case for everyone, just my personal experience.
And as I said, reading your comments this morning, I found it a bit amusing, is all.