Open Moko Themes

[Tim Newsom]

On Wed, 13 Jun 2007 4:52, Buddy wrote:
> On 6/13/07, Emre Turkay <emreturkay at gmail.com> wrote:
>> On 6/12/07, Tim Newsom <cephdon at gmail.com> wrote:
>>>  This is where XAML or XUL are particularly suited.
>>>  The idea is that the UI will be mostly svg commands or in some cases
>>>  images.. But rendered completely by the engine.  Look up what you get
>>
>> Loading the burden of SVG rendering to the run-time, for a very static
>> environment like a mobile platform (you don't plug a screen with a
>> different resolution to your cell phone generally) IMHO not a very
>> good idea. They may be vector graphics at the development phase but
>> they should be compiled (translated into bitmap) before deployed onto
>> the real device.
>>
>> My motivation is, why should we decrease the performance to get the
>> same effects, both for UI eye-candy and usefulness?
>>
>> emre
>>
>
> SVG can be used for scaling with same resolution and the average
> filesize will be very small
>

Exactly what I was going to say.  Ok.. So imagine that you have this 
wonderful 640 x 480 screen.  Text is very readable to the average user.. 
However, the skin / theme is too small for some visually impared people 
in some circumstances....
Svg allows you to "magnify" with perfect clarity to any size without 
distortion.  Ok, but the text is a raster font (is that the right word?) 
not some vectorized font right? Does it have to be? Why not handle 
translation of rasterized to vectorized fonts for the magnified area? Is 
that possible? I don't know but I imagine it should be.  Or use 
vectorized fonts everywhere.

Going another way, with svg, you can "draw" perfect thumbnails of the 
current state of any application in a task manager context by rendering 
the view of that frame in a scaled "window".  You could even allow those 
windows to be interactive so that 2 applications could be operated side 
by side.

Without drawing and rendering each available scale of static image 
(which would be very huge in size) how else can you get the same 
functionality?

The ability to skin an application, move the buttons around and test out 
a new layout without altering a single line of application code is huge 
in my mind.  Also, the ability to "mashup" (to overuse an overused word) 
application functionality is huge too.

Example:
You have an ftp program but you don't necessarily like the file manager 
program... However, you have a file manager program you do like but you 
don't like the layout as much.. It would seem to me that if we build 
this correctly we should be able to combine which ever file manager and 
ftp program we want into a new (again...) "Mashup" and have something we 
like and never touch the application behind.  Why is this possible? 
Because drag and drop exist at the os level maybe... Or because the UI 
glue code can handle any correctly defined and used interface on the app 
code... Or because all file managers and ftp apps follow specific 
guidelines which allow combining them in new ways.

/shrug..

Ok.. Now do that with a static interface.
--Tim