GNOME Bugzilla – Bug 765471
CellRendererText shows edit entry in a wrong position for small cells
Last modified: 2016-04-28 01:37:48 UTC
Created attachment 326599 [details] Testcase that reproduces the problem When a small text cell is edited, the edit entry is shown at a wrong position. How to reproduce: * Compile and run the testcase. * Ensure that the window is as small as possible horizontally, so that the left column is large and that the right column is small. * Double-click on the right column Expected result: * The entry for editing the cell contents appears on top of the right column Actual result: * The entry for editing the cell contents appears somewhere to the left of the right column
Created attachment 326808 [details] [review] GtkTreeView: change child repositioning to preserve locality As Company suggested, i've tried to fix this in gtk_tree_view_size_allocate(). This patch is based on my rather limited understanding of what's happening in that function. This patch should work (one caveat is highlighted in commit message; whether it should be fixed, and how, is a separate matter). However, while testing this for RTL, i've discovered that changing text direction to RTL in Inspector affects everything - except for the edit entry, which always displays its contents in LTR direction. If that is not a bug in Inspector direction switching, then it's a bug in treeview/cellrenderer (file it separately?), and this patch would be broken for people actually using RTL. There's also the fact that recent gtk master (i'm using aa99c64) has broken theme, which causes edit entry to have transparent background, which somewhat hampers the testing process. I've been meaning to talk to lapo about it, but he hasn't been on the IRC for some time now.
Created attachment 326809 [details] Testcase that reproduces the problem (works better for RTL)
mclasen explained to me how to actually get stuff to *be* RTL and i was able to test this patch with real RTL. And lapo fixed transparent cell-editing entry background. Anyway, works as intended, for both LTR and RTL. Please review.
Comment on attachment 326808 [details] [review] GtkTreeView: change child repositioning to preserve locality Looks good.
Created attachment 326895 [details] [review] GtkTreeView: reduce child size to fit it into treeview allocation This last fix is applied to cases when child widget (specifically - edit entry for GtkCellRendererText) extends past the edge of the treeview, partially disappearing. This happens: When LTR entry is shown for a small cell that is located at the right edge of a treeview, where its right edge extends past the treeview area (its left edge is already guaranteed to be inside the treeview, see previous commit). Or: When RTL entry is shown for a small cell that is located at the left edge of a treeview, where its left edge extends past the treeview area (its right edge is already guaranteed to be inside the treeview, see previous commit). In either case the child width is reduced (also shifting it right for the RTL case) so that it fits into the treeview.
Created attachment 326896 [details] Testcase that reproduces the problem (works even more better for RTL) This version comes with some Arabic text so that RTL is in full effect (you still need to enable RTL in Inspector, if it's not enabled by default). Set GTK_FIT_SMALL_CELL envvar to something and edit one of the small cells in the middle to see how the child can be fit into the cell regardless of its position.
Created attachment 326899 [details] [review] GtkTreeView: shift the child to fit it into treeview allocation After discussing this with Company on IRC, here's an alternative version that does not reduce child size. v2: In either case the child is shifted (breaking its alignment to the cell that previous commit tried to preserve) left or right depending on text direction, so that it does not stick outside of the treeview. If shifting made it stick from the *other* side of the treeview (treeview is really small), shift it in opposite direction to ensure that starting end (direction-dependent) is visible and leave it at that (it will stick out, but that can't be helped - we can't reduce child width).
Created attachment 326903 [details] [review] GtkTreeView: change child repositioning to preserve locality This is a merge of this patch and the following shift patch v2: * Folded both patches into a combination of MIN() and MAX(). First the child is made to overlay the cell perfectly (border is added, but it's usually 0; not sure what happens if it isn't 0, but that doesn't concern me). Then preferred width is queried. If child is smaller than that, it's enlarged. Where the extra size goes, depends on text direction. Then prefereed height is queried. If child is smaller than that, it's enlarged. Extra size is appended to both upper and lower edges equally. Then, if the child sticks outside of the allocation, it is shifted to be inside. Which edge is shifted last (thus guaranteeing that *this* edge will be visible, in case child width exceeds treeview allocation) depends on text direction.
Comment on attachment 326903 [details] [review] GtkTreeView: change child repositioning to preserve locality Nice. Thanks for the thorough checking of all possibilities.
Attachment 326903 [details] pushed as 96c18db - GtkTreeView: change child repositioning to preserve locality