Created attachment 9140 excess-clickable-area.png 1) Have two files named "loremipsum" and "loremipsum loremipsum" in icon view. First one is displayed as a one-line, second one is divided to two lines. 2) the clickable area of the two line filename is wider than the blue area drawn when it is selected - see the attached picture (excess area in red). So sometimes "clicking empty space" selects a file. This also affects rubberband selection - the file becomes selected even if it is not yet inside the rubberband. As soon as the filename is more than one line, the width of the "active" (clickable, selectable) area of the filename is always some predefined maximal width.
Created attachment 9141 wrong-xfce-4.14 Video demonstrating the bug. The rubberband selects "loremipsum loremipsum" even if it is not yet inside it. Then shown: clicking outside "loremipsum loremipsum" selects the file.
Created attachment 9142 correct-xfce-4.12 Correct behaviour in XFCE 4.12.
Created attachment 9165 gap-two-line-text-beside-icon.png I think a related bug occurs when using Edit/Preferences/Display/Text beside icons - multiline filenames are not displayed right next to the icon, there can be a visual (yet clickable) gap between the icon and the multi-line filename (see the above screenshot).
Delving into the code, there is exo_icon_view_calculate_item_size(..) function, which contains a call to gtk_cell_renderer_get_preferred_size (..) (introduced with GTK 3). This call will, for the text cell, return the width as wrap-width (132 pixels=128+4 padding (in default zoom)) whenever the text is long enough to be multi-line. It will not return the real width of the wrapped multiline text. This is the origin of the excess clickable area. I do not know how to fix this at the moment. exo_icon_view_paint_item (..) contains a call to gtk_cell_renderer_get_aligned_area (..), which will return the aligned_area as a area just around the rendered text, centered in cell_area (that is the reason why the highlight is painted correctly around the text, yet misplaced).
Created attachment 9177 0001-Fix-for-the-bugs-16075-and-16107.patch Fix for this bug. It also fixes bug 16107. Please test.
Adam Purkrt referenced this bugreport in commit 6fcefce9f1e7bb34cb65290c37f889481a677130 Fix for the bugs 16075 and 16107 https://git.xfce.org/xfce/exo/commit?id=6fcefce9f1e7bb34cb65290c37f889481a677130
Confirmed your fix and applied it above. Thanks!
Sean, could you please revert the patch? It led to bug 16196. I consider the patch ugly, it is not a good piece of code. I do not have a better fix now, I feel the problem is at least partly in gtk3 (see remarks above) - I may be wrong with that feeling. Anyway, for the moment being, please do revert the change.
The change has been reverted.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org'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: https://gitlab.xfce.org/xfce/exo/-/issues/18. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev