GNOME Bugzilla – Bug 707828
Enable / disable dangerous timeline keyboard shortcuts by handling focus events directly in the timeline and ruler widgets
Last modified: 2013-09-25 14:21:14 UTC
In mainwindow, we have a "setActionsSensitive" method that basically just allows disabling or enabling the global keyboard shortcuts related to the timeline, including: - Space to play/pause - Delete to remove clips - S to split clips - etc. Even after fixing various issues throughout time (bug #629208, bug #597243, and various unreported problems that were solved through many commits related to "actions"), there are still some bugs with it. For example: select a clip on the timeline, focus a gtk widget that is supposedly protected (such as an effect property spinbutton, or the media library's search widget), try pressing Delete and the clip is not deleted... but then click the clip again, click the search widget again, press Delete and... whoops, the clip is gone! That's because we were relying on focus events on the search widget, but the focus didn't change. And that's the case all over the place. Turns out that the way we handle this is all backwards. The cleaner and (probably) safer way is to set the can-focus (can_focus) property on the timeline canvas and on the ruler widget, and then connect them to their focus-in-event and focus-out-event to handle the setActionsSensitive stuff there and *only* there. As far as I can see, if you handle it in those two widgets, no need to handle it anywhere else anymore. Epic win. But then, at this point you might start thinking that setActionsSensitive probably shouldn't be in mainwindow anymore (should it be in timeline/timeline.py?), and might also be named differently... This is all so exciting, I'll certainly make a patch for this soon ;)
commit 13621422fc5e2d4317f299bce06205987477e466 Author: Jean-François Fortin Tam <nekohayo@gmail.com> Date: Tue Sep 10 22:25:00 2013 -0400 pitivi: Rely on timeline widgets' focus to set actions/shortcuts sensitivity This greatly simplifies the code (present and future) and makes the whole app incredibly more reliable when it comes to preventing "dangerous" timeline shortcuts (such as Delete/Spacebar) from interfering with other GTK+ widgets. Fixes bug #707828 commit 4dde28b0753eff4548de51565721c1af6fe34d85 Author: Jean-François Fortin Tam <nekohayo@gmail.com> Date: Tue Sep 10 22:16:44 2013 -0400 timeline: Connect button press/release to the timeline, not the whole stage Signal handling is then more specific, preventing useless (and wrong) stuff from happening when clicking layer controls instead of the timeline canvas. This is in preparation for making focus-based timeline actions sensitivity work. commit 406362694b61261b74f6b82d805e6dae79c2b3ba Author: Jean-François Fortin Tam <nekohayo@gmail.com> Date: Tue Sep 10 21:44:01 2013 -0400 Pass the proper arguments to the audio/video layer controls Passing self (the ControlContainer instance) as if it was "app" is a lie. Lying is bad, and causes things to go wrong. This fixes some tracebacks when trying to access other parts of the UI, which lays the groundwork to allow handling timeline actions sensitivity properly.