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: 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: 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: 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: 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: [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: [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 != 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 != 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: 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: @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: 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: 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
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: 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: 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! snip 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: 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: 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
