Re: Open Moko Themes
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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 good and those of us who know the loop preconditions / postconditions without even thinking. If openmoko is to deal with multiple different devices/resolutions this will be a key feature. I totally agree that openmoko graphics should be in a vector graphics format. Generate the bitmaps bigger for neo and maybe smaller for iphone, etc. Storing the generated bitmaps in .png or .svg files does really don't much matter. If .svg provides embedding bitmaps, why not. emre ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 separation of people who are good at making things look good and those of us who know the loop preconditions / postconditions without even thinking. If openmoko is to deal with multiple different devices/resolutions this will be a key feature. I totally agree that openmoko graphics should be in a vector graphics format. Generate the bitmaps bigger for neo and maybe smaller for iphone, etc. Storing the generated bitmaps in .png or .svg files does really don't much matter. If .svg provides embedding bitmaps, why not. emre 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.. Any image bitmaps would be out of sync unless you changed them but if its all done in svg it would render perfeclt. Same the other way.. All ratios would be the same (assuming a smaller display in the same orientation and proportional dimensions) so the exact same skin and theme would not need translation at all (except any embedded bitmaps). Again, that's how I understand it currently. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
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.. Scaling up vector graphics is certainly less likely to cause problems than scaling down. However, when you start talking about QVGA or smaller, every pixel counts and hand-tuned graphics are going to give a better presentation than generated graphics. However, even staying at the same DPI... what about a landscape vs. portrait orientation? Moving from 640 wide x 480 high to 480 wide x 640 high is going to need more than scaling. You are going to want to use the display differently. So yes, a different SVG file would likely be needed. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 for 320 x 240 and draw it perfectly at 648 x 480.. Scaling up vector graphics is certainly less likely to cause problems than scaling down. However, when you start talking about QVGA or smaller, every pixel counts and hand-tuned graphics are going to give a better presentation than generated graphics. However, even staying at the same DPI... what about a landscape vs. portrait orientation? Moving from 640 wide x 480 high to 480 wide x 640 high is going to need more than scaling. You are going to want to use the display differently. So yes, a different SVG file would likely be needed. - John If you will check the snipped out portion of my email, you should notice that I mention the assumption you are in the same orientation.. I will grant you that every pixel counts, but if each portion of the display is drawn with vector graphics and unless you are going way beyond the capabilities of the display... Within reasonable bounds the display should scale correctly. As for different orientation, sure, make 2 files for the alternate layout.. But that's incredibly more efficient than making 30 bitmaps (images or whaterever you call them) for each resolution setup and orientation combination. Granted, its my opinion. Granted, rendering a vectored image takes more processing than blitting an image from memory to the screen.. But from what I heard last time, at least the first public version of the neo will have a hardware graphics processor to handle most of that work. And anyway, I don't have a good feeling for the amount of time it would take to render a screen (skin which is theme plus layout) for something like the neo but without graphics processor. I am simply stating my own opinion and I expect others to do the same. /grin that's what the community is all about right? Someone with some extensive svg experience in this realm can give real hard core information. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 Phillips [EMAIL PROTECTED] wrote: 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 start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: 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 Phillips [EMAIL PROTECTED] wrote: 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 start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 apps on the different Openmoko hardware platforms. At the same time I am not convince that html is the way to go. What are the options here? -Pete On 12/06/07, Frank Coenen [EMAIL PROTECTED] wrote: 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 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: 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 Phillips [EMAIL PROTECTED] wrote: 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 start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 on linux.. But it would be worth the effort, IMHO. BTW, mono has started a project called moonlight which aims to bring silverlight applications to mono. Maybe we can help accelerate some of that work? --Tim On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote: 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 apps on the different Openmoko hardware platforms. At the same time I am not convince that html is the way to go. What are the options here? -Pete On 12/06/07, Frank Coenen [EMAIL PROTECTED] wrote: 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 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: 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 Phillips [EMAIL PROTECTED] wrote: 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 start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
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 potentially form factors is going to be more then a case of image resizing. It will be whole different layouts. Peter brings up a very good point. As images get smaller--because of fewer pixels available, not smaller pixels--it becomes much less reasonable to use scaled artwork. Whether that is SVG rendered into the smaller pixels or bitmaps resized, when you get down to the sizes required for today's common screen sizes, you need hand-tuned artwork. Working in the games industry since 1981, I've seen many kinds of artists. Most of today's artists do not have the skills to work at the pixel level. They may be wizards in Maya or 3DS Max, but couldn't design a 16 x 16 icon if their life depended on it--much less an animation in that many pixels. Having the combination of ability and patience to push the pixels around is a rare thing--but one absolutely necessary for a polished interface on a 1/8th VGA device. When we're dealing with a 300dpi VGA screen, the on-the-fly rendering from XML/SVG may be great. But it's not a panacea. On the other hand, I think it would be great to be able to not only skin individual apps, but be able to combine elements from multiple apps into one presentation. For example, suppose you had a CRM (customer relations) database wherein you kept notes about your clients. It would be great if the last note from that were available on the incoming call screen along with their name. But that would require a customized incoming call screen that aggregated the output of the dialer and the CRM app. At JavaOne there was a presentation on JSR 258 about a skinning architecture, but it only seemed to address appearance of elements, not layout nor the ability to combine features. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
