[sugar] [PATCH] REVISED screenshots hurt

[Eben Eliason]

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 <erik at laptop.org> 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
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
>