GNOME Bugzilla – Bug 722196
viewSelector: Move to a sync() model for deciding which page to show
Last modified: 2019-02-27 20:00:14 UTC
See patch. This is part of my overview transition cleanups.
Created attachment 266276 [details] [review] viewSelector: Move to a sync() model for deciding which page to show
Review of attachment 266276 [details] [review]: I don't really get what this is trying to fix, this is working code, and you're not really untangling it. ::: js/ui/viewSelector.js @@ +119,3 @@ Main.overview.connect('showing', Lang.bind(this, function () { + this._showAppsButton.checked = false; How can showAppsButton.checked be true at this point? @@ +125,3 @@ Main.overview.connect('hiding', Lang.bind(this, function () { + this._showAppsButton.checked = false; Doesn't this trigger a transition from apps to windows while closing?
(In reply to comment #2) > I don't really get what this is trying to fix, this is working code, and you're > not really untangling it. It's part of my work to fix the overview transition when launching an application. I figured this was worth a cleanup as it is. I agree that it's still quite messy though. Entire branch is (WIP) at: https://git.gnome.org/browse/gnome-shell/commit/?h=wip/overview-transition > ::: js/ui/viewSelector.js > @@ +119,3 @@ > How can showAppsButton.checked be true at this point? I don't know, but resetShowAppsButton was called here before, and I remember something breaking if I didn't do this. > @@ +125,3 @@ > Doesn't this trigger a transition from apps to windows while closing? Yes, but that's already what happens. That's what the overall branch is trying to fix.
(In reply to comment #3) > (In reply to comment #2) > > I don't really get what this is trying to fix, this is working code, and you're > > not really untangling it. > > It's part of my work to fix the overview transition when launching an > application. I figured this was worth a cleanup as it is. I agree that it's > still quite messy though. > > Entire branch is (WIP) at: > > https://git.gnome.org/browse/gnome-shell/commit/?h=wip/overview-transition WIP indeed - the stacking order in https://git.gnome.org/browse/gnome-shell/commit/?h=wip/overview-transition&id=ac1d5ba00c0e02ae1c25b0ddaf37f44fa011b9fa is wrong, because it puts top_window_group below the panel > > ::: js/ui/viewSelector.js > > @@ +119,3 @@ > > How can showAppsButton.checked be true at this point? > > I don't know, but resetShowAppsButton was called here before, and I remember > something breaking if I didn't do this. > > > @@ +125,3 @@ > > Doesn't this trigger a transition from apps to windows while closing? > > Yes, but that's already what happens. That's what the overall branch is trying > to fix. This is not the case, windows appear for a different reason (if you look at the workspace switcher, it's not visible when you exit the overview). Indeed, your last patch in the branch reintroduces showAppsBlocked for this.
Any plans for picking this up at some point? Carlos did clean up the overview transition last summer, so I suppose the original motivation for the branch is obsolete?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!