On Wed, 13 Jun 2007 4:52, Buddy wrote:
On 6/13/07, Emre Turkay <[EMAIL PROTECTED]> wrote:
On 6/12/07, Tim Newsom <[EMAIL PROTECTED]> 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
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
