GNOME Bugzilla – Bug 754620
positioning and size issues with new rename popover
Last modified: 2015-11-03 10:46:07 UTC
Here's a bunch of remaining issues with the popover now used for renaming: 1. The popover length doesn't scale with the filename (both initial one and if a longer one is typed) and thus is/becomes easily too small. 2. If the file is at the window's bottom, the popover is visible either only partially or not at all. Even when there's still enough screen space below, it's confined to the window (I use xmonad, dunno if that's the cause). 3. In list view the popover most often appears too far to the right as it's currently placed in the middle of the entire list's width, rather than eg. the name section's middle. But even the latter is too far on wide windows, so maybe position it ⅓ of name section's width from the left? 4. In grid view, the positioning is entirely wrong, both horizontally and vertically. The most natural position IMHO would a position vertically aligned with the icon center and horizontally below (resp. in 2. maybe above) the filename. (I still don't grok why the inplace renaming was yanked at all, but at least a popover isn't as fugly and distracting as a dialog.)
I confirm the second issue on GNOME (Wayland), the popover always pops at the bottom even if it is not visible there. I also confirm the first, even if it’s not a big issue in my mind. By the way, is the filename limited to a number of chars? I don’t understand the fourth issue, as it’s what I’m seeing I think.
Created attachment 310748 [details] list view at 1080px width: popover too far to the right Here's three screenshots to demonstrate 3. and 4.
Created attachment 310750 [details] grid view: misplaced popover (1) gtk3 at 9cd7f97 nautilus at 19d891e
Created attachment 310751 [details] grid view: misplaced popover (2) The further to the right the selected file is, the more misplaced (to the right) the popover becomes.
Ok, so the point 4 is a real separated bug, and I don’t see it here (on 3.17.90, GNOME/Wayland). The point 3 is a design problem of popovers-on-listboxrows.
(In reply to Arnaud Bonatti from comment #5) > Ok, so the point 4 is a real separated bug, and I don’t see it here (on > 3.17.90, GNOME/Wayland). > > The point 3 is a design problem of popovers-on-listboxrows. Not really. It is just a quality-of-implementation issue to show the pop over close to the click when using a mouse, and at a good location when not. Compare what the file chooser does.
Created attachment 310878 [details] [review] canvas-container: fix bounding box on different pixels per unit We were returning the bounding box without taking care of the pixels per unit, so the clients of it were using the wrong bounding box calculation. For instance the rename popover was wrong calculated for the canvas view if the pixel per unit was different than 1. The bounding boxes are usually not calculated with pixels per unit adjustment, but is very convenient to have it here, so add a comment explaining it.
Created attachment 310879 [details] [review] list-view: use button position for rename popover We were always pointing to the middle of the row, which is not very nice if the user is has his point of vision to another place. So use the last mouse event if available for positioning the rename popover in the x direction.
This fixes points 3 and 4. Number 1 needs discussion. But I guess multiline looks as fine solution. Number 2 is not reproducible, and the popover should go above the window out of the box, so makes me think it's a problem with something else. Can you reproduce with not xmonad? Attachment 310878 [details] pushed as 7d96b11 - canvas-container: fix bounding box on different pixels per unit Attachment 310879 [details] pushed as 7bc43d8 - list-view: use button position for rename popover
Thanks for the fixes. #1 IMHO the popover would look best if it grows in width first (eg. by half max) before switching to multiline. Otherwise with its current width, the textfield might become overly narrow in appearance for the relevant longish filenames. #2 seems to have been fixed along the way, I can't reproduce it either anymore. #3 is perfect now for mouse – yet keyboard users (or just if one already renamed via mouse and presses a single up/down + F2) are still left in the middle, so maybe prioritize by availability: 1) Current button position 2) Previous button position 3) Middle of filename (ie. new default for keyboard, and consistent with grid behavior)
Created attachment 311211 [details] [review] list-view: use filename column width for rename popover position Instead of total column width, use only that of the filename one for the rename popover position (if no button position present).
This is still too far to the right for windows wider than ~960px, though. I tried to figure out how nautilus/gtk/pango handles the filename rendering to see if there's a way to get the rendered one's middle position in pixels, but I still haven't gotten past the nautilus code yet. To be honest, so far it's just too convoluted for me.
(In reply to ar from comment #12) > This is still too far to the right for windows wider than ~960px, though. > > I tried to figure out how nautilus/gtk/pango handles the filename rendering > to see if there's a way to get the rendered one's middle position in pixels, > but I still haven't gotten past the nautilus code yet. To be honest, so far > it's just too convoluted for me. Sorry for answering late, got sidetracked. I think is better than what we have, let's go with it. I will push to master now before releasing, thanks for the patch!
Attachment 311211 [details] pushed as f03ab5c - list-view: use filename column width for rename popover position
The tiny size is a real nuisance. Apparently the fix did not make it to 3.18. I don't see a target milestone set. Can it please be targetted for the next (minor) release? Thank you!