After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654163 - Slides the status bar when mouse pointer approaches
Slides the status bar when mouse pointer approaches
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
unspecified
Other All
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on: 654007
Blocks:
 
 
Reported: 2011-07-07 15:10 UTC by Alexandre Mazari
Modified: 2012-01-16 23:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Slides the status bar when mouse pointer approaches (11.87 KB, patch)
2011-07-07 15:10 UTC, Alexandre Mazari
none Details | Review

Description Alexandre Mazari 2011-07-07 15:10:33 UTC
WIP patch to reintroduce 'mouse escaping' for the status bar after the switch to the new GtkOverlay widget.
The idea is to wrap the actual widget in a larger EventBox used to catch mouse motion in our 'escaping area'.
This basically works, with a large caveat: I couldn't find a way to make the eventbox invisible and click events passthrough.

So it is far from being reviewable, but I need some help here :)
Comment 1 Alexandre Mazari 2011-07-07 15:10:45 UTC
Created attachment 191469 [details] [review]
Slides the status bar when mouse pointer approaches

Introduce a widget wrapper making it 'escape' the mouse pointer.
Make use if it in EphyEmbed for the status bar.
Comment 2 Xan Lopez 2011-07-07 22:27:30 UTC
I thought we had said it was just fine to listen to the events in our parent. Is this not feasible anymore?
Comment 3 Alexandre Mazari 2011-07-08 09:01:08 UTC
(In reply to comment #2)
> I thought we had said it was just fine to listen to the events in our parent.
> Is this not feasible anymore?

That's certainly feasible but the widgets hierarchy of GtkOverlay is hidden to us. I am not sure that trying to find the right parent and depending on GtkOverlay internal implemetation is a great idea.

Also, the escaping behaviour is orthogonal to the overlay one, IMHO. Might be interesting to use it in other context.

Still if it is the path you prefer we follow, I think subclassing GtkOverlay might be a better idea, after all the container should be responsible for its children placement. Looks like Gedit took that path with their GeditAnimatedOverlay.

But well, if you know an easy trick to make the GtkEventBox not draw its background, I'd favor the proposed solution. I hope you share that opinion :)
Comment 4 Xan Lopez 2011-07-13 15:26:37 UTC
Considering you are having problems to implement what you want, and that we have been using the "connect to the parent" thing for a while without issues, I'd prefer to stick to the same plan if it's possible (which seems to be, since Gedit does it as you say).
Comment 5 Xan Lopez 2012-01-16 23:54:25 UTC
We are sharing NautilusFloatingBar with nautilus now, which does its own thing, so this is obsolete. Thanks for the patch though!