GNOME Bugzilla – Bug 581771
Chrome (aka the shell UI bits that are in the normal desktop view)
Last modified: 2009-05-15 20:15:47 UTC
For the sidebar, we need to add some additional clutter actors that behave the same way as the panel: they cause the input area to be adjusted, they create struts, they have to be hidden when there's a fullscreen window open, etc. This consolidates the current Main.addShellActor() code and the Panel window-stacking-watching code into a new object, Chrome, which creates a Clutter.Group for all the actors in the shell's UI, and does the right things with them. Most of the complicated entirely-new bits (ie, having additional input-region-modifying windows that are children of other windows in the chrome and don't modify the struts) are to support sidebar pop-out. I don't know if "Chrome" is the best name. I'm happy to change it if someone suggests something else. The patch won't apply cleanly without the overlay patch in bug 581769, but it will work fine if you resolve that conflict.
Created attachment 134209 [details] [review] Improve the framework for managing shell UI Adds an explicit "chrome" layer for the panel (and later the sidebar), managing the input region and struts for them, and hiding them when fullscreen windows are present.
Looks good to me. Chrome sounds good as a name, but a comment at the top of chrome.js explaining it would help, since it isn't immediately clear. There's obviously some lack of robustness in the tracking - if we track an actor, then track then untrack it's parent, for example. (You'd probably need another refcount for tracking children.) I'm not too worried about it, though it might be good to leave a comment mentioning it in case someone comes through hunting some weird "input struts get out of sync" bug.
Created attachment 134660 [details] [review] Update chrome framework This fixes some things you noted in the previous comment, plus the bug we'd both noticed where the sidebar struts got removed when going into the overlay
*** Bug 582671 has been marked as a duplicate of this bug. ***
Created attachment 134671 [details] [review] Panel should always be visible when overlay is visible Fix for bug 587671
Looks reasonable. Maybe a bit more readable to have chrome.addActor(actor); chrome.setActorVisibleInOverlay(actor, true); Rather than chrome.addActor(actor, true); ? (sometimes you really missed Python keyword arguments...)
committed iwth that change