Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Marcin Juszkiewicz wrote: Dnia środa, 13 czerwca 2007, Werner Almesberger napisał: Shawn Rutledge wrote: What is your favorite hardware and software for doing this? We use our own debug board. You need a special flexible cable to connect to JTAG (*), and our board has the corresponding connector. Debug board has also space to solder standard 20 pin ATM JTAG header and after that can be used with other devices then Neo1973. My friend used it to debug his own AT91 based project. Heck, they could probably make money selling the debug board separately. Any embedded software developer probably has a ton of jerry rigged MAX232 level shifter dongles, USB<->232 dongles and USB<->JTAG dongles. This all in one design is sweet. cheers, Bryan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wiki write access limited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joachim et al. Might I suggest . . . http://www.recaptcha.org Stops those pesky bots and helps archive.org at the same time. I use it on my Drupal site and it's cut the bot comments, etc. to zip. mischa Joachim Steiger wrote: > due to a lot of spam/edits by bots we now have limited the write > access to users who have registered a working email-address. were > sorry for that. > > please report when there are any new bugs due to this. > > regards > > -- > > roh > > ___ OpenMoko community > mailing list community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcIfEApSbE1MX5IIRAuvEAKDfvDFln9rpsb+Mxmaorp3DnT5AxQCgicWE VGg/MyHBSwlOQl7dXjQZnWc= =COoZ -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concern for usability and ergonomics
I agree. Different needs should be addressed in different products, not everything put into one device. I understand people wanting an OpenMoko keyboard phone. I don't have any real use for buttons on a touchscreen phone, though. (Other than for gaming.) Ortwin On 6/11/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote: Sean Moss-Pultz writes: > >On Jun 11, 2007, at 6:36 AM, Miguel A. Torres wrote: >> >> * Integrated keyboard and directional pads are not mere luxuries, >> but necessities. They allow for safe one hand operation while >> reducing touchscreen stress. Touchscreens are fragile (get >> scratched easily, develop calibration issues over time, etc) and >> direct finger use requires constant cleaning. While some people regard an integrated keyboard as a necessity, there are also those of us who prefer no keyboard. One of the main reasons I never replaced my Samsung I-300 with a Treo is that you can't get a Treo without a keyboard. It's certainly good to consider those users who regard a keyboard as a necessity. Please don't forget the people who don't agree, though! >> Treo is an excellent design in terms of usability. It's been >> designed with real people in mind. For example, it provides >> hardware volume buttons and a switch to turn the phone mute. More buttons, on the other hand, I agree with -- particularly buttons that can be used as hardware volume control (notice that's not quite the same thing as hardware volume control buttons! On my Samsung, those same buttons work very nicely as scroll buttons when reading documents). ___ 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: Neo1973 Update!
On 6/13/07, Lars Hallberg <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] skrev: And for games... Think flipper with tilt :-) Come on, be more creative than that! I try to be: http://forum.gbadev.org/viewtopic.php?t=13365 (The Neo1973 GTA-02 probably won't have the rotation sensor, though.) Ortwin ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wiki write access limited
Joachim Steiger wrote: due to a lot of spam/edits by bots we now have limited the write access to users who have registered a working email-address. were sorry for that. A pretty obvious step, that most Wikis have taken or will soon. The last few will probably be forced to (or shut down) by the courts when somebody posts something really bad and they can't prove who did it. No need to apologize, and thanks for being part of this project! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
On 6/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It's all on the wiki. I beleive there is a page describing how to download and set up the debugger. It's standard gdb (for ARM of course) with the appropriate software (drivers?) for the Neo/USB interface card. I think the USB port shows up as a serial port. Come to think of it there may be no need for drivers. Yes I found this http://wiki.openmoko.org/wiki/Debug_Board so it makes more sense now. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Dnia środa, 13 czerwca 2007, Werner Almesberger napisał: > Shawn Rutledge wrote: > > What is your favorite hardware and software for doing this? > > We use our own debug board. You need a special flexible cable to > connect to JTAG (*), and our board has the corresponding connector. Debug board has also space to solder standard 20 pin ATM JTAG header and after that can be used with other devices then Neo1973. My friend used it to debug his own AT91 based project. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Don't mud-wrestle with a pig. You'll both get dirty and the pig loves it ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
wiki write access limited
due to a lot of spam/edits by bots we now have limited the write access to users who have registered a working email-address. were sorry for that. please report when there are any new bugs due to this. regards -- roh ___ 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: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
JTAG is basically a way to inspect and/or set each and every register on the processor, not only the registers you're familiar with from a programmer's point of view, but also registers that might hold the state of input and output pins, etc. Also since you can control each register and single step the processor, you can use JTAG to peek and poke to every address or register that the processor can access on other chips, e.g. RAM. This is slow, of course, but is very powerful. It's all on the wiki. I beleive there is a page describing how to download and set up the debugger. It's standard gdb (for ARM of course) with the appropriate software (drivers?) for the Neo/USB interface card. I think the USB port shows up as a serial port. Come to think of it there may be no need for drivers. Hopefully this will give you some pointers. If you want to become really popular, take notes as you go along, and then post them on the wiki as the start of a JTAG howto. Would be very useful. Michael On Wed, 13 Jun 2007, Shawn Rutledge wrote: Would you post more details about this please? I have used JTAG for programming Atmel micros but am not yet very familiar with how it is used for "system exploration" when there are multiple devices on the bus. What is your favorite hardware and software for doing this? On 6/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Good points, Joe and Rod. To add to this, consider that this device has a JTAG port, and that you can buy the necessary interface card and cable for $150, and that the debugger is open source. So even with though the hardware was not promised to be open, we have tremendous visibility into it. ___ 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: @Sean: please check off
C'mon guys! If Sean could answered us, he surely would. Apparently, he can't make any public statement yet... cayco ___ 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: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Shawn Rutledge wrote: > used for "system exploration" when there are multiple devices on the > bus. We only have the Samsung MCU in the JTAG chain. > What is your favorite hardware and software for doing this? We use our own debug board. You need a special flexible cable to connect to JTAG (*), and our board has the corresponding connector. (*) In a phone, there isn't nearly enough space for one of the JTAG connectors you have on eval boards and the like. You could probably roll you own, though, and use some other JTAG adapter, e.g., the cute little Amontec JTAGkey. On the software side, we use OpenOCD. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Would you post more details about this please? I have used JTAG for programming Atmel micros but am not yet very familiar with how it is used for "system exploration" when there are multiple devices on the bus. What is your favorite hardware and software for doing this? On 6/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Good points, Joe and Rod. To add to this, consider that this device has a JTAG port, and that you can buy the necessary interface card and cable for $150, and that the debugger is open source. So even with though the hardware was not promised to be open, we have tremendous visibility into it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [openmoko-announce] Some light ahead...
On Tuesday 12 June 2007 21:28, Ivan -sk8- Chavero wrote: > Hello, > > I want to start developing apps for openmoko but i haven't being able to > find any tools for that. i have browsed the wiki, projects and the other > sections of the website and no luck. Instructions for building the full dev environment complete with qemu for emulating the neo hardware are in the Wiki http://wiki.openmoko.org/wiki/MokoMakefile > I'm interested on developing some thin client apps on the openmoko > framework as a proof of concept for my masters thesis on low coupled > distributed applications so it would be great if somebody could give me > some links for the documentation and developer tools. > > P.D. I also want to purchase a phone it looks like a very interesting > combination technology and philosophy!! > > thanks in advance. > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [openmoko-announce] Some light ahead...
Have you already find the MokoMakefile? http://wiki.openmoko.org/wiki/MokoMakefile -Steven On 6/12/07, Ivan -sk8- Chavero <[EMAIL PROTECTED]> wrote: Hello, I want to start developing apps for openmoko but i haven't being able to find any tools for that. i have browsed the wiki, projects and the other sections of the website and no luck. I'm interested on developing some thin client apps on the openmoko framework as a proof of concept for my masters thesis on low coupled distributed applications so it would be great if somebody could give me some links for the documentation and developer tools. P.D. I also want to purchase a phone it looks like a very interesting combination technology and philosophy!! thanks in advance. Sean Moss-Pultz wrote: > Dear Community, > > We owe you all an update as to our status. Here it goes... > > Last week we finished 200 devices. Of these about 50 seem to have some > problems but the rest are functionally complete, tested, and ready to > go. We know the source of the problems for the 50 that failed and this > is already corrected. This is great news because it means we can finally > start to move out of engineering sample mode and into real production! > > These first 150 (or so) devices will go to phase 0 developers and our > internal / external developers -- of which many still don't even have > phones! > > Oh and Imre Kaloz gets a freed phone, too. Thanks for being the first to > tell us about Atheros. We're almost for sure going to use their AR6K > chipset in our next product. > > We must forewarn you all that we're having some supply issues with our > 2.8" VGA LCM. Our vendor has had more than their fair share of troubles > moving this LCM into mass production. We have some in stock now. But > this might be the major bottleneck moving forward. There are only a few > companies currently making LCMs of this size and resolution. > > Finally, we've already begun moving production into one of our factories > in mainland China. There are two runs scheduled now: May 10th and May > 20th. We're going to take those runs a bit slow just to make sure the > quality is high. And then starting in June, things can run full speed. > > Thanks again for your continued support and patience. The light at the > end of the tunnel is getting a little brighter :-) > > Sincerely, > > The Core Team > > > > ___ 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
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 screen is somewhat useless... On Tue, 2007-06-12 at 11:55 +0200, Frank Coenen 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
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: Will Openmoko ever see the light of day? Was Re: Concern for usability and ergonomics
Duncan... Let me just add to what Sudharshan said... There is a stunning amount of variability in the mobile device supply chain. I used to work for Gibson Musical Instruments, where we were designing what was effectively a custom PDA (don't ask.) There were several delays, including about 9 months where we were waiting for parts to arrive at the factory. You get on the phone and you send over a PO number and you get a contract for delivery of a certain part and then you wait. And wait, and wait. And it never shows up. Then you get back on the phone and eventually you find another parts distributor. Since then, I've started taking delivery dates with a pretty large grain of salt. BTW, I've seen prototypes of the Neo 1973, and it has a lot of parts under the hood. If you guess that one in twenty parts could be problematical, there's plenty of opportunity for delay. At some point I'll have to tell you my story about the Nokia 770 I eventually got. -Cheers -Matt H. On Jun 13, 2007, at 6:26 AM, Duncan Hudson wrote: denis wrote: That is something I would like to know as well. The statement ist not really clear and seems to be very misterious. I don't know. In all honesty, has there ever been a really clear statement about this device? I'm beginning to feel (as was eluded to in others' posts months ago) that this is vaporware, and that we are just being strung along.Flame me all you want, but until I have something in my hot little hand how can I possibly be led to believe anything else at this point? Dunc ___ 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: [openmoko-announce] Some light ahead...
Hello, I want to start developing apps for openmoko but i haven't being able to find any tools for that. i have browsed the wiki, projects and the other sections of the website and no luck. I'm interested on developing some thin client apps on the openmoko framework as a proof of concept for my masters thesis on low coupled distributed applications so it would be great if somebody could give me some links for the documentation and developer tools. P.D. I also want to purchase a phone it looks like a very interesting combination technology and philosophy!! thanks in advance. Sean Moss-Pultz wrote: Dear Community, We owe you all an update as to our status. Here it goes... Last week we finished 200 devices. Of these about 50 seem to have some problems but the rest are functionally complete, tested, and ready to go. We know the source of the problems for the 50 that failed and this is already corrected. This is great news because it means we can finally start to move out of engineering sample mode and into real production! These first 150 (or so) devices will go to phase 0 developers and our internal / external developers -- of which many still don't even have phones! Oh and Imre Kaloz gets a freed phone, too. Thanks for being the first to tell us about Atheros. We're almost for sure going to use their AR6K chipset in our next product. We must forewarn you all that we're having some supply issues with our 2.8" VGA LCM. Our vendor has had more than their fair share of troubles moving this LCM into mass production. We have some in stock now. But this might be the major bottleneck moving forward. There are only a few companies currently making LCMs of this size and resolution. Finally, we've already begun moving production into one of our factories in mainland China. There are two runs scheduled now: May 10th and May 20th. We're going to take those runs a bit slow just to make sure the quality is high. And then starting in June, things can run full speed. Thanks again for your continued support and patience. The light at the end of the tunnel is getting a little brighter :-) Sincerely, The Core Team ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Will Openmoko ever see the light of day? Was Re: Concern for usability and ergonomics
On Wed, 2007-06-13 at 09:26 -0400, Duncan Hudson wrote: > In all honesty, has there ever been a really clear statement about this > device? I'm beginning to feel (as was eluded to in others' posts months > ago) that this is vaporware, and that we are just being strung along. > Flame me all you want, but until I have something in my hot little hand > how can I possibly be led to believe anything else at this point? > > Dunc Hi Dunc, Maybe this will change your mind, http://rene.rebe.name/photos/?p=/Computex/2007/img_2208.jpg Sure, the neo may get delayed, but it will definitely see the light of the day. I am basing my assertions on the fact, that actual devices have been created and circulated among people. I guess its pretty normal for things to get delayes. So fear not :D Just my 2 cents. Reggies Sudharshan S ___ 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 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
Announce list
I see the last official announcement was made 25th of April. I really dont want to start this whole thing again, BUT, can we please get another update? Even if its just, "we dont know when" answer. Thanks E-Mail disclaimer: http://www.sunspace.co.za/emaildisclaimer.htm ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: R: Openness (was RE: Concern for usability and ergonomics)
On 13/06/07, Michele Manzato <[EMAIL PROTECTED]> wrote: John Seghers Wrote: > Jonathon Suggs wrote > > There will always be complainers, that is just life...ignore them. > > It is, indeed, the complainers that I was commenting on. The one > that I quoted was complaining that stuff was being hidden from us > because FIC is working on new specs and hasn't shared them yet. Alright, here's the complainer. You know, complaints make projects grow (or fail) as much as compliments do. Both are useful, or needed. By the way I'm happy to read that you know what FIC is at. I don't. Indeed there's something going on in the backstage and we are intentionally keep out of it. I'm not saying that FIC hasn't the right to do so, they are a commercial company so their first targets must be market and sales. But this policy is going to impact the software part of it, which is meant to be open and to which we'd like to contribute to. Some months ago Sean suggested a few more fancy Openmoko-based devices. Well, fine, but how will this affect the evolution of the OpenMoko software stack? Are we really likely to make sensible suggestions (or sensible discussions) if we don't know the big picture? Sean is promising more focus and resources, but on which targets? That are the problems. I'm really looking forward to the next month and the coming back of the Openmoko leader. Until then, we're just a bunch of friends fancying around a wannabe phone. Nicely put. -Pete --- sorry about pm... Br Michele ___ 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
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@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Will Openmoko ever see the light of day? Was Re: Concern for usability and ergonomics
denis wrote: That is something I would like to know as well. The statement ist not really clear and seems to be very misterious. I don't know. In all honesty, has there ever been a really clear statement about this device? I'm beginning to feel (as was eluded to in others' posts months ago) that this is vaporware, and that we are just being strung along. Flame me all you want, but until I have something in my hot little hand how can I possibly be led to believe anything else at this point? Dunc ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 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. I agree totally about images. However, as I understand it the SVG spec is for far more than drawing pretty pictures. It also allows the embedding of these generated images. 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) 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. -Pete 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 ___ 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
First hands on with the Asus-Intel sub 200$ ultra notebook and it's Linux OS
Hi; talking embedded interfaces: Check it out http://www.hothardware.com/articles/Hands_on_with_the_ASUS_Eee/?page=2 Two modes: * beginner: boasting a trivial but interesting GUI * advanced: something that looks like KDE Nothing revolutionary i guess, but yet another example. Hope they'll release it in compliance with GPL Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
@Sean: please check off
It all boils down to ==8<==8> [ ] Hello Did i mention [ ] you may *now* preorder GTA01 units :-) [ ] we expect you'll be able to preorder GTA01 units in [ ] June [ ] July [ ] August [ ] some time later [ ] we are only making a few GTA01 units and selling/giving them to developers, not to everyone who is interested. [ ] Basically, GTA01 is dead. Wait for GTA02. Regarding GTA02, [ ] we expect GTA02 units to be ready [ ] Q3/2007 [ ] Q4/2007 [ ] Q1/2008 [ ] later [ ] GTA02 will be more expensive than GTA01. Our current guess: US$___ [ ] sorry to keep you waiting [ ] kthxbye ==8<==8> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home Brew StarTrek Communicator
On 6/12/07, Ian Stirling <[EMAIL PROTECTED]> wrote: Using really good coding, in good channel conditions, you may get 20 megabytes a second. Actually 10 MBits/sec = 1.25 MBytes/sec ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
R: Openness (was RE: Concern for usability and ergonomics)
John Seghers Wrote: > Jonathon Suggs wrote > > There will always be complainers, that is just life...ignore them. > > It is, indeed, the complainers that I was commenting on. The one > that I quoted was complaining that stuff was being hidden from us > because FIC is working on new specs and hasn't shared them yet. Alright, here's the complainer. You know, complaints make projects grow (or fail) as much as compliments do. Both are useful, or needed. By the way I'm happy to read that you know what FIC is at. I don't. Indeed there's something going on in the backstage and we are intentionally keep out of it. I'm not saying that FIC hasn't the right to do so, they are a commercial company so their first targets must be market and sales. But this policy is going to impact the software part of it, which is meant to be open and to which we'd like to contribute to. Some months ago Sean suggested a few more fancy Openmoko-based devices. Well, fine, but how will this affect the evolution of the OpenMoko software stack? Are we really likely to make sensible suggestions (or sensible discussions) if we don't know the big picture? Sean is promising more focus and resources, but on which targets? That are the problems. I'm really looking forward to the next month and the coming back of the Openmoko leader. Until then, we're just a bunch of friends fancying around a wannabe phone. Br Michele ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
