Mini-Conference Proposal: sugar performance

Tomeu Vizoso tomeu at tomeuvizoso.net
Sun Mar 23 14:32:58 EDT 2008


On Sun, Mar 23, 2008 at 7:01 PM, Gary C Martin <gary at garycmartin.com> wrote:
>  On 23 Mar 2008, at 17:13, Tomeu Vizoso wrote:
>  > - Move datastore and sharing initialization later after the UI has
>  > been launched, the user won't be able to start working sooner, but
>  > will be given a better idea of the launching process (will feel
>  > faster).
>
>  I think we spoke a little about this a few weeks back. What happens if
>  the UI needs access to datastore, metadata, or sharing details to
>  actually present it's UI for the task at hand? For example, launching
>  Speak activity from the Journal requires the face to be drawn with
>  preference data from the datastore (number of eyes, eye shape, mouth
>  shape, spoken language).
>
>  Currently most UI layout is just done in the activities main __init__
>  and this is already a limitation if the activity needs datastore
>  information before drawing the UI. If the activity is started from
>  Journal, then a read_file() method can catch the data availability and
>  draw the required UI. If the activity is started from fresh then there
>  is  nothing other than the __init__ call. With Moon activity, I've had
>  to put in an (arbitrary 50ms) event timer in my __init__ so I do not
>  draw the UI right away. Then, if read_file() is triggered, I remove
>  the event timer and draw the UI for the data that just became
>  available. If read_file() is not called, or not called within my event
>  timer delay, then the timer eventually fires and triggers a default UI
>  draw. Not an idea solution.
>
>  It would be useful to have 3 methods called during activity set-up:
>
>         __init__ # set-up what you can
>
>  then either:
>
>          read_file() # for when there is journal data
>
>  xor:
>
>         clean_start() # for when there is no journal data

Well, what I expected from activities is something like what happens
in Read and Write. Both use a quite complex widget as their "meat":
Abiword's abiwidget and Evince's view.

Both these widgets can be inserted in the hierarchy and will be drawn
empty. If you set a PDF or ODT document, that document will be
displayed.

Basically, we can summarize this issue as moving things to be async.
If everything is synchronous, the result of the user actions will last
longer to appear on the screen, and the users thinks that nothing is
happening and that something wrong happened.

The idea is that, instead of waiting 5 seconds for the full UI to
appear, the activity window would appear after, say, 3 seconds, half a
second later the document will get loaded, and half a second later the
user will be able to share the activity or invite somebody.

Can your activities do something about this?

Tomeu



More information about the Devel mailing list