Dialer UI Design

[Nishit Dave]

On Tue, Sep 30, 2008 at 6:55 PM, Alex Osborne <ato at meshy.org> wrote:

> You mean start Mofi, then switch to a different app and back to the
> still running Mofi? The window renders virtually instantly for me,
> there's a little flash of it redrawing but you really have to watch
> for it and it's not noticeably worse than any other app.  I'm
> switching between xterm and Mofi on Debian on the FreeRunner.  The
> fact I can't see it could be due to Debian using a different GTK
> theme, I notice the font (and hence all the widets) are much smaller
> on Debian than on OM 2007/8, so it might render faster.
>

It might be because I use a Qtopia-based installation (2008.8-update) then,
and GTK might run better on Debian 'natively', I guess.


>
> The fact that Python is used for the application logic should have
> zero effect on the redraw speed.  This is because the code that does
> the drawing (GTK), is actually written in C.  The Python code tells
> GTK once when the window is created, "hey I want five buttons and a
> textbox with this text, in this arrangement, you figure out the
> rest", it's then GTK's responsibility to redraw them and tell python
> when a button gets clicked or a menu item is selected.  In a normal
> application that's just using standard widgets and not doing any
> custom drawing, redraws (like switching between applications)
> shouldn't execute any Python code at all.
>

This is very informative, thanks.  I still have the feeling that GUI
performance is poor when the executable is written in python.  Maybe its
just me.


> But for typical GUI programs processor speed is usually largely
> irrelevant as long as the underlying toolkit is not completely
> broken.  If a GUI is not responding it's a problem with how the
> program is structured, it should be doing something asynchronously
> instead of blocking the event loop.
>
> I just hope everybody follows best practices.  At the end of the day, all I
need is something that is responsive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080930/4b58e66a/attachment.htm