This seems like a decent, but lossy reduction. (Though I agree in full that the current behavior is far less than ideal.) There are still some ugly cases, though, which can't be fixed without compositing. Am I correct in thinking this assumes that the activity is visible while keep/close buttons or shortcuts are activated? If the user reveals the Frame and accesses these commands via the activity menu, the Frame will be in the screenshot. Moreover, they might be in another activity, or another zoom level entirely, and actually get misleading screenshots instead of none at all.
Should we verify that the activity is the active one, and that the desktop is not shown, before taking an invalid screenshot? Also, when is compositing potentially coming? Is it necessary to do this for 8.2.1 if we'll have a far better solution which handles all cases in a release or two? - Eben On Fri, Sep 5, 2008 at 12:31 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > Devs, > > Attached to this email are both the original patch, which removes > automated screenshot acquisition from the sugar shell, and a patch to > activity.py in sugar-toolkit which adds screenshot acquisition to the > user-directed 'keep' (save) event, so that the screenshot can appear in > the journal when the user explicitly selects to save their work. > > Note that the keep event previously did not acquire a screenshot-- it > was apparently assumed that it would have been acquired previously by a > tabbing event. Additionally, two screenshots were acquired on every > close event (one in the Shell.py code and one in the activity.py code). > > The effect of these patches is to retain the benefits of screenshots > without incurring their costs on every window navigation event. Only > user-directed 'close' and 'keep' events now trigger the screenshot. > This means that there will always be screenshots after activities > properly exit, or when the user elects to save data. Other automated > screenshot events are removed so that system responsiveness does not > suffer during window manager navigation. > > before, screenshots taken on these events: > - frame visibility > - tabbing start > - activity next tab > - activity previous tab > - zoom into activity view > - activity close (twice) > > after, screenshots taken on these events: > - activity close (once) > - activity keep / save > > Comments welcome. Please test and report results. > > Erik > > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar > > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
