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 793791 - last row entry box of editable text renderer in tree view in a vertical box is in wrong position
last row entry box of editable text renderer in tree view in a vertical box i...
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
Other Linux
: Normal minor
: ---
Assigned To: gtktreeview-bugs
Depends on:
Reported: 2018-02-24 09:50 UTC by Henry Wilkes
Modified: 2018-05-02 19:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

renderer text in a vertical box (1.73 KB, text/x-csrc)
2018-02-24 09:50 UTC, Henry Wilkes

Description Henry Wilkes 2018-02-24 09:50:38 UTC
Created attachment 368869 [details]
renderer text in a vertical box

When placing a basic editable text cell renderer column inside a treeview inside a vertical box the entry box (activated by clicking) for the last row *only* is placed vertically above the original value, rather than on top of the original entry. If the treeview is outside a box, or inside a horizontal box the behaviour goes away.

How to reproduce:

Compile the attached code and run. Unlike the editing the second column values of "friend" and "hat", when editing (by double clicking) the last entry "log", the entry box is displayed vertically above the "log" entry, as opposed to on-top of the entry.

This behaviour disappers if the tree view is placed directly in the window, rather than in the vertical box

This behaviour also disappears if box orientation is changed from GTK_ORIENTATION_VERTICAL to GTK_ORIENTATION_HORIZONTAL
Comment 1 GNOME Infrastructure Team 2018-05-02 19:55:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: