GNOME Bugzilla – Bug 331241
Only popup controls when mouse moves
Last modified: 2010-09-02 18:28:35 UTC
I find the behaviour of control elements in fullscreen mode a bit annoying. Just a little vibration at may desk (where the mouse is located) and it shows up whole 5 secounds! :) I would suggest to get this triggered by moving the pointer to the lower half of the screen or by clicking the a mouse button (middle?). By the way, also switching between window and fullscreen mode could be changed. Xine-ui, Videolan and a lot of Windows players do this through double clicking. I think that's simple and fast.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 331349 ***
Sorry, Bug 331349 should be a dupe of this one :)
*** Bug 331349 has been marked as a duplicate of this bug. ***
Iäve added a patch here http://bugzilla.gnome.org/attachment.cgi?id=74782 That does exactly that...
Niklas, please split your patch from the one in bug 162814, and add the patch to bug 331241 (ie. this one), which is still opened. Also, I won't accept a patch to only show the fullscreen controls when the mouse is on the "edges". But I would accept a patch to only show the controls when the mouse has travelled a certain amount of distance, to avoid the interface showing up on jitters.
Created attachment 74807 [details] [review] Don't show fullscreen controls until mouse has moved a distance Shows the fullscreen controls only after the cursor have moved a certain distance. Distance and the timeout (to reset the distance) are controlled by two constants...
(In reply to comment #6) > Created an attachment (id=74807) [edit] > Don't show fullscreen controls until mouse has moved a distance > > Shows the fullscreen controls only after the cursor have moved a certain > distance. Distance and the timeout (to reset the distance) are controlled by > two constants... Actually, the distance would need to be relative to the size of the screen (which you can get from the GdkScreen). The coding style is also either absolutely dreadful, or reminescent of the 1980's. Please try to following the existing coding style.
Created attachment 76033 [details] [review] Don't show fullscreen controls until mouse has moved a distance Well, "dreadful" is ofcourse a matter of opinion. Following existing code style, is a very good point, though (I can only blame force of habit). Assuming you meant the variable naming scheme, is this patch more to your liking? This patch uses the fullscreen_rect in the totem struct to determine current size of fullscreen window, and a percentage of that width to determine required movement distance. But, I was thinking... When you stretch those tired legs and accidentally kick the mouse across the table, chances are that it'll exceed the required distance. Another variant would be to have a minimum required movement time, say 1/4 second, before showing the controls. How about that?
Could you please post the same patch generated with "-up"?
Created attachment 76967 [details] [review] Don't show fullscreen controls until mouse has moved a distance Here we go... Using -up
Please don't use static variables. Also use C-style comments (not C++ ones). Also, I think this is far too high: +#define FULLSCREEN_POPUP_MOVEMENT_REQUIRED 50 // percentage of screen width 50% of the screen in 3 seconds? 10%, or even 5% would be a better number (avoid the popups when it jitters, but doesn't need such a large movement). That's something we can always tweak afterwards.
Created attachment 77581 [details] [review] fullscreen-control-popup.patch Patches totem.c and totem-private.h * No more statics used. Added the FullscreenMovementTracker structure definition to totem-private, and a reference to it in the Totem structure * Uses <sys/time> to time movement with millisec granularity * Now requires a minimum continuous movement time (250 milliseconds) and decreased the requried distance to 15% of screen estate * Only uses C comments Still trying... One of these days, I'll get it right :)
Last patch looks good to me, apart from a few remaining style issues, and a typo in a comment here or there, which could easily be fixed when it's committed.
Will this patch be included in Totem in the upcoming 2.20 release? Also, I think the idea of edge activation is much better than percentage activation. It's more natural to move the mouse to the edge when you want to use the controls and away when you're done with them. It would also make it so that there is no delay before the controls disappear--simply move your mouse away, and the controls vanish.
(In reply to comment #14) > Will this patch be included in Totem in the upcoming 2.20 release? No, it won't, as we didn't get around to it. Assuming the patch is still good, it should get into 2.22.
The patch needs to be updated to use the TotemFullscreen object instead of having the code in totem.c
(In reply to comment #16) > The patch needs to be updated to use the TotemFullscreen object instead of > having the code in totem.c > Ok, I'm on it...
Created attachment 95625 [details] [review] Restrict showing the popups to top and bottom areas
Created attachment 95680 [details] [review] Restrict showing the popups to top and bottom areas The patch restricts showing the fullscreen control popups when mouse cursor is moved over them. EDIT: This patch updates the previous one in that it doesn't hide the mouse cursor if the fullscreen controls are visible
totem-fullscreen.c:90: warning: no previous prototype for 'totem_fullscreen_get_control_placements' totem-fullscreen.c:288: warning: no previous prototype for 'totem_fullscreen_cursor_timeout_remove' totem-fullscreen.c:297: warning: no previous prototype for 'totem_fullscreen_cursor_hide' totem-fullscreen.c:308: warning: no previous prototype for 'totem_fullscreen_cursor_timeout_add' totem-fullscreen.c:318: warning: no previous prototype for 'totem_fullscreen_cursor_show' totem-fullscreen.c: In function 'totem_fullscreen_cursor_show': totem-fullscreen.c:322: warning: control reaches end of non-void function totem-fullscreen.c: In function 'totem_fullscreen_cursor_hide': totem-fullscreen.c:304: warning: control reaches end of non-void function FYI, the old code didn't hide the cursor or the popups if the cursor was on top of one of them. That being said, I'm not sure that showing the popups only when the cursor would be is the best idea. How does one know where the popups are supposed to be in the first place? Bryan, the problem is that a simple jitter of the mouse would show the popups. There's 2 different fixes here for that problem: only show the popups when the mouse has travelled a certain distance (dependant on the screen size), or show the popups only when the mouse is where the popups would be. Any ideas?
(In reply to comment #20) > totem-fullscreen.c:90: warning: no previous prototype for > 'totem_fullscreen_get_control_placements' > totem-fullscreen.c:288: warning: no previous prototype for [SNIP] Whops, my bad.... > FYI, the old code didn't hide the cursor or the popups if the cursor was on top > of one of them. Ok > That being said, I'm not sure that showing the popups only when the cursor > would be is the best idea. How does one know where the popups are supposed to > be in the first place? Right now, parts of the code that moves the popups into place (totem_fullscreen_move_popups) has simply been duplicated in totem_fullscreen_get_popups_placement (which ofcourse isn't a good idea). Why not calculate the popups positions when fullscreen has been initiated (recalulated if the theme or screen res changes) and simply keep that info in the TotemFullscreenPrivate-struct?
(In reply to comment #21) <snip> > > That being said, I'm not sure that showing the popups only when the cursor > > would be is the best idea. How does one know where the popups are supposed to > > be in the first place? > > Right now, parts of the code that moves the popups into place > (totem_fullscreen_move_popups) has simply been duplicated in > totem_fullscreen_get_popups_placement (which ofcourse isn't a good idea). > Why not calculate the popups positions when fullscreen has been initiated > (recalulated if the theme or screen res changes) and simply keep that info in > the TotemFullscreenPrivate-struct? I wasn't commenting on the code, but on the behaviour. I don't really like the behaviour you implemented in that patch, which is why I'm asking Bryan for comments.
I think this bug is related to a issue we have had with cheese-fullscreen! (bug#548546) We definitely need some good guidelines how to trigger these fullscreen-popup-controls (gnome wide?!). The cheese bug was solved by showing the controls when the fullscreen mode gets triggered (so the user knows where they are, bottom or top) and then the controls popup gets showed again when the user moves the mouse to the area where the controls are. I see this bug is quite old, so lets do something to solve this gnome-wide?! But to be honest I've come to this bug because I had some problems with fullscreen controls I wanted to report: first: When I use the seek-bar something odd happens...After releasing the seek-slider the label with the current time gets changed (from "1:35 / 1:50" to "seek to 1:45 / 1:50"). It happens in the normal (non fullscreen) mode to, but thats not a problem because its below the seek bar. In fullscreen mode the label is right of the seek bar, changing the length of the label changes also the size of the seek bar, thats quite disturbing. second (minor): When I use the seek bar in non fullscreen mode with playback paused, the label with "seek to ..." appears only during drag/drop of the slider. After releasing the slider the label gets normal again, but when I switch to fullscreen after releasing the slider, the label in fullscreen mode is still "seek to ..." I hope I made my points clear...
(In reply to comment #23) > But to be honest I've come to this bug because I had some problems with > fullscreen controls I wanted to report: > > *snip* Would you mind filing these as a single new bug please? We don't want to dilute this bug. Thanks.
alright...but don't complain in the new bug: "why don't you go trough the old bugs first before setting up a new one?" :)
I just saw that I cannot reproduce this behavior in 2.24.3, so forget my issues :)
Anything new on this one? It's one of the reasons I use mplayer instead of Totem. Aside from annoying mouse behavior, the "Leave fullscreen" button is awful. Can you please remove it and instead make the context menu item a checkbox? I'd personally like the best if the controls got shown when mouse "touches" the bottom edge, and vanished when the mouse leaves the control area + some 50px. The movement detection and timeouts are terrible ("do it one more time and my head's gonna explode" kind of meaning), who came up with that?
Created attachment 150665 [details] [review] Patch to only show the controls when the mouse has travelled a certain amount of distance
commit aa769696289b1498e2c0cec00bc0f117ebf9f8d8 Author: Ralf Ebert <info@ralfebert.de> Date: Sat Jan 2 06:31:44 2010 +0100 Only popup controls when mouse moves a certain distance Only show the fullscreen popups when the mouse moves more than 30 pixels (or events) within 200 msecs. https://bugzilla.gnome.org/show_bug.cgi?id=331241