Re: Tinymail on it?
On Fri, 2007-02-02 at 05:12 +, Jon Phillips wrote: On Thu, 2007-02-01 at 01:56 +0100, Philip Van Hoof wrote: I already asked it to some internal E-mail address, the reaction back then was positive but no real certainties. Is there interest from the OpenMoko team for bringing tinymail to the device? (http://tinymail.org) I've been reading the discussions about push e-mail, and that idea is all nice and stuff. But you'll still need an actual client to display the e-mails themselves. Philip, this would be great. You should hop over toe the openmoko-devel mailing list to discuss more. There is discussion about an integrating messaging app. Tinymail is great, uses evolution data server, and could hopefully be adapted to the openmoko platform. It looks like that mailing list is an invite-only one, or else isn't the mailman on the server working correctly (I haven't yet received a confirmation E-mail). I'd be happy to join that mailing list and discuss the technical pieces of messaging with you guys. Especially when it comes to RFC822 messages (E-mails, MIME parts, etc etc) ... Yes, this would be amazingly stellar for mobile apps. It appears that messaging is a big missing piece right now, so tinymail with some extensions would be an amazing opportunity in the messaging arena. What is the current extensibility of tinymail? How could we go about adding SMS support to tinymail to treat it like a first class piece of mail? ... and of course also non-RFC822 messages and services that deliver such messages to the software on the device. Although we will have to check how we can blend-in such messages into the current API. It might mean that I will have to make the current API more flexible, maybe this can be solved internally within the implementations of that API, etcetera ... ? But I would be very happy to discuss this indeed. And I'm certainly willing to actively change things in order to support SMS and MMS type of messages. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Tinymail on it?
On Sun, 2007-02-04 at 12:44 +0100, Philip Van Hoof wrote: It looks like that mailing list is an invite-only one, or else isn't the mailman on the server working correctly (I haven't yet received a confirmation E-mail). Nevermind, I received it. It should work now :) -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: mail and contacts app
On Fri, 2007-02-02 at 16:30 -0800, Jon Phillips wrote: On Fri, 2007-02-02 at 17:21 -0700, Richi Plana wrote: The thread started here: http://lists.openmoko.org/pipermail/openmoko-devel/2007-January/73.html Does that make it three versions of EDS we're talking about (the Novell original, Philip van Hoof's and EEDS)? Or is Phillip's and EEDS the same? No, actually, that is the version that these systems use. So, if that is the case, then we have one unified one :) Tinymail does not really use any of the 'other' components of eds. The only component that it uses, in a very modified form, is the camel component. Although camel is part of eds, it's not really integrated or used by the other eds components. In fact it's surprisingly disconnected from any other such eds component (and could have been done as a separate library too). The tinymail project took that LGPL component ... made a series of changes to it. These changes are slowly going to become available in the upstream version. And even more slowly into the eds-dbus version (as the maintainers of eds-dbus told me that they are planning to in phases bring upstream-only to eds-dbus. Not to mix multiple versions of multiple components into their distribution). The problem with this is that the camel changes that I did for tinymail are very much targeted at mobile devices. Upstream Evolution is very unlikely to accept all of them. So some of them will never reach upstream. Therefore wont they reach eds-dbus either (as the eds-dbus team is only interested in the upstream eds). The funny part is indeed that both eds-dbus and the camel of tinymail are targeted at mobile users. But it's the redirection that the camel of tinymail has to take, that is going to make it nearly impossible to get all changes into eds-dbus. The exact same style of changes have happened to eds-dbus. But those changes of course didn't have to take that route. Note that I *did* actively contact them about this and that I *did* tell them that we should better cooperate and work on a single version. They *did*, however, told me that they are only interested in upstream eds. Which is perfectly understandable (so I said it, don't get angry with me dear eds-dbus team: I do understand) and fine for me. . And which is why tinymail is using its own internally build Camel and not the one in eds-dbus, indeed. I really like to get things done, you know. Now, I didn't make these changes for zero reasons. In fact does tinymail need all of the changes that have happened. That's because I have been very conservative in making changes to the camel. So only if really really needed, did I make them. So all changes naturally are really needed. A list of the changes: o. Offline POP3 support o. Summary support for POP3 using TOP o. CONDSTORE support o. BINARY support o. Bandwidth reductions when retrieving the summary from IMAP o. Really major memory consumption reductions when dealing with summaries o. Extremely major memory consumption reductions when downloading summary from IMAP servers o. A major memory consumption reduction when downloading a message from an IMAP server (streaming it directly from the TCP/IP stream to the filesystem, rather than first copying it) o. Support for partial retrieval (only the message, not the attachments) for IMAP o. Support for partial retrieval (only the message, not the attachments) for POP o. Multiple bugfixes (major ones) o. Removing all compilation warnings and also some real bugs caused by not looking at them (using variables uninitialised, which happened quite often in Camel) In *near* future will much more such changes happen. For example IDLE support in the IMAP provider of Camel and changes to all the subsystems of Camel that are needed in order to support this. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
Joe Pfeiffer wrote: Gabriel Ambuehl writes: On Saturday 03 February 2007 18:50:02 Joe Pfeiffer wrote: Which is utterly sad, given I'm such a big fan of Blinkenlights... Trying to make sure we get a couple of multicolor LEDs in v2 ;) Much as I love flashing lights (there's just something *wrong* when my ethernet hub looks more like a computer than my computers do!), I'd much rather get more hardware buttons. Wiring application launching to the buttons on my Palm is really, really nice. You want illuminated buttons. Think about it. We have a winner! We really want buttons with changable logos - http://www.artlebedev.com/everything/optimus/ However, the only sort-of-practical way to do this is to use one internal 50*10mm or so OLED display, with 4-8 hardware buttons on top of it, which are transparent, and designed to relay the underlying display. Unfortunately - this will take up a _relatively_ large volume in the phone. I'd guess 8mm*55*13 - and a little more as the display is flat and the phone is not. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 video (was Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?)
Since you're going to have to reencode your videos for OpenMoko anyway, they could easily be prerotated in the process. That's what we were doing on the Tapwave Zodiac until the amazing people from CoreCodec worked their magic. On 2/4/07, Ian Stirling [EMAIL PROTECTED] wrote: Mikko Rauhala wrote: la, 2007-02-03 kello 14:47 +0100, Harald Welte kirjoitti: Also, the 770 has a landscape display. We have a portrait display. The S3C2410 cannot rotate the image, so you would have to rotate every frame in software, too! Modifying a player to render the image to be rotated in the first place shouldn't be hard, though perhaps any straightforward way to do that would degrade cache behaviour? (A wild guess.) Also, as re-encoding files spesifically for the Neo would be quite ok with me, rotating at that point would be quite a workable solution also. (I'll add that I don't necessarily expect the Neo1973 to play back decent video and won't blame FIC if it doesn't, but I'll sure _try_ it ;) The comparison I'm using internally - Pentium 100, just about will manage that. I do expect to need to pick codecs very carefully - there won't be much spare. Rotating internally may be the straw that breaks the camels back. OTOH - going down to 12fps isn't _that_ visible on this size of screen, and that helps a fair bit - as does reducing the sound bandwidth, or going mono. _simple_ audio codecs - such as NICAM 728 equivalent - which is 10 bit, stereo companded from 14 bits, at 32Khz - may even be appropriate in some cases - to reduce the load on the CPU, and trade off for bandwidth. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: graphics hardware; OpenVG
On 2/4/07, Shawn Rutledge [EMAIL PROTECTED] wrote: What kind of framebuffer architecture is the Neo going to use? Is there graphics acceleration of any kind? Or is the processor's own framebuffer hardware being used directly? It uses the S3C2410's integrated LCD controller with the framebuffer in main memory. It supports a framebuffer bigger than the display resolution, so you get scrolling or double buffering support, but no hardware accelerated drawing. regards Philipp ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Handy application ideas
On Saturday 03 February 2007 22:34:10 Tomasz Zielinski wrote: 2007/2/2, kkr [EMAIL PROTECTED]: ...Because, I presume that the thief will do very quickly a hard reset. There is no such thing like restore to factory default in Neo1973. What you load to flash memory, will remain there. That's why restore to factory default will likely mean: reflash the firmware. Now your average cell phone thief will probably not manage that right away. Maybe a feature could be added that before reflashing (for which there is legitimate use on an OSS phone), the phone tries everything to contact its owner with GPS coordinates? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Thoughts about Bluetooth equipement - does somebody knows a Bluetooth camera?
Salve! Some thoughts about Bluetooth equipment: -Keyboard -Mouse -Headset -Carkit -PC/Laptop/Router with Bluetooth -printer -soundgateway(?) -embedded devices with Bluetooth -other bluetooth mobiles to do converence calls or when the Neo1973 v1 hasn't GPRS class A - to use GRPS while phoning *g* So what more? Are there digital cameras with Bluetooth on the market? Does some of them allows to send pictures directly via Bluetooth when pressing the release? Any inexpensive one there? Which devices did you also know with bluetooth? - barcode scanner? - sensor like thermomether - medical sensor systems, e.g. for live controling of the heartbeat. Link ideas for our wiki? http://tuxmobil.org/bluetooth_linux.html http://tuxmobil.org/bluetooth_cell_apps.html Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Thoughts about Bluetooth equipement - does somebody knows a Bluetooth camera?
Salve! It seems that http://www.bluetooth.com/ has a good overview - we could pick devices from their when they are supported with Linux. Somethink like linux-usb.org would be nice. Robert Michel schrieb am Sonntag, den 04. Februar 2007 um 15:34h: So what more? Are there digital cameras with Bluetooth on the market? Does some of them allows to send pictures directly via Bluetooth when pressing the release? Any inexpensive one there? To be more focused/precice - do you know personal a camera like that? What's your experiances with it? Greetings, from a sunny Aachen, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
enviroment friendly development for v2?
Salve! I don't know how much enviroment friendly development was criteria for the v1 - but this point would be nice to consider - at last for v2: http://www.greenpeace.org/international/campaigns/toxics/electronics/copy-of-how-the-companies-line OpenMoko will enable the user to use the phone much longer and to add the software that he wants/needs instead of the need to buy a new phone because of a new protocoll e.g. Wap. This is already a big step for beeing an environment friendly product. Don't get me wrong, I don't ask for making all better from the beginning - but on the longterm, it would be nice to promote OpenMoko/Neo1973 also with ecological criterias. Like: Beeing greener then the Greenphone ;) Supporting small companies to repair e.g. display demanges with different display types and a non-propritary battery format would help that the live-time of a Neo would be longer than the 12-24 month crap with included engineered end of live shortly after warannty. No keyboard is a good design to be able to use it for a longer time :) So avoiding using high toxical chemicals for the production it the one aspect - having a lower resources consumption with a longer livetime another. Green greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
Ian Stirling writes: We really want buttons with changable logos - http://www.artlebedev.com/everything/optimus/ However, the only sort-of-practical way to do this is to use one internal 50*10mm or so OLED display, with 4-8 hardware buttons on top of it, which are transparent, and designed to relay the underlying display. Unfortunately - this will take up a _relatively_ large volume in the phone. I'd guess 8mm*55*13 - and a little more as the display is flat and the phone is not. Yeah. Changeable logos on the buttons would be ideal, but just illuminating them with a fixed icon would be practical and extremely useful. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Cellular usage
I hope I am posting this properly. I was thinking about my infrequent airline trips and their dislike of cell phones. Is there any possibility to turn off the transmitter in software? Kyle ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
Joe Pfeiffer wrote: Ian Stirling writes: We really want buttons with changable logos - http://www.artlebedev.com/everything/optimus/ However, the only sort-of-practical way to do this is to use one internal 50*10mm or so OLED display, with 4-8 hardware buttons on top of it, which are transparent, and designed to relay the underlying display. Unfortunately - this will take up a _relatively_ large volume in the phone. I'd guess 8mm*55*13 - and a little more as the display is flat and the phone is not. Yeah. Changeable logos on the buttons would be ideal, but just illuminating them with a fixed icon would be practical and extremely useful. With cunning icons, and a RGB LED you might even get three icons per LED. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Airplain mode Re: Cellular usage
Salve Kyle! Wellcome to the openmoko community mailinglist ;) On Sun, 04 Feb 2007, Kyle wrote: I hope I am posting this properly. I was thinking about my infrequent airline trips and their dislike of cell phones. Is there any possibility to turn off the transmitter in software? Yes the hardware will allows to turn off the GSM transmitter. Inside the Neo1973 will be a GSM chip from TI. The System on a chip (SoC) will communicate with this chip with at commands via a serial connection. One of this at commands (you maybe knows them from using modems) will switch off and on the GSM transmitter. To find more about airplain mode discussion we already had on this list use our listarchive and/or google airpain mode site:openmoko.org http://www.google.de/search?q=airplain+mode+site%3Aopenmoko.org One of our ideas was to use GPS to switch the device on again - or to remind the user to do so. So your welcome to share your ideas, wishes and questions here - maybe you will find some inspiring ideas in our list archive: http://lists.openmoko.org/pipermail/community/ Last official announcement from the teamleader Sean Moss-Pultz: http://lists.openmoko.org/pipermail/announce/ - http://lists.openmoko.org/pipermail/announce/2007-January/00.html Hope my mail helps you, Greetings rob (just a student, active on this list) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
On Sun, 4 Feb 2007, Ian Stirling wrote: [EMAIL PROTECTED] wrote: On Sat, 3 Feb 2007, Michael 'Mickey' Lauer wrote: Harald Welte wrote: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) This is true, no LED. Which is utterly sad, given I'm such a big fan of Blinkenlights... You want a phone that looks like the front panel of an Imsai 8080, right? Old Skool baby! http://www.dbit.com/~greeng3/pdp1/PDP1.10.jpg Hehe. That's the background image I want for my Neo. Speaking of which, once we're done with the functionality of all our great ideas, no reason not to have different skins, right? I mean the dialer application could use the traditional pushbuttons, or a retro round dial, or even a plug-and-jack switchboard interface (touch the headset, touch the appropriate jack, a wire appears and makes the connection...) http://groups.google.co.uk/group/sci.electronics.design/browse_thread/thread/52e1c0873fc9c79b/84aa18f138b3c438?lnk=stq=pdp-1+business+cardrnum=5hl=en#84aa18f138b3c438 Yikes! An Imsai with USB ports??!?!?!?!?! ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Tinymail on it?
On Sun, 2007-02-04 at 12:44 +0100, Philip Van Hoof wrote: On Fri, 2007-02-02 at 05:12 +, Jon Phillips wrote: On Thu, 2007-02-01 at 01:56 +0100, Philip Van Hoof wrote: I already asked it to some internal E-mail address, the reaction back then was positive but no real certainties. Is there interest from the OpenMoko team for bringing tinymail to the device? (http://tinymail.org) I've been reading the discussions about push e-mail, and that idea is all nice and stuff. But you'll still need an actual client to display the e-mails themselves. Philip, this would be great. You should hop over toe the openmoko-devel mailing list to discuss more. There is discussion about an integrating messaging app. Tinymail is great, uses evolution data server, and could hopefully be adapted to the openmoko platform. It looks like that mailing list is an invite-only one, or else isn't the mailman on the server working correctly (I haven't yet received a confirmation E-mail). I'd be happy to join that mailing list and discuss the technical pieces of messaging with you guys. Especially when it comes to RFC822 messages (E-mails, MIME parts, etc etc) ... Yes, this would be amazingly stellar for mobile apps. It appears that messaging is a big missing piece right now, so tinymail with some extensions would be an amazing opportunity in the messaging arena. What is the current extensibility of tinymail? How could we go about adding SMS support to tinymail to treat it like a first class piece of mail? ... and of course also non-RFC822 messages and services that deliver such messages to the software on the device. Although we will have to check how we can blend-in such messages into the current API. It might mean that I will have to make the current API more flexible, maybe this can be solved internally within the implementations of that API, etcetera ... ? But I would be very happy to discuss this indeed. And I'm certainly willing to actively change things in order to support SMS and MMS type of messages. Oh, this is great news indeed. I installed the Contacts and Dates apps from openhanded with no troubles, but when I tried to install Tinymail, I need the customized libraries. Are there instructions for how to do a build, where to find the updated libraries, and without breaking my old system's libraries ;) Current OpenMoko developers, could you comment on the state of messaging on OpenMoko and if this is a good direction to go on merging these message types behind this soon-to-become handheld standard mail app? :) The tinymail, dates and contacts applications are awesome, well supported by opened hand, nokia/maemo and others. Thus, it seems logical to jump on the bandwagon to gain group benefits and to have an upstream source for email... 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 https://lists.openmoko.org/mailman/listinfo/community
RE: OpenMoko at Oreilly Emerging Telephony Conference
On Sat, 2007-02-03 at 22:37 -0800, David Schlesinger wrote: Same here. Wait, Sean, you are in the bay area right now? Yah, maybe we should get together once the device is launched ... Also, I'm putting on the Creative Commons Salon on FEB 21 at shinesf.com, which is a good place to meet regardless: http://upcoming.org/event/137741/ Jon -Original Message- From: [EMAIL PROTECTED] on behalf of Sean Moss-Pultz Sent: Sat 2/3/2007 9:53 PM To: Jon Phillips Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Re: OpenMoko at Oreilly Emerging Telephony Conference On Sat, 2007-02-03 at 16:45 -0800, Jon Phillips wrote: GREAT idea. Whether or not we are attending the conference, enough of us live in the area that we should get together, if not at the conference then in a suitably friendly bar or restaurant. Perhaps we should find out when Sean is available, and see if we can work around that? Michael Yah, that sounds goodSean, what do you think? Sounds like a great idea. Can you organize something? I seem to be free just about any night now. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community -- 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 https://lists.openmoko.org/mailman/listinfo/community
Re: mail and contacts app
On Sun, 2007-02-04 at 13:16 +0100, Philip Van Hoof wrote: On Fri, 2007-02-02 at 16:30 -0800, Jon Phillips wrote: On Fri, 2007-02-02 at 17:21 -0700, Richi Plana wrote: The thread started here: http://lists.openmoko.org/pipermail/openmoko-devel/2007-January/73.html Does that make it three versions of EDS we're talking about (the Novell original, Philip van Hoof's and EEDS)? Or is Phillip's and EEDS the same? No, actually, that is the version that these systems use. So, if that is the case, then we have one unified one :) Tinymail does not really use any of the 'other' components of eds. The only component that it uses, in a very modified form, is the camel component. Although camel is part of eds, it's not really integrated or used by the other eds components. In fact it's surprisingly disconnected from any other such eds component (and could have been done as a separate library too). The tinymail project took that LGPL component ... made a series of changes to it. These changes are slowly going to become available in the upstream version. And even more slowly into the eds-dbus version (as the maintainers of eds-dbus told me that they are planning to in phases bring upstream-only to eds-dbus. Not to mix multiple versions of multiple components into their distribution). The problem with this is that the camel changes that I did for tinymail are very much targeted at mobile devices. Upstream Evolution is very unlikely to accept all of them. So some of them will never reach upstream. Therefore wont they reach eds-dbus either (as the eds-dbus team is only interested in the upstream eds). The funny part is indeed that both eds-dbus and the camel of tinymail are targeted at mobile users. But it's the redirection that the camel of tinymail has to take, that is going to make it nearly impossible to get all changes into eds-dbus. The exact same style of changes have happened to eds-dbus. But those changes of course didn't have to take that route. Do these changes seem to speed up your app and possibly could speed up Evolution in general? I'm having great fun with these apps because of their speed (almost to the point of where I want to use them full-time rather than crashy evolution!!!) Note that I *did* actively contact them about this and that I *did* tell them that we should better cooperate and work on a single version. They *did*, however, told me that they are only interested in upstream eds. Is EDS mostly controlled by Novell? Yes, seems like a big wall to jump to get changes in...like OO.o or something... Which is perfectly understandable (so I said it, don't get angry with me dear eds-dbus team: I do understand) and fine for me. . And which is why tinymail is using its own internally build Camel and not the one in eds-dbus, indeed. I really like to get things done, you know. That is cool and good to know (even though you are prolly sick of having to repeat this all the time ;) Now, I didn't make these changes for zero reasons. In fact does tinymail need all of the changes that have happened. That's because I have been very conservative in making changes to the camel. So only if really really needed, did I make them. So all changes naturally are really needed. A list of the changes: o. Offline POP3 support o. Summary support for POP3 using TOP o. CONDSTORE support o. BINARY support o. Bandwidth reductions when retrieving the summary from IMAP o. Really major memory consumption reductions when dealing with summaries o. Extremely major memory consumption reductions when downloading summary from IMAP servers o. A major memory consumption reduction when downloading a message from an IMAP server (streaming it directly from the TCP/IP stream to the filesystem, rather than first copying it) o. Support for partial retrieval (only the message, not the attachments) for IMAP o. Support for partial retrieval (only the message, not the attachments) for POP o. Multiple bugfixes (major ones) o. Removing all compilation warnings and also some real bugs caused by not looking at them (using variables uninitialised, which happened quite often in Camel) In *near* future will much more such changes happen. For example IDLE support in the IMAP provider of Camel and changes to all the subsystems of Camel that are needed in order to support this. Man, I want to run with these changes when using Evolution...this is great! Jon -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org
Re: Q: How does USB hubs work? Re: Multiple USB Devices
On Sat, Feb 03, 2007 at 09:15:54AM -0700, Joe Pfeiffer wrote: Harald Welte writes: My understanding is that it will be USB On-The-Go, No. OTG is a complex specification, and it comprises way more than just a AB socket, but also electrical and software components which we cannot provide using the S3C2410. Thanks for the correction. This is interesting do I understand you to mean that the NEO can behave as either a host or as a device depending on how it's plugged in, without support OTG? Yes. OTG is one specific, quite complicated (on multiple layers) approach to automatically do the right thing, if you have compliant devices. We're basically able to electrically switch the usb socket from host to device and vice-versa, 1) manually (by software) 2) automatically in OTG-similar way based on 5th pin of mini-B jack. but we cannot do all the higher layers (such as negotiating with another device who will be host and who will be device, etc.) -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: graphics hardware; OpenVG
On Sun, 2007-02-04 at 00:48 -0700, Shawn Rutledge wrote: What kind of framebuffer architecture is the Neo going to use? Is there graphics acceleration of any kind? Or is the processor's own framebuffer hardware being used directly? I've been doing some framebuffer graphics on the Zaurus SL-6000; it has a TC6393 chip, which is relatively primitive but at least it can draw lines and filled rectangles without having to set every pixel one by one. I just discovered this open standard for vector graphics acceleration on mobile devices, called OpenVG: http://www.khronos.org/openvg/ Apparently the idea is to define an API and a test and benchmark suite, so applications (or whole windowing systems) will be portable between devices, but some devices will accelerate more functions than others (and the benchmarks will reveal this). Any plans to implement that on the Neo? Well, you would want to add openvg support lower than X11. You should talk to the X and Cairo developers about this. For the OpenMoko uses, Cairo offers hardware acceleration through Glitz, sand Cairo has been in GTK since 2.8... 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 https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
2007/2/4, Robert Michel [EMAIL PROTECTED]: Don't get me wrong, I don't ask for making all better from the beginning - but on the longterm, it would be nice to promote OpenMoko/Neo1973 also with ecological criterias. Average OpenMoko user takes a bath once a week. iPhone user takes a shower twice a day! Buy Neo1974, save the Earth! :-] No keyboard is a good design to be able to use it for a longer time :) You can still use phones made in 60's, are you sure touchscreen will survive 40 years too? ;-) -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
Salve Tomasz! On Sun, 04 Feb 2007, Tomasz Zielinski wrote: 2007/2/4, Robert Michel [EMAIL PROTECTED]: Don't get me wrong, I don't ask for making all better from the beginning - but on the longterm, it would be nice to promote OpenMoko/Neo1973 also with ecological criterias. Average OpenMoko user takes a bath once a week. iPhone user takes a shower twice a day! Buy Neo1974, save the Earth! :-] Wow what a seriously answer. It seems that you haven'd used the link: http://www.greenpeace.org/international/campaigns/toxics/electronics/copy-of-how-the-companies-line Ok, when you are only interested in competing with iPhone - greenpeace is helping to seperate from Apple: http://www.greenpeace.org/raw/content/international/press/reports/greener-electronics-apple-rank-2.pdf No keyboard is a good design to be able to use it for a longer time :) You can still use phones made in 60's, are you sure touchscreen will survive 40 years too? ;-) First I was comparing mobil phones, second, because the touchscreen has no mechanical parts, I think it is possible to produce this touchscreen in a way, that 80% are usable in 40 years. And making the case strong enough to be able to use the mobile outdoor and in the rain would help using the touchscreen in 40 years as well. But you are not seriously it makes a big differance if the devices are usable due crap keys or no softwareupgrade posibilities for 2 years, or if the Neo1973 will be used for 10 years. I was not kidding with a ecologicaly view on mobil phones, we can bring OpenMoko and the Neo1973 into seriously science - influence of OpenSoftware to reduce hardware cycles - it is absolutly unsmart to produce devices only for 1-2 year use. And your kidding replay let me thing that with OpenMoko it would be possibe to go one stepp further - recycling of old smartphones 1. refurbishment and selling them with OpenMoko 2. desodering ICs and recycling of SoCs, GSM ICs, displays and condensors: http://en.wikipedia.org/wiki/Tantalum I don't think there is any other consumer electronic device that is generally replaced every 12 months. http://news.bbc.co.uk/1/hi/sci/tech/6174422.stm Visit Nokia Sustainable products: http://www.nokia.com/A4197011 And I think it is possible to find studies about the ecological footprint of mobil devices like: http://www.mitpressjournals.org/doi/abs/10.1162/108819806775545330 See: http://howgeen.blogspot.com/2006/12/mobile-phone-one-more-enemy-for-earth.html In our mind, the mobile phone's not associated yet with the environmental, social or economic problems that it leads to. However, some figures are scary: nearly 30 kg of raw materials are necessary to manufacturate a device of about 100 grams! And in the world, one estimates that a billion devices are living! [...] http://www.wwf.be/fr/index.cfm?group=newsmenu=factsheets.cfmpage=factsheets/campaign/gsm-environment.cfm PC 764m^2 mobil phone 32m^2 http://www.weeeman.org/html/impact/footprint.html BTW the ieee has an IEEE 802.3 Energy Efficient Ethernet Study Group: http://www.ieee802.org/3/eee_study/ The more I think about ecolgical points with OpenMoko/Neo1973 as more I think it could be a good promoting argument. 1. OpenMoko/Neo1973 give the user the freedom to update and install new software - independent from the hardware producer or network provider. This gives a perspective to use the Neo1973 longer then any other smartphone with a fast changing market - mostly protocolls 2. The ecological footprint of a smart phone is much smaller than that of a PC or laptop - giving full Linux power to the Neo1973 it will reduce the need for a PC/Laptop That could be combined with avoiding toxical chemicals during producing, posibilities to repair devices and recycling ideas So I would not talk about to aim a livetime of 40 years, but what about sinicicant longer livetime (5-10 years) than normal smart phones? Green greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
Robert Michel writes: You can still use phones made in 60's, are you sure touchscreen will survive 40 years too? ;-) First I was comparing mobil phones, second, because the touchscreen has no mechanical parts, I think it is possible to produce this touchscreen in a way, that 80% are usable in 40 years. Resistive touchscreens do have the eqivalent of a mechanical part: the material between the front and back surfaces. When you press, you push it out of the way to make contact. This wears down over time; I actually kept my first Palm Pilot long enough to wear the screen out (and was able to find a replacement screen on ebay, so it kept on going for several more years!) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
All this is good. a) how the company (FIC) is supposed to make a profit by manufacturing less phones? b) let's say my phone will last 10 years . How can I be sure that my cellular provider will use the same technology for many years (with only software upgrades required)? There are companies that create sell refurbished phones to 3rd world countries for cheap, so the situation is not grim enough. Robert Michel wrote: Ok, when you are only interested in competing with iPhone - greenpeace is helping to seperate from Apple: First I was comparing mobil phones, second, because the touchscreen has no mechanical parts, I think it is possible to produce this touchscreen in a way, that 80% are usable in 40 years. The touchscreen has a digitizer, and it's still very unreliable for long-term usage. I wonder if FIC will do it right. So I would not talk about to aim a livetime of 40 years, but what about sinicicant longer livetime (5-10 years) than normal smart phones? Green greetings, rob -- With best regards, Oleg. *OLS Software* Websites Building, PHP Development. Tel./Fax 03-613-2865 , mobile: 054-424-0865 URL http://www.ols.co.il ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
Salve Joe! On Sun, 04 Feb 2007, Joe Pfeiffer wrote: Robert Michel writes: You can still use phones made in 60's, are you sure touchscreen will survive 40 years too? ;-) First I was comparing mobil phones, second, because the touchscreen has no mechanical parts, I think it is possible to produce this touchscreen in a way, that 80% are usable in 40 years. Resistive touchscreens do have the eqivalent of a mechanical part: You are right about resistive touchscreens, but will the Neo not have an optical touchscreen? Or is the v1/v2 without multitouch? Greetings rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Wiki pdf / images
Hi, I am trying to add a pdf and some images to an openmoko wiki page http://www.linuxtogo.org/gowiki/OpenMoko/AtFOSDEM , but the 'attach file' option in 'More actions' is grayed out. Can attaching files be allowed, or am I doing something wrong? Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Tinymail on it?
On Sun, 2007-02-04 at 11:06 -0800, Jon Phillips wrote: Oh, this is great news indeed. I installed the Contacts and Dates apps from openhanded with no troubles, but when I tried to install Tinymail, I need the customized libraries. Are there instructions for how to do a build, where to find the updated libraries, and without breaking my old system's libraries ;) No, you don't need to compile nor patch any customised libraries. All such customisations have been done within tinymail's code. This means that the only source code you need, is the one in the repository of tinymail. In other words, the modified camel-lite is part of the tinymail code as-is. The code also will not clash, in any way, with existing libraries or installations. That's because binary and directory-path names have been changed to be appended with the -lite suffix. Even the .pc files, used by autotools, have been renamed that way. Current OpenMoko developers, could you comment on the state of messaging on OpenMoko and if this is a good direction to go on merging these message types behind this soon-to-become handheld standard mail app? :) The tinymail, dates and contacts applications are awesome, well supported by opened hand, nokia/maemo and others. Thus, it seems logical to jump on the bandwagon to gain group benefits and to have an upstream source for email... On the subject of ... support, Please make sure not to make the misconception that Nokia is behind tinymail as the leading force or playing a leading role for the project. Although it's true that Nokia is helping or sponsoring various development efforts and features of tinymail, it's not-so that Nokia is doing the project. The tinymail project is a true free software and community project led by me. Various people have done feature development on behalf of Nokia for tinymail, including me, but the initial start of the project had very few to do with Nokia. The current engine behind tinymail also isn't Nokia but rather .. simply .. me and my believe in it :-) While I agree that their interest in the project adds quite a lot fuel to that engine, it wouldn't be correct if one would start thinking that tinymail is a Nokia-only-something. That is absolutely not the case. It is the case that Nokia are the earliest adaptors and the first mobile device vendor to be interested in the project. And that they have been financing the development of very interesting features. That they contacted me at Guadec. Etc etc etc. But nothing would stop me from accepting contract working for other such vendors. Nor would anything stop me from taking different directions for the project. Except of course that a few API promises based on release numbers. Promises that make sense for any library. But I do want to be very clear, I even want to stress it and I want to put a big emphasis on ... that tinymail is not for only Nokia. Oh, and underline that too. Mark it. Make it bold. Capitalise it. In fact would I be very interested in other such markets and other such vendors. And not only me, as I'm building a network of competence around the project. With members like, X-Tend Freebility, Collabora, Kernel Concepts and Igalia. And I hope more like them soon. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
Salve Oleg! Oleg L. Sverdlov schrieb am Sonntag, den 04. Februar 2007 um 23:36h: All this is good. a) how the company (FIC) is supposed to make a profit by manufacturing less phones? Who is saying that FIC should produce less phones ;) When FIC is producing phones which are usable 2-5 longer than the other phones on the market, than this is a good argument to choce a phone from FIC. Don't forget that FIC steps new into a quite closed market. b) let's say my phone will last 10 years . How can I be sure that my cellular provider will use the same technology for many years (with only software upgrades required)? You cant upgrade to UMTS, but for phoning with GSM it should be good enough. When the GSM chip would be on a small module, even network technologie would be upgradable. There are companies that create sell refurbished phones to 3rd world countries for cheap, so the situation is not grim enough. AFAIK less then 2% of the mobils are going to recycled. My 12 years old hp48 calculator is still very usefull, so I don't find any reason (from the consumer view) why a live cycle of a smartphone couldn't be 10 years as well. Not the hardware was the limiting factor on the phones of the last years - the software was it. Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: enviroment friendly development for v2?
Robert Michel writes: On Sun, 04 Feb 2007, Joe Pfeiffer wrote: Robert Michel writes: You can still use phones made in 60's, are you sure touchscreen will survive 40 years too? ;-) First I was comparing mobil phones, second, because the touchscreen has no mechanical parts, I think it is possible to produce this touchscreen in a way, that 80% are usable in 40 years. Resistive touchscreens do have the eqivalent of a mechanical part: You are right about resistive touchscreens, but will the Neo not have an optical touchscreen? Or is the v1/v2 without multitouch? I thought I saw an earlier post on this list confirming that V1 will use a resistive, single-touch-only screen. The wiki confirms that it's single-touch (but doesn't describe the technology). Near as I can tell, there's been *no* information from FIC on the V2; everything about it has been speculation. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: mail and contacts app
On Sun, 2007-02-04 at 11:24 -0800, Jon Phillips wrote: Do these changes seem to speed up your app and possibly could speed up Evolution in general? I'm having great fun with these apps because of their speed (almost to the point of where I want to use them full-time rather than crashy evolution!!!) Speed is a little bit abstract here. Some of the patches speed up in pure raw performance. Others will speed things up because less bytes are being transmitted between you and the IMAP server. Most reduce memory consumption. Which often means that they actually cause things to be less performing. In general will the changes mean that they will speed up things on mobile devices. And that the changes make things possible on mobile devices, whereas they used to be more or less impossible caused by aggressive memory consumption (allocations of more than 60MB ram). Note that I *did* actively contact them about this and that I *did* tell them that we should better cooperate and work on a single version. They *did*, however, told me that they are only interested in upstream eds. Is EDS mostly controlled by Novell? Yes, seems like a big wall to jump to get changes in...like OO.o or something... Yes A list of the changes: o. Offline POP3 support o. Summary support for POP3 using TOP o. CONDSTORE support o. BINARY support o. Bandwidth reductions when retrieving the summary from IMAP o. Really major memory consumption reductions when dealing with summaries o. Extremely major memory consumption reductions when downloading summary from IMAP servers o. A major memory consumption reduction when downloading a message from an IMAP server (streaming it directly from the TCP/IP stream to the filesystem, rather than first copying it) o. Support for partial retrieval (only the message, not the attachments) for IMAP o. Support for partial retrieval (only the message, not the attachments) for POP o. Multiple bugfixes (major ones) o. Removing all compilation warnings and also some real bugs caused by not looking at them (using variables uninitialised, which happened quite often in Camel) In *near* future will much more such changes happen. For example IDLE support in the IMAP provider of Camel and changes to all the subsystems of Camel that are needed in order to support this. Man, I want to run with these changes when using Evolution...this is great! You can of course help me with getting them upstream. Get in touch if that is what you want to work on. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Tinymail on it?
On Fri, 2007-02-02 at 05:12 +, Jon Phillips wrote: I very recently started playing a little bit with the SyncML API, and since it's not very difficult to get something basic working I might implement some support for this sooner or later too. Yes, this would be amazingly stellar for mobile apps. It appears that messaging is a big missing piece right now, so tinymail with some extensions would be an amazing opportunity in the messaging arena. While I don't see the real cool thing about SynCML (it's just a rather simplistic synchronisation standard, but simplism is actually probably it's most powerful feature), I do see the use for it in tinymail. This will eventually translate into me developing (some) support for SyncML into tinymail. It would certainly mean that I'll actively encourage and support somebody who would develop this for tinymail or for Camel or tinymail's camel-lite (should be the same code then, as the API of camel-lite nor the cache format hasn't really changed that much). What is the current extensibility of tinymail? How could we go about adding SMS support to tinymail to treat it like a first class piece of mail? The only difficulty that I see with SMS and MMS is that the format of those messages isn't RFC822 (E-mails with MIME parts, etc etc). This means implementing a TnyMimePart for SMS and MMS that deals with the format efficiently and correctly. I have never even looked at how those messages look, heck I never use the feature on my phone (actually, I hate it when people send me an SMS. I prefer hearing the voice of the person who's contacting me .. hehe). Oh, another difficulty might be building a summary from the messages. I can imagine that the messages only have a from phone number and that the user wants to see the person's name if the person is in the contact list. Or the subject, the dates, etc etc ... -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 video (was Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?)
su, 2007-02-04 kello 18:28 -0500, Bryce Leo kirjoitti: I'm sorry guys... but instead of flipping the video or worrying about re-coding... how bout a non-techical solution. Rotate the Device You certainly wouldn't catch me wanting to watch a video in portrait modethat would ruin the whole thing. Why would you want to watch a video in portrait mode? We don't. The framebuffer, however, is in portrait orientation. Hence the need to rotate to landscape at some point, be it at play time in the player or the X server (probably rather the former, efficiency-wise), or at recode time to take some work off of the Neo CPU. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 video (was Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?)
On Saturday 03 February 2007 15:47, you wrote: Also, the 770 has a landscape display. We have a portrait display. The S3C2410 cannot rotate the image, so you would have to rotate every frame in software, too! That's a good point. Anyway, rotation can be combined with scaling or color format conversion and done in a single pass, so overhead should not be too big. One more solution is rotation at video transcode stage as Mikko suggested. Just for some experiment, I compiled mplayer for arm920t (not using armv5te instructions), and benchmarked it with sdl video output (software YUV-RGB conversion, generic nonoptimized scaling 320x240 = 640x480) and libmad mp3 audio decoder. Please note that the LCM we use in the Neo1973 can do hardware scaling, e.g. theoretically you can software-reconfigure the LCM to behave as QVGA 240x320, and then change the s3c2410_fb kernel driver timings accordingly. If I understand that correctly, it is not arbitrary scaling but support for 240x320 resolution? But as we should first aim at transcoded video support anyway, that would provide some performance improvement. This has not been tested or implemented by us, since we're mainly interested in getting a high-res phone UI working right now :) I clearly understand that :) I guess it is one of the reasons, why you announced early access to the device for open source developers. I hope that some of them would try implementing some video support. However, if somebody skilled wants to write, integrate and test code for this, I'm happy the help. We cannot disclose the LCM data sheet, but I can add the software sequence for 240x320 / 480x640 switching to the [GPL licensed] kernel LCM driver at least after phase-1 (March 11). The S3C2410 user manual is publicly available from Samsung Semiconductors, so basically it's up to whoever is interested to implement it. One interesting question is how to merge this into X11/Kdrive... As far as I understand, only the very latest big (non-kdrive) X11 has randr capabilities for dynamically adding/removing viewports and changing resolutions. [But did I mention that Keith Packard gets a phase-0 phone? *g*] As it seems to be not quite trivial to do, this part of work can wait a bit until some initial video benchmarks are available (centered nonscaled 320x240 video playback vs. software scaled to fullscreen). About integration with x11/kdrive. Nokia 770 also uses kdrive, and implements some extensions to access extra features (pixel doubling). Unfortunately it does not provide access to hardware YUV colorspace (libxv exists, but it is just a stub and does nothing). So right not mplayer on Nokia 770 uses some kind of hack and accesses framebuffer concurrently with x11 server. Synchronization is not perfect, so it is possible to get garbage on the screen when you switch between different applications a lot while mplayer video playback is active. A more clean solution would be to patch xserver to interact with mplayer better to synchronize framebuffer access (kdrive on Nokia 770 already has some patches to synchronize with DSP video decoder used by built-in video player). Maybe I'll try this later. I'm just interested in improving video support for ARM based devices, that's why I posted to this openmoko mailing list . I'm currently trying to integrate a fast scaler for ARM into ffmpeg library (the engine used by mplayer, vlc and the other video players for linux ): http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-January/051209.html So now I'm trying to collect information about what scaling/color conversion functionality would be useful for various devices. Looks like Neo 1973 may need rgb565 = rgb565 scaler, image rotation support and probably yv12 = rgb565 (grayscale). I don't have much free time, so support for just Nokia internet tablets has the highest priority for me. But if anybody else would like to work on the features needed for Neo 1973 video support, I would be glad to help. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: graphics hardware; OpenVG
On 2/4/07, Jon Phillips [EMAIL PROTECTED] wrote: Well, you would want to add openvg support lower than X11. You should talk to the X and Cairo developers about this. Well I wondered how a standard like that can improve application portability. QT, X, and OpenGL (and GTK) are all somewhat portable themselves, and applications are usually written on top of those layers. The first three can run directly on hardware (or maybe GTK can too nowadays?) But when you choose one of those you limit the applications that can run on the device to those that were written against that API. By introducing a new standard, it means that if applications are to use that new standard directly, they have to be re-written; and if not, then the new standard is just another layer of indirection between one of those existing systems and the hardware. At least it defines which kinds of acceleration are the most important and helps to quantify the results. I do think that having accelerated drawing hardware for more types of primitives than just line segments would be a good improvement (elliptical arcs and Bezier curves are important for many kinds of graphics; and there is a second-order curve that is important for TrueType, right?) But there were existing attempts like GGI to make accelerated drawing available at a lower level. For the OpenMoko uses, Cairo offers hardware acceleration through Glitz, sand Cairo has been in GTK since 2.8... But how soon do you think we will see portable Linux devices that provide acceleration for most of OpenGL? I have a suspicion that Apple already had to do that, to be able to get that glitzy UI to work well enough, just like desktop OS X will not run very well without a good graphics card. And there are some chips available. I think I read something about an Intel-designed companion graphics chip for the PXA270. And Nvidia has something too. I wonder what the power budget is for those. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Tuning fork, (was: music applications: piano, drum, bell...)
On 31-01-07 03:39, kkr wrote in part: [...] we would be able to built a music application like a piano (or synthesizer). Sound would be different according to the force exercised by the finger (Like a true one, or, at least, a more realistic). And of course, to be able of playing several notes simultaneously (Do+Re +Mi) And what about an electronic tuner for my guitar? Of course with support for alternative tunings. Oh, and while we're at it, I'd also like it to work for my concert zither (http://en.wikipedia.org/wiki/Image:Zither.png). And the piano as well, perhaps? Does something like this exist already? Curious, Marnix ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Itch2: Trivial to use Go game program
Sounds pretty good, maybe add to this kind of programm possibilty to play online with another people, after teaching process. In this case it wil turn even more usable. On 1/25/07, Aloril [EMAIL PROTECTED] wrote: Go program that would allow start playing Go without even reading rules. Animations would 'explain' liberties and solidly connected units of stones by flashing them for a short time after move. Especially combined with touch screen should allow even 2-3 year old children to play Go against computer. Player only need to be able to touch at screen at point (s)he wants to place stone. Phone would then reply and wait for another touch (move). I suspect that eventually player would figure out what is happening without any explanation. Computer opponent would start close to random strength and increase strength gradually as player increases in strength. http://londerings.novalis.org/wlog/index.php?title=Go_Teaching_Program -- Aloril [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
