GNOME Bugzilla – Bug 773119
Floating bar not hiding on hover with two or more tabs
Last modified: 2017-02-01 06:44:34 UTC
Reproducible steps: 1. Press Ctrl+N 2. Select any item in Icon or List View 3. Move mouse cursor over a floating bar.
Sorry. Step 1 is Ctrl+T (new tab), of course.
Thanks for reporting this. I will take a look when I find a freer moment tomorrow.
Created attachment 337950 [details] [review] floating-bar: fix hide on hover with notebook visible When the notebook is visible, the pointer intersection with the floating bar check fails. That is due to how the floating bar bounds are calculated - the upper y bound becomes smaller than the lower y bound. That can be fixed by calculating the upper bound relative to the lower one.
If I am being honest, I have no idea why my fix works. It appears that GTK+ and GDK have conflicting ideas about positioning.
(In reply to Ernestas Kulik from comment #4) > If I am being honest, I have no idea why my fix works. It appears that GTK+ > and GDK have conflicting ideas about positioning. Works like a charm. Thanks!
Review of attachment 337950 [details] [review]: Would be good to explain the reason in the commit message. The widget windor of the GtkOverlay has y = 0 when there are no tabs, and y = 37 (depending on theme and font size) when there are tabs. However we are not taking that into account and instead just setting the parents allocation as a upper limit. Rule of thumb is when using positions always take into account the relative position of the parent. But I think part of this code is mine so I will not be grumpy about it :D Once you explain that in the commit message, just commit it.
I forgot to mention, the code of the patch looks perfectly good, thanks! :)
(In reply to Carlos Soriano from comment #6) > Review of attachment 337950 [details] [review] [review]: > > Would be good to explain the reason in the commit message. > > The widget windor of the GtkOverlay has y = 0 when there are no tabs, and y > = 37 (depending on theme and font size) when there are tabs. > However we are not taking that into account and instead just setting the > parents allocation as a upper limit. > Rule of thumb is when using positions always take into account the relative > position of the parent. But I think part of this code is mine so I will not > be grumpy about it :D > > Once you explain that in the commit message, just commit it. The code actually made sense to me. The lower limt is set as the y coordinate of the floating bar /within/ the parent overlay and the upper limit is set as the height /of/ the parent overlay, no?
(In reply to Carlos Soriano from comment #7) > I forgot to mention, the code of the patch looks perfectly good, thanks! :) Oh that's not explicity, but rather duplication, which is wrong. This is something documented in the API of glib/gtk+, there is not need to document it, in the same way you don't document g_file_rename or so saying "rename the file". Comments should always be the last resort (as opposed of what some universities teach). What it's not clear here is that you are unescheduling something that is already unescheduled because you return g_source_remove. So you clarify "it's just for setting the id to 0 in the priv data...".
(In reply to Carlos Soriano from comment #9) > (In reply to Carlos Soriano from comment #7) > > I forgot to mention, the code of the patch looks perfectly good, thanks! :) > > Oh that's not explicity, but rather duplication, which is wrong. This is > something documented in the API of glib/gtk+, there is not need to document > it, in the same way you don't document g_file_rename or so saying "rename > the file". > > Comments should always be the last resort (as opposed of what some > universities teach). > > What it's not clear here is that you are unescheduling something that is > already unescheduled because you return g_source_remove. So you clarify > "it's just for setting the id to 0 in the priv data...". Wait… This is the wrong bug. :D
wtf how this happened?
Created attachment 338726 [details] [review] floating-bar: fix hide on hover with notebook visible When the notebook is visible, the pointer intersection with the floating bar check fails. That is due to how the floating bar bounds are calculated - the offset of the overlay when tabs are visible is not taken into account, allowing the upper y bound to become smaller than the lower bound. That can be fixed by calculating the upper y bound relative to the lower one.
Review of attachment 338726 [details] [review]: YEP
Attachment 338726 [details] pushed as 0880338 - floating-bar: fix hide on hover with notebook visible
*** Bug 778007 has been marked as a duplicate of this bug. ***