On Wed, 13 Jun 2007 11:15, John Seghers wrote:
Tim Newsom wrote
As I understand it, you would not even need to build a different svg
file. You could use the same one and it could automatically scale
because the engine would scale it.. It should be possible (in my
mind)
to take a layout
Tim Newsom wrote
> As I understand it, you would not even need to build a different svg
> file. You could use the same one and it could automatically scale
> because the engine would scale it.. It should be possible (in my mind)
> to take a layout for 320 x 240 and draw it perfectly at 648 x 480.
i would exchange 3D hardware support in Neo for OpenVG hardware support
anytime! that way we could use SVG (or such) for everything, windows,
buttons, etc...
http://en.wikipedia.org/wiki/Openvg
.andre
p.s. or atleast Cairo (or similar) with OpenGL to accelerate vector
graphics, as 3D in 2D scree
On Wed, 13 Jun 2007 7:08, Emre Turkay wrote:
On 6/13/07, Peter A Trotter <[EMAIL PROTECTED]> wrote:
If the application is then used on a different form factor device you
can
simply produce a new SVG file. All the UI script and images are linked
to
the SVG.
This also gives us a nice separatio
On 6/13/07, Peter A Trotter <[EMAIL PROTECTED]> wrote:
If the application is then used on a different form factor device you can
simply produce a new SVG file. All the UI script and images are linked to
the SVG.
This also gives us a nice separation of people who are good at making things
look go
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 completel
I was fingering SVG as a potential candidate to entirely separate the
application UI from the back end (html/ajax has been suggested elsewhere but
I think SVG would be far better)
What about cairo then ?
___
OpenMoko community mailing list
community@l
On 13/06/07, Buddy <[EMAIL PROTECTED]> 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 re
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
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, fo
Tim Newsom 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.
>
> On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote:
> > UI for these different screen resolutions and po
Luit van Drongelen wrote:
> (most phones
> and PDAs are QVGA).
Actually most phones sold today are 176 x 220, whereas most PDAs are QVGA.
There's still a lot of phones today that are 128 x 160 and the Sidekick III
is still 240 x 160.
- John
___
OpenM
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
for using it and you will see what I am talking about. There is work to
be done getting XAML to function
UI for these different screen resolutions and potentially form factors is
going to be more then a case of image resizing. It will be whole different
layouts. I am quickly coming round to the idea of a near complete separation
of GUI from application. It is the only way to really present the same a
Making your icons/panels/butons in svg-format and make a shell-script that
(using imagemagick for example) converts all of them to the requered
resolution in png.
It shouldn't be the worry of the designer in what resolution use intend to
use OpenMoko.The program/GTK should take care of that.
On
I think the first theme concern should be different resolutions.
Currently there's just a VGA theme, but QVGA and WQVGA (i guess...
480x272 anyways) for future phones, and non-FIC phones. (most phones
and PDAs are QVGA).
At least I'd like to see that come soon.
--
LuitvD
On 6/12/07, Jon Philli
On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote:
> I know that there are going to be themes for the OpenMoko interface,
> but I'm just wondering if there is anyone who has started working on
> alternate themes? I think I'd like to take a crack at it, and I was
> curious if anyone has had any
17 matches
Mail list logo