GNOME Bugzilla – Bug 651293
Tooltip display for last item makes item uneditable (when not using status bar)
Last modified: 2017-02-01 02:22:30 UTC
Created attachment 188784 [details] Picture of bug If using nautilus without a status bar the selected item title 'floats' at the bottom of the nautilus application. If you choose the last file item in a list this 'floating' title prevents you seeing the actual title making editing difficult/impossible. The fix would be to have the 'floating' title disappear when the user goes into editing mode and return when the user exits editing mode.
I have this issue as well. Here is my description as well as my suggested solutions. In Nautilus when you have an even number of files on the bottom row it becomes difficult to rename the last file as the status bar covers the text area. I realize this is likely a rare occurrence, and can be gotten around by adjusting the width of the window, but it is a minor bug. Possible solutions: Move status bar to the left side when working with files in that corner. Do not show status bar while renaming. Best IMHO: Give the file area a bottom margin of the height of the status bar. Ubuntu 11.04, Gnome-Shell nautilus: 1:3.0.2-0ubuntu2~natty1
*** Bug 658511 has been marked as a duplicate of this bug. ***
*** Bug 661990 has been marked as a duplicate of this bug. ***
*** Bug 668904 has been marked as a duplicate of this bug. ***
*** Bug 671933 has been marked as a duplicate of this bug. ***
why status of bug still UNCONFIRMED?
(In reply to comment #5) > *** Bug 671933 has been marked as a duplicate of this bug. *** Why status of this bug still UNCONFIRMED?
*** Bug 676875 has been marked as a duplicate of this bug. ***
We should behave like Epiphany and gradually move the floating bars out of the way when they would hover part of the selection.
*** Bug 688090 has been marked as a duplicate of this bug. ***
*** Bug 688063 has been marked as a duplicate of this bug. ***
*** Bug 688584 has been marked as a duplicate of this bug. ***
As mentioned in [0], I have an idea for a workaround to this bug: adding an empty row to the end of the list, such that, if I scroll to the bottom, the floating status bar would hover this 'dummy row' instead of the last item. Such empty row would look and behave as background. As a side effect, this dummy row would provide a fix for bug 689768 and bug 306413. [0] https://bugzilla.gnome.org/show_bug.cgi?id=689768#c7
Other operational systems just show the tooltip for last lines at top when selecting this items. It's another simple solution.
I suggest update the bug to Gnome version 3.x, instead of 3.0, since this bug remains in the current version.
*** Bug 691795 has been marked as a duplicate of this bug. ***
Created attachment 233866 [details] Someone tell me the name of the selected folders please (In reply to comment #15) > I suggest update the bug to Gnome version 3.x, instead of 3.0, since this bug > remains in the current version. Yes, please. Even more when the fixed statusbar option has been removed in nautilus 3.6... By the way, this also happens in icon view. See screenshot.
*** Bug 698281 has been marked as a duplicate of this bug. ***
This bug has been active since at least GNOME 3.4, does this mean a "won't fix"?
This status bar is completely covering the last file's name in list view! It's really annoying that you can't toggle it off, and it makes it nearly impossible to rename the last file in the list.
*** Bug 701137 has been marked as a duplicate of this bug. ***
Kees de Jong, while the developers doesn't have any indicator which bugs or features are more relevant for the users (as discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=684943#c15) we really have to wait until someone stubles on this one.
It baffles me how this has not been fixed yet. It's an extremely annoying behavior. I guess all the devs use fullscreen nautilus windows? I typically use nautilus in a smallish (800x600px or so) window with listview - and this 'tooltip dancing back and forth and yet always being in they way' is driving me nuts. Sorry for the noise. I just had to get it off my chest.
This annoying problem also persists in Gnome 3.8.2 (Ubuntu PPA) and drives me nuts. Best solution (for me) would be the re-appearance of the much more useable statusbar? I am missing the information regarding the free space of the drive I am actually on.
I can confirm on GNOME 3.10.0.
*** Bug 711113 has been marked as a duplicate of this bug. ***
I have been trying to find a solution for this problem every couple of months for a long time. I always use list view, and the bottom file is covered up. It is so annoying that I have spent hours searching for solutions, and most of the posts are old (like making the yellow tooltip transparent). It is a TERRIBLE problem and I agree with the many other users from launchpad. Moving the yellow bar across does not solve the problem, since I use small windows. I hope someone will fix it soon!
*** Bug 733114 has been marked as a duplicate of this bug. ***
I hope someone will fix it soon too!
*** Bug 734011 has been marked as a duplicate of this bug. ***
*** Bug 735031 has been marked as a duplicate of this bug. ***
*** Bug 735987 has been marked as a duplicate of this bug. ***
I am one more user daily annoyed by this bug. As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=651293#c13 an easy (and very consistent) fix is to just add one (or more) empty row(s) at the bottom of the list. I can not think of any argument against this solution. If any of the developers responds positively to this, I am willing to create a patch implementing the change.
If you do, please remember that it also happens in icon view.
A patch would be very much welcomed, as this is still relevant in 3.14
*** Bug 737893 has been marked as a duplicate of this bug. ***
*** Bug 739533 has been marked as a duplicate of this bug. ***
*** Bug 741084 has been marked as a duplicate of this bug. ***
Proposal in comment #17 doesn't solve cases where selected file is at bottom in view, but not bottom of the whole list (i.e. when list can be scrolled, and scroll position is not at bottom, and bottom file of current view is selected). Comment #9 seems to be a better solution, but might be problematic too in case of workflow where user starts selecting files one by one from the bottom. In that situation, user cannot select other file(s) if the floating status bar hovers over them, unless the bar smartly hovers away too for that.
Created attachment 294086 [details] [review] floating-bar: hide on mouseover If the floating bar is very large, changing its alignment may not be sufficient to move it out of the way. Instead, hide it completely on mouseover and bring it back when the mouse is moved away.
Nice! That would simultaneously make bug #742594 redundant!
(In reply to comment #40) > Created an attachment (id=294086) [details] [review] > floating-bar: hide on mouseover > > If the floating bar is very large, changing its alignment may not be > sufficient to move it out of the way. Instead, hide it completely on > mouseover and bring it back when the mouse is moved away. I tried the patch, it's nice solution I like it, but I found a nitpick didn't know if you're aware of it, when you hover the bar and is hidden then try to click on the revealed item but the clicks are ignored.
Comment on attachment 294086 [details] [review] floating-bar: hide on mouseover Drat, I hadn't noticed. I think that's a fairly serious problem.
Created attachment 294806 [details] [review] Create and use new hover-hide property. Create new property for hide-on-hover behaviour, so old behaviour is still there for people who want to use it. Hide-on-hover is implemented by using a timeout for checking the pointer position until it goes outside the bar up/down 'y coord' limits. I've been testing the patch and think it's performing well but of course I appreciate new test and feedback.
Hey Carlos, what do you think about this patch?
Review of attachment 294806 [details] [review]: ::: src/nautilus-floating-bar.c @@ +225,3 @@ + //hide floating bar at top position of widget + gtk_widget_set_valign (data->floating_bar, GTK_ALIGN_START); + nautilus_floating_bar_hide (data->floating_bar); nautilus_floating_bar_hide should be called before gtk_widget_set_valign so that the widget doesn't briefly flash into the location it's not supposed to be shown in. ::: src/nautilus-floating-bar.h @@ +79,3 @@ +void nautilus_floating_bar_remove_hover_timeout (NautilusFloatingBar *self); + +gboolean nautilus_floating_bar_is_hover_hide (NautilusFloatingBar *self); Personally, I don't see why the API for nautilus_floating_bar needs to change at all. Why would anyone NOT want the bar to be hidden on hover?
(In reply to Michael Catanzaro from comment #45) > Hey Carlos, what do you think about this patch? Sorry for the delay, I didn't get an email for this bug report for some reason. We will remove the floating bar after releasing 3.16, so probably this won't be need at all. Thanks for the good work anyway =)
(In reply to Carlos Soriano from comment #47) > (In reply to Michael Catanzaro from comment #45) > > Hey Carlos, what do you think about this patch? > > We will remove the floating bar after releasing 3.16, so probably this won't > be need at all. Thanks for the information, you just saved me keep working on this and also in bug 96239 which I've already spent some time working towards a fix. The removing of floating bar is being replaced by something? Now that I think of it, the information provided ("filename" and file size) can be easily obtained from the view or one-click away..
(In reply to Nelson Benitez from comment #48) > (In reply to Carlos Soriano from comment #47) > > (In reply to Michael Catanzaro from comment #45) > > > Hey Carlos, what do you think about this patch? > > > > We will remove the floating bar after releasing 3.16, so probably this won't > > be need at all. > > Thanks for the information, you just saved me keep working on this and also > in bug 96239 which I've already spent some time working towards a fix. Sorry I meant bug 651293 instead of 96239
Bug 703030 can also be closed if floating bar is finally removed.
According to comment 47, this will not be fixed for 3.16.0. Removing target
(In reply to Carlos Soriano from comment #47) > We will remove the floating bar after releasing 3.16, so probably this won't > be need at all. > > Thanks for the good work anyway =) Has there been any progress on this issue? This problem still exists in GNOME 3.18 (on Fedora 23).
Review of attachment 294806 [details] [review]: Thanks Nelson for the patch. We didn't remove the floating bar yet, even if we want. This patch would need update to master and make sure it works with the latest work on the window-slot and view we did. Probably won't worth the effort because as said we want to remove the floating bar, but in the meantime we could merge this... Marking as needs-work
Bump. The floating info bar is still present in Nautilus 3.20.
Come on gnome.. we love you
Created attachment 331388 [details] [review] nautilus-floating-bar: hide on hover Due to the floating bar being in an overlay, it can obscure the content under it. We were planning to remove it and use an action bar. But it's taking long, so in the meantime we can improve this situations hiding the floating bar when hovered. On the way I improved the handling of the spinner, which was failing to be shown on certain situations. Patch based on Nelson Benitez, thanks!
Attachment 331388 [details] pushed as e66d3ca - nautilus-floating-bar: hide on hover
Thank you so much, Carlos!