http://wiki.openmoko.org/api.php?action=feedcontributions&user=Lally&feedformat=atomOpenmoko - User contributions [en]2013-05-24T05:37:17ZUser contributionsMediaWiki 1.19.6http://wiki.openmoko.org/wiki/SolarisSolaris2009-02-01T08:29:15Z<p>Lally: </p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win. (Note: He did, see the Epilogue. You win some, and you lose all the rest.)<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC. --prefix=/usr<br />
|-<br />
| mpfr-2.3.2/ || For GCC --prefix=/usr<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. Modify the bang line in /usr/bin/yum to point to /usr/bin/python2.2<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
<tt>export PATH=/usr/local/bin/:$PATH<br />
<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH</tt><br />
<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]<br />
<br />
= Epilogue =<br />
Well, the last thing I got to was a QT based tool requiring a semaphore implementation. Perhaps someone else can give that a try.<br />
<br />
I went ahead & VirtualBox'd an Ubuntu install and dedicated it to OM. Ugh.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2009-02-01T08:28:27Z<p>Lally: Unconditional Surrender</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC. --prefix=/usr<br />
|-<br />
| mpfr-2.3.2/ || For GCC --prefix=/usr<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. Modify the bang line in /usr/bin/yum to point to /usr/bin/python2.2<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
<tt>export PATH=/usr/local/bin/:$PATH<br />
<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH</tt><br />
<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]<br />
<br />
= Epilogue =<br />
Well, the last thing I got to was a QT based tool requiring a semaphore implementation. Perhaps someone else can give that a try.<br />
<br />
I went ahead & VirtualBox'd an Ubuntu install and dedicated it to OM. Ugh.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-30T20:22:12Z<p>Lally: /* Prerequisite Software */ Changed prefix for install for gmp & mpfr</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC. --prefix=/usr<br />
|-<br />
| mpfr-2.3.2/ || For GCC --prefix=/usr<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. Modify the bang line in /usr/bin/yum to point to /usr/bin/python2.2<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
<tt>export PATH=/usr/local/bin/:$PATH<br />
<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH</tt><br />
<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-28T00:13:48Z<p>Lally: /* Upgraded Python */ Changed yum instructions.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC<br />
|-<br />
| mpfr-2.3.2/ || For GCC<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. Modify the bang line in /usr/bin/yum to point to /usr/bin/python2.2<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
<tt>export PATH=/usr/local/bin/:$PATH<br />
<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH</tt><br />
<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T23:50:36Z<p>Lally: /* The new Bash */ Fixed formatting on .bashrc commands.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC<br />
|-<br />
| mpfr-2.3.2/ || For GCC<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. This will break yum, so you'll have to change it back when you want to run that.<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
<tt>export PATH=/usr/local/bin/:$PATH<br />
<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH</tt><br />
<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T23:48:30Z<p>Lally: /* Prerequisite Software */ Added GCC requirements & some formatting.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC<br />
|-<br />
| mpfr-2.3.2/ || For GCC<br />
|-<br />
| '''gcc-4.3.2/''' || B/c the original GCC supplied didn't understand a specific warning flag.<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| '''Python-2.6/''' || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| '''subversion-1.5.3/''' || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| '''linux-2.6.18/''' || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. This will break yum, so you'll have to change it back when you want to run that.<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T23:46:25Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| gmp-4.2.4/ || For GCC<br />
|-<br />
| mpfr-2.3.2/ || For GCC<br />
|-<br />
| gcc-4.3.2 || B/c the original GCC supplied didn't understand a specific warning flag. <br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. This will break yum, so you'll have to change it back when you want to run that.<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T03:02:54Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers. You don't have to build or even configure this. Just untar and symlink the include/ directory.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. This will break yum, so you'll have to change it back when you want to run that.<br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Host OSes]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T02:28:19Z<p>Lally: /* Hacking up the system to make it work */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
== Linux Kernel ==<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Upgraded Python ==<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here. This will break yum, so you'll have to change it back when you want to run that. <br />
<br />
== The new Bash ==<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
== Runtime Library Setup ==<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T02:15:59Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/ ||<br />
|-<br />
| help2man-1.36.4/ ||<br />
|-<br />
| gettext-0.17/ ||<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here.<br />
<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T02:15:45Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion. Install in /usr/local.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here.<br />
<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-27T00:40:27Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| openssl-0.9.8i/ || for subversion.<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
= Hacking up the system to make it work =<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here.<br />
<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-24T15:52:42Z<p>Lally: A little reorg and some new notes.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
<br />
= Hacking up the system to make it work =<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
In /usr/bin, rename python to old_python, and link /usr/local/bin/python here.<br />
<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-23T05:48:27Z<p>Lally: /* Onto the Point */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Use these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-23T05:40:21Z<p>Lally: /* Prerequisite Software */ Added requirement for linux kernel source.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| linux-2.6.18/ || For the headers<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
Go into /usr/include, and<br />
<br />
<tt>ln -s /usr/local/src/linux-2.6.18/include/linux .</tt><br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T15:54:59Z<p>Lally: /* Prerequisite Software */ Made the packages into a table.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
{| border="1"<br />
! Package<br />
! Comments<br />
|-<br />
| apr-1.3.3/ || for subversion<br />
|-<br />
| apr-util-1.3.4/ || for subversion<br />
|-<br />
| bash-3.2/ || the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
|-<br />
| diffstat-1.46/<br />
|-<br />
| help2man-1.36.4/<br />
|-<br />
| gettext-0.17/<br />
|-<br />
| git-1.6.0.2/ || yum didn't have this.<br />
|-<br />
| ncftp-3.2.2/ || to make CPAN happy about Locale::gettext<br />
|-<br />
| neon-0.28.3/ || for subversion<br />
|-<br />
| Python-2.6/ || for the proper sqlite support. Yeah, the whole thing.<br />
|-<br />
| sqlite-3.6.3/ || for python's sake.<br />
|-<br />
| subversion-1.5.3/ || yum didn't have this.<br />
|-<br />
| texi2html-1.64/ || no package for this either.<br />
|-<br />
| texinfo-4.9/ || default version didn't have makeinfo<br />
|-<br />
| make-3.81/ || seriously<br />
|-<br />
| tar-1.20/ || again, seriously.<br />
|-<br />
|}<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T15:50:09Z<p>Lally: /* Notes */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
# diffstat-1.46/<br />
# help2man-1.36.4/<br />
# gettext-0.17/<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T15:48:01Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect distribution maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
# diffstat-1.46/<br />
# help2man-1.36.4/<br />
# gettext-0.17/<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T15:46:08Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software. After you're done with this, you'll:<br />
<br />
# Respect package maintainers more<br />
# Loathe other software developers more<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ <br />
# gettext-0.17/<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
As early as you can, build gettext and install it. Then setup LD_LIBRARY_PATH, /etc/ld.so.conf, etc. before moving forward with the rest. Otherwise some of the configures will complain about preloadable_libintl.so.<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T13:58:42Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does. [http://www.mail-archive.com/bug-bash@gnu.org/msg02148.html You'll probably need this one-line patch]<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-14T13:53:04Z<p>Lally: /* Notes */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash.<br />
<br />
In both root's and that user's .bashrc, pop in these lines:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH<br />
<br />
So that your new tool versions & shared libs will get picked up properly.<br />
<br />
Also, add /usr/local/lib to /etc/ld.so.conf (in the zone, obviously), and do an ldconfig after installing gettext.<br />
<br />
[[Category:Application Developer]]<br />
[[Category:Host OSes]]<br />
[[Category:In progress]]</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T22:45:30Z<p>Lally: /* Prerequisite Software */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
It's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash. <br />
<br />
In that user's .bashrc, pop in this line:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
<br />
So that your new tool versions will get picked up properly.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T22:44:51Z<p>Lally: </p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
== Prerequisite Software ==<br />
<br />
<br />
<br />
Create a user (or the build system will complain that you're "root"). Create /home, and then create the user. Let's call him 'moko'.<br />
<br />
Before doing the su - moko, it's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
# make-3.81/ -- seriously<br />
# tar-1.20/ -- again, seriously.<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
<br />
When they're installed, they'll go in the default prefix setting, namely /usr/local/bin. Put /usr/local/bin in as the first entry in your path.<br />
<br />
<br />
== Notes ==<br />
<br />
The build system will complain if you attempt to run it as root, even if it's the bullshit root in a container (it can't tell the difference). Create /home, and then create a user (say "moko") to run the build system. Also, edit /etc/shells and add /usr/local/bin/bash to the list. Finally, edit /etc/passwd and change moko's shell to /usr/local/bin/bash. <br />
<br />
In that user's .bashrc, pop in this line:<br />
<br />
export PATH=/usr/local/bin/:$PATH<br />
<br />
So that your new tool versions will get picked up properly.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T22:16:08Z<p>Lally: Got fancier with my link syntax.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
[http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone Using these directions for setting up the zone].<br />
<br />
Create a user (or the build system will complain that you're "root"). Create /home, and then create the user. Let's call him 'moko'.<br />
<br />
Before doing the su - moko, it's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in [[MokoMakefile]]<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T22:09:56Z<p>Lally: /* Onto the Point */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5).<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Create a user (or the build system will complain that you're "root"). Create /home, and then create the user. Let's call him 'moko'.<br />
<br />
Before doing the su - moko, it's time to install a '''lot''' of software:<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest by download, configure, and make. Here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/ -- yum didn't have this.<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support. Yeah, the whole thing.<br />
# sqlite-3.6.3/ -- for python's sake.<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/ -- no package for this either.<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T21:01:22Z<p>Lally: /* Onto the Point */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
This is on a randomly, and partially, upgraded version of OpenSolaris Indiana (2008.5). <br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T20:52:53Z<p>Lally: Formatting.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing ''incredibly'' sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components ''extensively'' to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T20:52:02Z<p>Lally: </p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
Most of this is a war of inches, with the enemy using 10,000 paper cuts to bleed your soul dry.<br />
<br />
Most likely, he'll win.<br />
<br />
The opposition's key weapon is the excessive use of unnecessary features. Not even resulting in bloat, but just growing the dependency graph of installed software on the build system to make the entire thing /incredibly/ sensitive to almost any difference between their build systems and yours.<br />
<br />
Hence, why we're going to use a full Linux userland stack to do this. Atop of this, we'll have to upgrade components /extensively/ to make this all work. You're going to hate all this.<br />
<br />
But hey, at least you don't actually have to run Linux.<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success. Until then, it's best an amusement to watch from the sidelines.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T20:48:28Z<p>Lally: /* Onto the Point */</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success.<br />
<br />
== Onto the Point ==<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
# texinfo-4.9/ -- default version didn't have makeinfo<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T20:41:34Z<p>Lally: Disclaimer added.</p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
== Note and Disclaimer ==<br />
<br />
I'm still working on getting this all to work. Don't actually follow these instructions until I've claimed success.<br />
<br />
== Onto the Point ==<br />
<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T18:20:03Z<p>Lally: </p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
# apr-1.3.3/ -- for subversion<br />
# apr-util-1.3.4/ -- for subversion<br />
# bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
# diffstat-1.46/<br />
# help2man-1.36.4/ -- build without NLS.<br />
# git-1.6.0.2/<br />
# ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
# neon-0.28.3/ -- for subversion<br />
# Python-2.6/ -- for the proper sqlite support<br />
# sqlite-3.6.3/ -- for python<br />
# subversion-1.5.3/ -- yum didn't have this.<br />
# texi2html-1.64/<br />
<br />
Actually, whenever you have the option, --disable-nls in the configure scripts seems to make life a lot easier.<br />
<br />
This is being written as I do it, so note that it'll change until I've gotten a full build (make image) done. After that, it's dfu-util!</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T18:16:17Z<p>Lally: </p>
<hr />
<div>= Building on Solaris =<br />
<br />
(Well, OpenSolaris)<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
<br />
apr-1.3.3/ -- for subversion<br />
apr-util-1.3.4/ -- for subversion<br />
bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
diffstat-1.46/<br />
help2man-1.36.4/ -- build without NLS.<br />
git-1.6.0.2/<br />
ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
neon-0.28.3/ -- for subversion<br />
Python-2.6/ -- for the proper sqlite support<br />
sqlite-3.6.3/ -- for python<br />
subversion-1.5.3/ -- yum didn't have this.<br />
texi2html-1.64/<br />
<br />
<br />
Some more's probably necessary. I'll update this as I go.</div>Lallyhttp://wiki.openmoko.org/wiki/SolarisSolaris2008-10-13T18:15:14Z<p>Lally: Initial creation.</p>
<hr />
<div>Building on Solaris<br />
<br />
(Well, OpenSolaris)<br />
<br />
After a few dead starts, the best way to build on Solaris is to use a BrandZ Linux zone, and install enough stuff into the CentOS-3 image to make it all work.<br />
<br />
Using these directions for setting up the zone:<br />
http://wikis.sun.com/display/chosug/Installing+a+Linux+Zone<br />
<br />
Try to install what you can from the package list in MokoMakefile<br />
<br />
The rest, here's what I've had to install so far:<br />
apr-1.3.3/ -- for subversion<br />
apr-util-1.3.4/ -- for subversion<br />
bash-3.2/ -- the builtin cp doesn't take the -t option, the one in this newer bash does.<br />
diffstat-1.46/<br />
help2man-1.36.4/ -- build without NLS.<br />
git-1.6.0.2/ <br />
ncftp-3.2.2/ -- to make CPAN happy about Locale::gettext<br />
neon-0.28.3/ -- for subversion<br />
Python-2.6/ -- for the proper sqlite support<br />
sqlite-3.6.3/ -- for python<br />
subversion-1.5.3/ -- yum didn't have this.<br />
texi2html-1.64/ <br />
<br />
<br />
Some more's probably necessary. I'll update this as I go.<br />
<br />
[[Category:Solaris, Platforms, Porting]]</div>Lallyhttp://wiki.openmoko.org/wiki/Mac_OS_XMac OS X2008-09-12T23:53:51Z<p>Lally: /* Apple CDC Ethernet driver 10.5.x */</p>
<hr />
<div>Being primarily a Linux based project, the host platform of choice is Linux. However, it is entirely possible to work with Openmoko and Neo handsets using MacOS X, as you'll soon see.<br />
<br />
There are actually two ways of working with Openmoko and MacOS X. One is simply to run ubuntustudio on parallels (or your favourite debian in your favourite virtual machine), in which case you would then follow the instructions for Linux, and Ubuntu in particular.<br />
<br />
On the other hand, if you wish to use MacOS X directly, please continue:<br />
<br />
= Flashing to your device =<br />
To operate the Phase 1 devices (Neo 1973), you need to flash a root file system first.<br />
<br />
== Graphical Flashing with Openmoko Flasher ==<br />
Here are detailed instructions:<br />
# download Version 1.4 or later of Openmoko Flasher from http://www.dsitri.de/wiki.php?page=Openmoko%20Flasher<br />
# select the repository<br />
# press the Refresh button (which loads the list of packages on the server)<br />
# select and load the rootfs (takes some minutes for approx. 40 MByte)<br />
# Now, on your Openmoko, hold the AUX button while pressing the Power button for 5 seconds<br />
# the BOOT menu should appear<br />
# connect the USB cable<br />
# Press the Flash button<br />
# the BOOT menu screen on the OM should show an indication that it has been switched to DFU mode<br />
# (if it fails, unplug the Openmoko shortly and replug and try again (experience shows that it is needed up to three times)<br />
# if it successfully flashed, you should be able to boot the Openmoko and continue configuring AJZaurusUSB<br />
<br />
A Universal Binary version of dfu-utils tool (and libusb) is included in the Openmoko Flasher application bundle. You can access it as ''Openmoko Flasher.app/Contents/MacOS/dfu-util''.<br />
<br />
To flash from Terminal (which is sometimes required), see the directions below or in [[Flashing_the_Neo_FreeRunner|Flashing the Neo]]<br />
<br />
To flash the kernel:<br />
Openmoko\ Flasher.app/Contents/MacOS/dfu-util -a kernel -R -D uImage<br />
To flash the root filesystem:<br />
Openmoko\ Flasher.app/Contents/MacOS/dfu-util -a rootfs -R -D rootfs_filename.jffs2<br />
To flash the boot loader to NAND<br />
Openmoko\ Flasher.app/Contents/MacOS/dfu-util -a u-boot -R -D uboot.bin<br />
<br />
When flashing succeeds (in any of the above cases) the following should be shown:<br />
status(0) = No error condition is present<br />
Done!<br />
<br />
{{Note|If you get an error: ''Cannot set alternate interface: usb_set_altinterface: could not set alternate interface''. You have to unplug and replug it again. '''Make sure it stays in the Boot menu during that!''' After you have replugged your openmoko you should see ''DFU: Switching to DFU Mode'' on the openmoko screen. Now you can execute the command again and this time it should work.<br />
<br />
If somebody has a solution for this problem please contact me. - [[User: Anakron|Anakron]]}}<br />
<br />
== Compiling dfu-util ==<br />
Alternatively, you can compile dfu-util manually as described at http://wiki.openmoko.org/wiki/User:SNMoore but you need libusb (e.g. through MacPorts).<br />
<br />
= Connecting a Mac and an Openmoko device =<br />
<br />
== USB Serial ==<br />
<br />
It is possible to access the U-Boot [[Bootloader]] serial console from a Mac. You can use the Terminal application on Mac OS X, or <tt>minicom</tt> from [http://finkproject.org/ Fink] or [http://www.macports.org/ MacPorts] (formerly Darwin Ports.)<br />
<br />
The USB driver creates cu and tty character devices, for example<br />
$ ls -la /dev/tty.usb*<br />
crw-rw-rw- 1 root wheel 10, 18 Aug 23 14:10 /dev/tty.usbmodem00000001<br />
$ ls -la /dev/cu.usb*<br />
crw-rw-rw- 1 root wheel 10, 19 Aug 23 14:10 /dev/cu.usbmodem00000001<br />
<br />
=== USB Serial with screen ===<br />
<br />
The <code>screen</code> program is included with Mac OS X, and can be used from the terminal command line to connect to the serial console. To do this, simply get to a shell prompt in the terminal and invoke <code>screen</code> as follows:<br />
<pre><br />
% screen /dev/tty.usbmodem00000001<br />
</pre><br />
<br />
You should find yourself at the U-boot serial console prompt. To get out, type <code>control+a</code> followed by <code>control+backslash</code>.<br />
<br />
=== USB Serial with minicom ===<br />
<br />
The <tt>minicom</tt> program from the [http://www.macports.org/ MacPorts] collection can be used to access the USB serial port <tt>/dev/cu.usbmodem00000001</tt> (numbering may vary.)<br />
<br />
First install the program (assuming you already have MacPorts installed):<br />
<br />
sudo port install minicom<br />
<br />
Then launch it in configuration mode (the -s flag):<br />
<br />
sudo minicom -s<br />
<br />
Under "Serial Port Setup", set the Device to "/dev/cu.usbmodem00000001" and set Bps to "115200 8N1". Under "Modem and Dialing", enter empty strings for "Init string", "Reset string", and "Hang-up string". Save the setup as default ("dfl") then Exit. <br />
<br />
You should now be able to access the bootloader console. You should exit from Minicom before disconnecting the smartphone, or else you will get an error about unplugging a USB device while it is in use.<br />
<br />
=== USB Serial with Terminal ===<br />
<br />
The built in Mac Terminal application <tt>Terminal.app</tt> can be used to access the USB serial port <tt>/dev/tty.usbmodem00000001</tt> (numbering may vary.)<br />
<br />
An easy way to do this is to configure the terminal with Script Editor, as described in the short article, [http://www.macosxhints.com/article.php?story=20061109133825654 ''Use 'screen' as a serial terminal emulator''](macosxhints.com). Then,<br />
<br />
# Press and hold {{aux}} and then press and hold {{power}} for 5 seconds<br />
# Press {{aux}} to select <tt>Set console to USB</tt> in the U-Boot menu, and {{power}} to execute it<br />
# Start the serial terminal application. You should see a U-Boot command line prompt, such as<br />
In: usbtty<br />
Out: usbtty<br />
Err: usbtty<br />
DEVICE_CONFIGURED: 1<br />
Enabling automatic fast charge<br />
GTA01Bv4 #<br />
When you boot Linux on the smartphone, or if the smartphone powers down, Mac OS X will show a USB Device Unplug Notice, "The USB device has been unplugged while an application was still active. This can result in loss of data." This error is probably harmless.<br />
<br />
== USB Networking ==<br />
<br />
There are two drivers you can use to talk to the RNDIS/Ethernet Gadget that the Neo1973 presents to its host system. The main difference between them is stability, but both have their own problems. Leopard needs further testing (Apple revised the driver and the Network System Settings).<br />
<br />
=== Apple CDC Ethernet driver 10.4.10 ===<br />
MacOS X 10.4.10 and later includes a driver for RNDIS/Ethernet Gadget devices. Launch System Preferences -> Network and you should see "new interface detected enXX". <br />
<br />
<b>Issue</b>: Each time you reboot the Neo, the interface will get a different Ethernet address. This in turn makes Mac OS X create a new configuration record. After a while you'll end up with a load of unusable enXX devices - if you don't periodically clean them out. Open System Preferences and go to Network -> Show(Network Port Configurations) -> Select an enXX -> Delete.<br />
<br />
<b>Note</b>: this is not a problem to blame MacOSX for because it tries to make network configuration simpler based on the assumption of stable Ethernet addresses.<br />
<br />
=== Apple CDC Ethernet driver 10.5.x ===<br />
<br />
<b>Issue</b>:10.5 (Leopard) doesn't show a new ethernet interface for a Neo1973 running 2007.11. You'll only get the serial port, which is detected as a modem. The Ethernet device will show up in ifconfig though. If it doesn't, try the other driver below.<br />
<br />
It turns out that the AppleUSBCDC driver prefers to use the CDC-ACM interface of USB networking devices instead of CDC-ECM with the exception of a broadcom network card. You can download a patched AppleUSBCDC driver that will recognize the usb id/vendor pair of g_ether and force it to use CDC-ECM. You can obtain the OS X 10.5.X patched driver from: http://bugcommunity.com/downloads/usbcdc-g_ether.zip. Source code: http://bugcommunity.com/downloads/files/AppleUSBCDCDriver-g_ether.326.4.1.zip<br />
<br />
The issue of multiple network interfaces showing up whenever the device is rebooted/power-cycled is due to the g_ether driver randomly setting the host and device mac addresses. This problem is remedied by passing the same host and device mac addresses during the modprobe of g_ether.<br />
<br />
For example:<br />
<br />
modprobe g_ether host_addr=46:0d:9e:67:69:eb dev_addr=46:0d:9e:67:69:ec<br />
<br />
=== AJZaurusUSB driver ===<br />
<br />
You can also use the open source driver from [http://www.dsitri.de/wiki.php?page=AJZaurusUSB]. It was developed for handheld devices like iPAQ, Sharp Zaurus and Motorola A760, but works for Openmoko as well. Download and install according to the manual found inside the package. The code is GPL'd (source available) and runs on both Intel and PPC Macs with 10.3, 10.4 and 10.5.<br />
<br />
After rebooting or loading the kernel extension by hand, you should have a new Ethernet interface in your System Preferences/Network.<br />
<br />
<b>Note</b>: This driver does not have the same problem as the Apple driver does, where it constantly adds to the list of interfaces each time you reboot the neo, because the driver provides a constant ethernet address independently what the Neo says. Only flashing a new kernel might force you to update.<br />
<br />
<b>Issue</b>: This driver is sometimes a bit flaky, and a reboot of the Mac seems to bring it back. It is especially critical about hot unplugging the OM and sleep modes of MacBooks. This may even result in a Kernel Panic.<br />
<br />
=== Network Settings ===<br />
Open System Preferences and go to Network and you should see "new interface detected enXX". In the Show list box select the new interface - Ethernet Adapter enXX.<br />
<br />
Use this configuration on the new interface:<br />
<pre><br />
IP-V4: manual<br />
IP-Addr: 192.168.0.200 (you can use anything in 192.168.0.* but OM is configured by default to use 192.168.0.200 as the external gateway)<br />
Subnet: 255.255.255.0 (should be the default - see tip below if have issue with these settings)<br />
Router: 192.168.0.202 (not actually needed, OS X can figure this out for itself, unless you have other conflicting configurations)<br />
</pre><br />
<br />
<b>Tip</b>: If your Internet connection is also in the range 192.168.0.x then instead you might want/need to use:<br />
<pre><br />
Subnet: 255.255.255.248<br />
</pre><br />
<br />
=== Testing Your Connection ===<br />
You should be able to connect to your Neo! Try using Terminal (Applications->Utilities->Terminal) to ping the Neo at 192.168.0.202 and the roundtrip time should be between 1 and 2 ms.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
You can also [[scp]] files back and forth or share displays with X11. Additional software and configuration could allow telnet, SMB, or many other possibilities using the TCP/IP network over your USB connection.<br />
<br />
Try pinging your Mac PC from the Neo<br />
ping 192.168.0.200<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
If that works then your Mac is routing the neo globally--if not see [[MacOS_X#Enabling_the_Mac_as_an_Internet_Router | Sharing Internet Connection with Mac]].<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo & Network:<br />
ping www.google.com<br />
If that doesn't work then see [[USB_Networking#Configure_Default_Neo_DNS | Configuring Default Neo DNS]] to try and resolve the issue.<br />
<br />
Congordulations Elizagreth!!! The Neo is networked together with the Mac and sharing the Mac's interweb connection.<br />
<br />
== Bluetooth Networking ==<br />
{{InProgress}}<br />
<br />
This approach is based on: <br />
<br />
http://wiki.openmoko.org/wiki/Bluetooth_Support#Networking<br />
http://www.macosxhints.com/article.php?story=20051220221237711<br />
<br />
Unfortunately we can't use the pand (PAN daemon for BNEP) or dund (Dial Up Networking daemon for LAP) since neither service is available for the Mac.<br />
<br />
So, we configure a RFCOMM connection and a PPP gateway on the Mac. Finally, we connect the OM as a ppp client to the Mac.<br />
<br />
The reversed direction (OM as the Access Point and the Mac as the client) is described shortly in http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#PPP_Networking<br />
<br />
=== Making the Mac a PPP over Bluetooth Access Point ===<br />
<br />
In the Bluetooth System Preferences (10.4.11)<br />
* go to the Sharing pane<br />
* add a new service "BluetoothAccessPoint" of type RS-232<br />
* Enable that it is shown in the network preferences pane<br />
* Apply<br />
<br />
In the Network System Preferences<br />
* activate the new network configuration (BluetoothAccessPoint)<br />
* go tot the Modem tab and change the modem to "Null Modem 115200"<br />
* Apply<br />
<br />
In a Terminal, enter the following:<br />
$ sudo /usr/sbin/pppd /dev/tty.BluetoothAccessPoint 115200 noauth local passive proxyarp asyncmap 0 silent persist :172.16.140.14<br />
<br />
Here you see the 172.16.140.14 address, which makes it possible not to use natd, since it's in the same network as the Mac is. So the firewall knows where to sent it to -- no routing problems etc. Pick any free address in your private range. For instance, if you are using the following ... firewall: 192.168.1.1, Mac: 192.168.1.2, you can enter 192.168.1.3, assuming it's not used elsewhere on your network.<br />
<br />
If you want to be sure you did it right, open the system.log file on the Mac (tail -f /var/log/system.log), and you should see something like this:<br />
Jun 25 10:33:57 hostname pppd[679]: pppd 2.4.2 (Apple version 229) started by username, uid 0<br />
Jun 25 10:33:57 hostname pppd[679]: Connect: ppp0 <--> /dev/tty.BluetoothAccessPoint<br />
<br />
In Terminal, write<br />
sudo sysctl -w net.inet.ip.forwarding=1<br />
which should give the following feedback:<br />
net.inet.ip.forwarding: 0 -> 1<br />
<br />
In Terminal, write<br />
sudo ifconfig ppp0 up.<br />
<br />
=== Connecting the Openmoko as a Client to the Mac ===<br />
<br />
On the Openmoko do the following<br />
<br />
* Power on bluetooth<br />
<br />
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on<br />
<br />
* Scan for the Mac<br />
root@fic-gta01:~$ hcitool scan<br />
Scanning ...<br />
00:0E:6D:C0:0l:6A Sho<br />
00:20:E0:5A:FE:C8 MacBook<br />
<br />
* start the PPP client<br />
<br />
pppd 115000 192.168.1.202:192.168.1.200 local defaultroute pty 'rfcomm connect 0 00:16:CB:2F:A0:46 1'<br />
<br />
* Enjoy<br />
<br />
== WiFi Networking ==<br />
{{InProgress}}<br />
<br />
To Be Done.<br />
<br />
== Neo1973 as a Bluetooth GPRS modem ==<br />
{{InProgress}}<br />
<br />
To Be Done.<br />
<br />
= Enabling the Mac as an Internet Router =<br />
<br />
Here is described how to enable your Mac to serve as a Internet Router for your Openmoko device.<br />
<br />
Note: you have to open all services you want to use from the Openmoko in the Mac Firewall.<br />
<br />
== USB connection ==<br />
<br />
In the Sharing System Preferences<br />
* click the Internet tab<br />
* Check all the ethernet (en) interfaces you want to enable Internet access for (i.e. the USB connection)<br />
<br />
SSH into your Neo and create /etc/resolv.conf, specify your Internet router IP address as the name server. You can simply copy the /etc/resolv.conf from your Mac.<br />
scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf<br />
<br />
Example:<br />
nameserver 192.168.1.200 # replace by your real nameserver address<br />
<br />
Make sure your Neo routing table has entries so that all internet traffic is sent to your Mac (which will forward it to the outside world)<br />
<br />
root@fic-gta01:~$ route<br />
Kernel IP routing table<br />
Destination Gateway Genmask Flags Metric Ref Use Iface<br />
192.168.0.0 * 255.255.255.0 U 0 0 0 usb0<br />
default 192.168.0.200 0.0.0.0 UG 0 0 0 usb0<br />
<br />
Don't forget to enable your USB interface for Internet Sharing!<br />
<br />
== Bluetooth connection ==<br />
{{InProgress}}<br />
<br />
= Accessing data and services on your device =<br />
<br />
== ssh ==<br />
<br />
After making the USB connection work, start ssh:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
If you don't have installed the key, it will ask for a "yes" on the first connection. The root password is blank unless you change it.<br />
<br />
MacBook-hns:~ hns$ ssh -l root 192.168.0.202<br />
root@192.168.0.202's password: <br />
root@fic-gta01:~$ hostname<br />
fic-gta01<br />
root@fic-gta01:~$<br />
<br />
NOTE: the ssh daemon (dropbear 0.49) on the Openmoko appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
== SMB ==<br />
{{InProgress}}<br />
<br />
To Be Done.<br />
<br />
== X11 ==<br />
Launch Apple X11.<br />
xhost +192.168.0.202.<br />
On the Neo:<br />
export DISPLAY=192.168.0.200:0.0<br />
<br />
== Synchronizing ==<br />
{{InProgress}}<br />
<br />
This is not done yet. Possible solutions are SyncML or ZMacSync http://www.dsitri.de/wiki.php?page=ZMacSync<br />
<br />
ZMacSync does not yet synchronize but allows more easy access to the Openmoko through Terminal/ssh.<br />
<br />
<br />
= Developing Openmoko software on a Mac =<br />
<br />
== Using virtualization software and MokoMakefile/OpenEmbedded ==<br />
<br />
You can use Parallels or VMWare to install your favourite Linux distribution and then develop just as on Linux.<br />
<br />
There are some drawback since AFAIK dfu-util may not work correctly in such environments.<br />
<br />
Don't bother with Parallels Desktop for Mac (<=3), the current USB support is terrible and USB storage keys don't even work so there was no way I would try dfu-util. USB keys work under VMWare Fusion for Mac though I have yet to try dfu-util in an VM under VMWare Fusion as there is Openmoko Flasher for Mac. -- [[User: Eric|Eric]]<br />
<br />
=== VMware Fusion ===<br />
<br />
In VMware Fusion USB Networking is working properly, just plug in the device and connect it to your virtual machine.<br />
<br />
Unfortunately dfu-util is currently not working. In fact if you get dfu-util working via unplug/replug method on Mac OS X it works inside VMware too.<br />
<br />
=== VirtualBox ===<br />
<br />
dfu-util is not working, has some problems with getting exclusive access to the USB device.<br />
<br />
== Natively ==<br />
{{InProgress}}<br />
<br />
There are some efforts to get through process of compiling OE and Openmoko under mac: [[Openmoko_under_QEMU_on_MacOSX]]<br />
<br />
== GNUstep/mySTEP SDK ==<br />
<br />
There is a [[QuantumSTEP]]/mySTEP project to port GNUstep to the Openmoko/Neo: [[http://www.quantum-step.com/wiki.php?page=Openmoko-Edition More Info]]<br />
An SDK for Xcode/Interface Builder is also available: [[http://www.versiontracker.com/dyn/moreinfo/macosx/20581 Entry at Version Tracker]] [[http://www.quantum-step.com/wiki.php?page=SDK More Info]]<br />
<br />
== Tools for Developers ==<br />
<br />
Some tools that run on MacOS X<br />
<br />
=== mkfs.jffs2 ===<br />
[[http://www.quantum-step.com/download/Openmoko-Edition/mkfs.jffs2.tgz mkfs.jffs2]] - make JFFS2 (root) file system (Universal Binary). Package includes sources and Xcode 2.4 project file to rebuild on MacOS X 10.4.11. NOT TESTED DEEPLY.<br />
<br />
mkfs.jffs2 --pad=0x700000 -o rootfs.jffs2 -e 0x4000 -n -d/tmp/jffsroot/<br />
<br />
=== Crosscompiler Toolchain ===<br />
<br />
[[http://www.quantum-step.com/wiki.php?page=Compiler gcc 2.95.3]] - OABI cross compiler toolchain (C, C++, Obj-C) with Linux headers (PPC and Intel Macs)<br />
<br />
If someone has a newer one that works, please provide as an installable OSX Package.<br />
<br />
<br />
Will the ones from MacPorts work? [[http://www.macports.org/ports.php?by=name&substr=gnueabi]] I'm still trying to get QEMU to work and haven't had a chance to test it yet.<br />
<br />
= Other Resources =<br />
<br />
== Search Software Repositories ==<br />
<br />
[[http://www.versiontracker.com/php/qs.php?action=search&str=openmoko&srchArea=macosx Keyword Openmoko]] at VersionTracker<br />
<br />
== Discussion Fora ==<br />
<br />
[[http://www.oesf.org/forums/index.php?showforum=63 Mac Issues Forum]] at Open Embedded Software Foundation (was Zaurus User Group)<br />
<br />
[[Category:Flashing Openmoko]]</div>Lallyhttp://wiki.openmoko.org/wiki/Neo_FreeRunner_OpennessNeo FreeRunner Openness2008-09-10T03:05:40Z<p>Lally: Fixed a changed link in the Bluetooth section.</p>
<hr />
<div>__NOTOC__<br />
__NOEDITSECTION__<br />
{{Languages|GTA02_Openness}}<br />
{{gta02menu}}<br />
<br />
Many people are more interested in getting a completely (and openly) documented hardware platform than in getting one with "just" all drivers under GPL. Why is this so? Just imagine an open source kernel which is released under a copyleft license which is incompatible to the GPL (like the OpenSolaris kernel). These poor developers would have to reverse engineer a so called "open platform" as they cannot use the available drivers and header files. If you are a GPL-is-the-only-true-license guy/girl: Don't be offended by this, it's simply about choice. :)<br />
<br />
This page tries to give you an overview how open the GTA02 hardware is documented and where to get the documentation. Your help is needed! If you know anything which is missing just add it, if possible with a reference where the info is coming from.<br />
<br />
{|border=1<br />
!Component<br />
!Name<br />
!Openness<br />
|-<br />
|CPU<br />
|Samsung S3C2442<br />
|Docs available from Samsung, but not easily. Only after registering and qualifying. [http://www.elektronika.opatnet.cz/datasheet/U/um_s3c2442b_rev12.pdf here] is a copy. um_s3c2442b_rev12.pdf]<br />
|-<br />
|NAND flash<br />
|Samsung?<br />
|Standard [[NAND]] command-set.<br />
|-<br />
|GSM modem<br />
|TI Calypso?<br />
|Speaks standard protocols with proprietary extensions. Most of the proprietary extensions are present also in some BenQ and/or Enfora Enabler modems which have open documentation available on internet. See also [[GTA01 gsm modem]]. The NDAd documentation for the calypso, [http://cryptome.org/ti-calypso1.pdf register definition] and [http://cryptome.org/ti-calypso2.pdf hardware definition] was leaked onto a public forum on the 4th of March by persons or persons unknown.<br />
The legality of reading these files may vary according to your local laws, as may generating code from them.<br />
|-<br />
|Transceiver<br />
|TRF6151?<br />
|No interaction with software.<br />
|-<br />
|Analog baseband<br />
|TWL3014?<br />
|No interaction with software.<br />
|-<br />
|WiFi<br />
|Atheros AR6K<br />
|No documentation available! GPL'ed driver only.<br />
|-<br />
|Bluetooth<br />
|Delta DFBM-CS320 Class2 Module using CSR BlueCore4?<br />
|Documented [http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/ here] <br />
|-<br />
|GPS<br />
|[[u-blox ANTARIS 4 ATR0635]]<br />
|Serial protocol documentation is freely available from the manufacturer.<br />
|-<br />
|Graphic Accelerator<br />
|SMedia 3362<br />
|Documentation is only available under NDA. Unlike [http://lists.openmoko.org/pipermail/community/2007-September/010175.html previously announced],<br />
there are [http://ibot.rikers.org/%23openmoko/20080423.html.gz no current plans] to get this information out of NDA due to funding and time constraints.<br />
|-<br />
|MicroSDHC<br />
|?<br />
|Connected to the SMedia 3362<br />
|-<br />
|LCD<br />
|TD028TTEC1 module using a Toshiba JBT6K74 TFT LCD Driver Chipset?<br />
|No open documentation available! GPL'ed driver only.<br />
|-<br />
|Touch Screen<br />
|?<br />
|Connected to the s3c2442 similar to GTA01<br />
|-<br />
|Vibrator<br />
|<br />
|Simple motor attached to the PWM output of the s3c2442<br />
|-<br />
|Sound Codec<br />
|Wolfson Codec<br />
|[http://www.wolfsonmicro.com/uploads/documents/en/WM8753.pdf Full data sheet]<br />
|-<br />
|Sound Amplifier<br />
|National Semiconductor LM4857<br />
|[http://www.national.com/ds.cgi/LM/LM4857.pdf Full data sheet]<br />
|-<br />
|Power management<br />
|Philips PCF50606<br />
|Documented [http://www.rockbox.org/twiki/pub/Main/DataSheets/pcf50606.pdf here]<br />
|-<br />
|Battery<br />
|Proprietary<br />
|Schematic [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf here]<br />
|- <br />
|JTAG<br />
|?<br />
|Standardized, BSDL file for the CPU will hopefully become available<br />
|-<br />
|Case<br />
|Proprietary<br />
|Openmoko has released the CAD files for the case schematics. See the [http://downloads.openmoko.org/CAD/ CAD directory]<br />
|-<br />
|}<br />
<br />
[[Category:Neo FreeRunner Hardware]]</div>Lallyhttp://wiki.openmoko.org/wiki/Wish_ListWish List2008-05-12T17:37:53Z<p>Lally: /* Anti Theft Application */</p>
<hr />
<div>This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].<br />
<br />
== Development ==<br />
=== Painless SDK installation & Setup ===<br />
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]<br />
<br />
* one command for installation (apt-get install openmoko)<br />
* one command to start Xnest (openmoko-xephyr?)<br />
* one command to start an i386 shell (openmoko-386-shell)<br />
* one command to start an armel shell (openmoko-armel-shell)<br />
<br />
No extra configuration required.<br />
<br />
==== IDE Plugins ====<br />
People like to see plugins for<br />
* [http://anjuta.sourceforge.net Anjuta]<br />
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].<br />
* [http://www.netbeans.org NetBeans]<br />
* Game engine - Game Creation plugins<br />
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]<br />
* [http://www.kdevelop.org KDevelop]<br />
* [http://developer.apple.com/tools/xcode/ XCode]<br />
* [http://www.monodevelop.com MonoDevelop]<br />
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]<br />
<br />
==== UI Designer ====<br />
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]<br />
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?<br />
<br />
<br />
==== Built-in Scripting Language ====<br />
{{Main|Wishlist:BuiltInScriptingLanguage}}<br />
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.<br />
==== Easy build of the existing autotools - based packages ====<br />
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.<br />
<br />
===Foreign Widget Set Bindings ===<br />
==== Qt Integration ====<br />
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.<br />
<br />
==== Maemo Integration ====<br />
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.<br />
<br />
==== wxWidgets Integration ====<br />
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.<br />
<br />
wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]<br />
<br />
==== SDL Integration ====<br />
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.<br />
<br />
==== Cocoa / GNUstep ====<br />
Allows to use MacOS X as a development platform.<br />
<br />
=== Software: Language bindings ===<br />
==== Python bindings ====<br />
Python bindings seem to be a commonly requested feature. <br />
<br />
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."<br />
<br />
==== C++ bindings ====<br />
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.<br />
<br />
==== Ruby bindings ====<br />
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)<br />
<br />
==== Java bindings ====<br />
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported. <br />
==== Other bindings ====<br />
* Perl<br />
* C#<br />
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings<br />
<br />
== Community Support ==<br />
<br />
=== [http://projects.openmoko.org projects.openmoko.org] ===<br />
Infrastructure for developers with<br />
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)<br />
* One mailing list for project<br />
<br />
== Platform ==<br />
=== Community Images ===<br />
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.<br />
<br />
=== Wishlist voting ===<br />
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.<br />
<br />
Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]<br />
<br />
== Software: Additional features ==<br />
<br />
===PDA Mode===<br />
<br />
There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.<br />
<br />
===Driving Mode===<br />
<br />
It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones<br />
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.<br />
<br />
===Calling===<br />
<br />
==== Mask ID based on dialed numbers ====<br />
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.<br />
<br />
==== Use calling cards and similar routing techniques for lower-cost calling ====<br />
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.<br />
<br />
==== Outgoing black/white lists ====<br />
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.<br />
<br />
Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.<br />
<br />
==== Time-based blocking/unblocking of calls ====<br />
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.<br />
<br />
====Speaker-phone====<br />
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.<br />
<br />
====Advanced Airtime Tracking====<br />
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.<br />
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.<br />
<br />
* Call duration should consider billing increments and show the durations according to accounting period<br />
<br />
<br />
<br />
==== Anti-stutter software ====<br />
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.<br />
<br />
====Minimize In-Call mode (check address book while in call)====<br />
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.<br />
<br />
Similar request when using the browser (lookup passwords, todo list, etc).<br />
<br />
====Hold Music (Ringback Tone)====<br />
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.<br />
This can partially be implemented on the phone.<br />
Issues are:<br />
*In countries where callers pay, this will make you unpopular.<br />
*In countries where the called party pays, it will use your minutes, or cost you money.<br />
**A list of people to activate this function for would alleviate this.<br />
*[[GPRS]] internet connection will stall while the hold music is being played.<br />
*Extra battery used when playing music.<br />
<br />
Also see [[Answering Machine]].<br />
<br />
====Play sound clips over the air====<br />
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104<br />
The buttons can have default sounds, but also have the ability to be customized.<br />
<br />
It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.<br />
<br />
==== DTMF Landline Dialing ====<br />
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.<br />
<br />
Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.<br />
<br />
For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.<br />
<br />
==== Conversation Recorder ====<br />
<br />
An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.<br />
<br />
====Unlicensed Mobile Access (UMA)====<br />
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.<br />
<br />
This can be combined with a GPS map to show where local free hubs are.<br />
<br />
==== Ignore-Call Button ====<br />
{{Main|Wishlist:Ignore Call Button}}<br />
<br />
Shut up a ringing phone, without accepting or rejecting the call.<br />
<br />
Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises. <br />
<br />
A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.<br />
<br />
The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).<br />
<br />
==== Voice Mailbox ====<br />
{{Main|Voice Mailbox}}<br />
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.<br />
Can act profile-dependent.<br />
<br />
==== Hold Button ====<br />
<br />
Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.<br />
<br />
==== Unanswered Call, Fast Call ====<br />
<br />
In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.<br />
Then the user of the mobile phone calls the other user(using the CallerID recognition).<br />
<br />
===Audio===<br />
<br />
==== Ambient Noise Detection ====<br />
{{Main|Wishlist:Software:Ambient Noise Detection}}<br />
<br />
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.<br />
<br />
If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.<br />
<br />
Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.<br />
<br />
==== Active noise control ====<br />
<br />
Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.<br />
<br />
==== Hear Impaired Mode ====<br />
<br />
Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).<br />
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.<br />
<br />
Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.<br />
<br />
==== Mute Button ====<br />
<br />
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.<br />
<br />
<br />
===Web Browser===<br />
<br />
==== Full-page Zoom Support ====<br />
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.<br />
<br />
The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.<br />
<br />
* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.<br />
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.<br />
* If this is not practical, Minimo with full-page-zoom ability is good.<br />
<br />
==== Plugins Support ====<br />
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].<br />
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.<br />
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.<br />
<br />
==== Widget support ====<br />
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)<br />
<br />
There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.<br />
<br />
===Media===<br />
====Music/Video Software====<br />
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular. <br />
<br />
Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.<br />
<br />
It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!<br />
<br />
- Possible copyright issues sharing music files?<br />
<br />
Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.<br />
<br />
==== Reading Support ====<br />
It would be really great to be able to read :<br />
<br />
*PDF<br />
*Open Document files<br />
*Text / RTF files<br />
*fb2 files (fbreader)<br />
*MS Office files<br />
*Aportis Doc (pdb)<br />
*DjVu<br />
*...<br />
<br />
In both landscape and portrait<br />
<br />
==== Wikipedia Mirror ====<br />
{{Main|Wishlist:Wikipedia_Mirror}}<br />
<br />
==== Blog ScribblePad ====<br />
<br />
Draw an image (and maybe add some text), then post to your blog.<br />
<br />
==== E-Book Reader ====<br />
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.<br />
<br />
==== Personal Wiki ====<br />
{{Main|Wishlist:PersonalWiki}}<br />
<br />
Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].<br />
<br />
[http://www.didiwiki.org/ Didiwiki]<br />
<br />
<br />
==== Dictionary, thesaurus, translator and flashcards ====<br />
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.<br />
<br />
'''Dictionary'''<br />
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:<br />
<br />
advantages:<br />
* small<br />
* very efficient + useful<br />
* only limited to really needed functions<br />
<br />
Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)<br />
<br />
==== Flickr uploader ====<br />
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.<br />
<br />
===PIM (Personal Information Managment)===<br />
====Context Sensitivity====<br />
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?<br />
<br />
==== Notes ====<br />
<br />
Something for taking notes would be a nice feature:<br />
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.<br />
<br />
Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].<br />
<br />
==== Calendar ====<br />
<br />
A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.<br />
The tool should have a reminder feature and other features like other mobile phones already have.<br />
<br />
I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)<br />
<br />
* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)<br />
<br />
==== Address Book ====<br />
<br />
* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP<br />
servers or whatever.<br />
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.<br />
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done<br />
by integrating with whatever on-phone GPS mapping software the Neo ends up using.<br />
* Random text input 'notes' about a contact<br />
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's<br />
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant<br />
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account<br />
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.<br />
* Support for:<br />
**[http://en.wikipedia.org/wiki/SyncML SyncML]<br />
**[http://abook.sourceforge.net/ abook] a text-based addressbook program<br />
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book<br />
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).<br />
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.<br />
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).<br />
<br />
==== Database/List Display/Edit ====<br />
{{Main|Wishlist:PilotDB}}<br />
<br />
One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.<br />
<br />
==== To-Do lists ====<br />
<br />
* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.<br />
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.<br />
<br />
<br />
==== Context based To-Do list ====<br />
{{Main|Wishlist:context based to-do list}}<br />
<br />
If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.<br />
<br />
==== Workout ====<br />
<br />
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.<br />
<br />
==== Shopping List ====<br />
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.<br />
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.<br />
<br />
==== [[Fuel Log]] ====<br />
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).<br />
Advanced features could include:<br />
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)<br />
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)<br />
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)<br />
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server<br />
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.<br />
<br />
==== Keep in touch reminder ====<br />
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.<br />
<br />
<br />
==== Menstruation period timer ====<br />
Fill in statistics and compute probabilities for menstruation, fertility, mood.<br />
See http://www.getjar.com/products/48/MyGirls<br />
<br />
==== Tagging ====<br />
{{Main|Wishlist:Tagging}}<br />
Tags can be used by various applications. Requirement is interoperability for further enhancement.<br />
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.<br />
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.<br />
<br />
<br />
<br />
==== Exchange Integration ====<br />
<br />
Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.<br />
<br />
* Is the time right to name names ? Add as your liking...<br />
** Plugin/integration to & from Kontact<br />
** Same with Evolution - Thunderbird - Seamonkey<br />
** ?? Google Calendars ?? (this one is tough)<br />
** Ms Exchange<br />
<br />
==== An electronic wallet ====<br />
<br />
A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).<br />
<br />
Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]<br />
<br />
==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====<br />
<br />
Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.<br />
<br />
Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.<br />
<br />
PROS: <br />
*genuine saving in time for social and business situations<br />
<br />
CONS: <br />
*I am sure there are some security hassles to be pondered....<br />
*not going to be used every day... definitely not an immediate priority.....<br />
*only at geek conferences will all have a neo....<br />
<br />
==== SMS Counter ====<br />
<br />
An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.<br />
<br />
==== Data Storage ====<br />
<br />
Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.<br />
Make this list available through the address book.<br />
This would be great for people who are switching between one or more communication channels frequently<br />
<br />
===Profiles===<br />
{{Main|Wishlist:Profiles}}<br />
<br />
The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.<br />
And how to automatically switch between them.<br />
<br />
===Text Messaging===<br />
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included<br />
For current development status of the messaging-app see: [[Messages]].<br />
<br />
There are many useful options that now can be used to full capacity:<br />
<br />
* '''Instant Messaging'''<br />
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net<br />
<br />
* '''Acknowledge/status SMS'''<br />
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.<br />
<br />
** '''Special handling of status-SMS''' <br />
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.<br />
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date<br />
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See: <br />
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]<br />
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)<br />
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung<br />
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/<br />
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.<br />
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.<br />
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])<br />
** Implement a script that abbreviates :-)<br />
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.<br />
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).<br />
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel<br />
* '''Searching''' allow full-text search or string search.<br />
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...<br />
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.<br />
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.<br />
* '''SMS-EMail-Gateway'''<br />
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS<br />
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).<br />
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it<br />
** By standard carrier SMS - cost 10cents<br />
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE<br />
** By email/Wifi - cost FREE<br />
** By email/GPRS - cost ?<br />
** Too many options!!!<br />
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.<br />
<br />
=== Text input ===<br />
{{Main|Wishlist:Text Input}}<br />
There are many good suggestions for text input on the specific text input ideas page.<br />
<br />
=== More/Custom Input Method Widgets ===<br />
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}<br />
Additional and customizable Input Method Widgets (similar to virtual keyboard). <br />
This could add soft-key functionality to games or other applications such as:<br />
*D-Pads<br />
*buttons<br />
*virtual trackballs<br />
*...<br />
Personalized layouts could be associated with each application.<br />
<br />
=== Games ===<br />
{{Main|Wishlist:Games}}<br />
<br />
=== Mesh Networking ===<br />
{{Main|Wishlist:Mesh Networking}}<br />
<br />
=== Printing Support ===<br />
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:<br />
<br />
* Notes<br />
* Maps<br />
* Email<br />
* Calendars<br />
* ...<br />
<br />
Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on<br />
<br />
# GTK+'s printing support<br />
# Making cups run on a really small system<br />
<br />
{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}<br />
<br />
There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.<br />
<br />
Further details:<br />
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]<br />
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]<br />
* [http://www.j5live.com/?p=204 j5live.com]<br />
<br />
===Misc Software===<br />
====Clocks/timers/Activity meters====<br />
===== Sport tracker =====<br />
{{Main|Wishlist:Sport_tracker}}<br />
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.<br />
<br />
===== Standby clock =====<br />
{{Main|Wishlist:Standby_clock}}<br />
A quick way to see what time it is.<br />
<br />
===== Egg Timer =====<br />
{{Main|Wishlist:EggTimer}}<br />
<br />
Very simple (one click) count up / count down timers are very useful.<br />
<br />
===== Cycle Computer =====<br />
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.<br />
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)<br />
<br />
===== NTP Server =====<br />
<br />
Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices. <br />
<br />
I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.<br />
<br />
<br />
===== Find Keys/locate stuff =====<br />
<br />
This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.<br />
<br />
A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you. <br />
<br />
Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.<br />
<br />
For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].<br />
<br />
===== Reality check reminder =====<br />
{{Main|Wishlist:Reality check reminder}}<br />
<br />
A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]<br />
<br />
===== Automatic timezone changing (GPS) =====<br />
<br />
Check the timezone with GPS and adapt them.<br />
<br />
====Calculators====<br />
===== A Universal Unit Converter Tool =====<br />
<br />
One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers. <br />
<br />
Ideas what kind of conversions a converter tool could do:<br />
<br />
Length<br />
- Acceleration<br />
- Angle<br />
- Angular Velocity<br />
- Area<br />
- Capacitance<br />
- Radioactivity<br />
- Currency <br />
- Charge<br />
- Computer Memory<br />
- Conductance<br />
- Density<br />
- Energy<br />
- Illumination<br />
- Power<br />
- Force <br />
- Flow<br />
- Pressure<br />
- Speed<br />
- Temperature<br />
- Time<br />
- Torque<br />
- Viscosity<br />
- Volume<br />
- Weight<br />
<br />
Roman Numerals<br />
- ASCII, Hex<br />
- Cooking<br />
- BMI<br />
- Clothing Sizes<br />
<br />
Money Converter based on current rates from Internet...<br />
e. g. Dollar <-> Euro<br />
<br />
Physical and Mathematical Constants<br />
GPS conversions <br />
<br />
- link to or integration of a scientific calculator<br />
- link to or integration of a simple calculator<br />
<br />
A good basis for such a converter tool could be the Palm program "units" from <br />
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.<br />
<br />
For GPS conversions see gpsbabel [http://www.gpsbabel.org]<br />
<br />
===== An Postfix Notation (RPN) calculator =====<br />
<br />
Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.<br />
<br />
==== Windows CE Emulator ====<br />
<br />
On ARM machine, Windows CE API emulator, like Wine on x86 machines. <br />
<br />
==== PalmOS Emulator ====<br />
<br />
The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.<br />
<br />
I'd like to see a Windows CE Emulator with active sync support.<br />
<br />
==== Chumby Emulator ====<br />
<br />
Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.<br />
<br />
==== TV Guide ====<br />
Display a TV guide using [http://xmltv.org xmltv].<br />
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)<br />
<br />
==== Alcohol meter ====<br />
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.<br />
See, for example (German text) http://www.misterio-online.de/promille.htm<br />
<br />
==== Interaction with LEGO Mindstorm ====<br />
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.<br />
<br />
==== Flashlight ====<br />
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!<br />
<br />
==== Wii Controller Emulator ====<br />
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.<br />
<br />
==== FUSE support ====<br />
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)<br />
<br />
=== Accessibility ===<br />
Accessibility features for the visually impaired.<br />
* High Contrast Themes.<br />
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.<br />
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]<br />
<br />
==== VOIP ====<br />
* [[Dialer]] should be able to use SIP.<br />
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.<br />
* A standard SIP client would probably fit better into the "free and open" philosophy.<br />
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.<br />
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)<br />
<br />
''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''<br />
<br />
Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.<br />
Edw/<br />
<br />
==== Power Meter ====<br />
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.<br />
<br />
Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?<br />
<br />
=== Accelerometer wishes ===<br />
==== Flick interface ====<br />
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.<br />
<br />
Sensitivity of the scrolling should be configurable and a test option provided.<br />
<br />
==== Reading navigation of documents enhanced by accelerometers ====<br />
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.<br />
<br />
I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)<br />
<br />
==== Wand UI ====<br />
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.<br />
==== Panning interface ====<br />
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.<br />
<br />
In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.<br />
<br />
When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.<br />
<br />
==== Shake-to-Wake ====<br />
Giving the phone a shake enables voice commands for a few seconds.<br />
Usage Examples: <br />
<br />
* {Shake} "Call" ''ContactName'' ''PhoneType''<br />
* {Shake} "Call John Mobile" (Calls John's mobile)<br />
* {Shake} ''ApplicationName''<br />
* {Shake} "Reader" (Opens the e-book application)<br />
<br />
Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)<br />
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)<br />
<br />
I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.<br />
<br />
==== Emergency call ====<br />
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.<br />
<br />
A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).<br />
<br />
:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)<br />
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)<br />
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]<br />
<br />
==== Movement detection ====<br />
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.<br />
<br />
==== Games ====<br />
Imagine a first person shooter that you look around by turning your body.<br />
<br />
==== Sloshing battery indicator ====<br />
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.<br />
==== Steady screen ====<br />
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.<br />
* being mounted inside a vehicle<br />
* during certain sports<br />
* while the internal vibrator is activated (perhaps)<br />
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.<br />
<br />
At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements. <br />
<br />
Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.<br />
<br />
In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.<br />
<br />
These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.<br />
<br />
==== Taping as input ====<br />
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.<br />
<br />
==== Others ====<br />
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].<br />
<br />
=== Connectivity ===<br />
<br />
==== VNC ====<br />
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.<br />
<br />
==== Networked X-Windows ====<br />
<br />
Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.<br />
<br />
==== NX client ====<br />
<br />
A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]<br />
<br />
==== OpenOffice Presenter Control ====<br />
<br />
I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.<br />
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.<br />
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse <br />
click than to fast than you must go back.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Amarok and other Media Player remote control ====<br />
<br />
Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.<br />
<br />
==== Read informations with SMS ====<br />
Send a SMS with Code to the OpenMoko (from a specific number).<br />
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).<br />
<br />
=== Security ===<br />
<br />
==== General Filesystem Encryption ====<br />
<br />
If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed. <br />
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).<br />
<br />
http://luks.endorphin.org<br />
<br />
==== My Account ====<br />
{{Main|My Account}}<br />
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.<br />
<br />
Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.<br />
<br />
==== [http://zfoneproject.com/ Zfone] or similar ====<br />
<br />
Something that allows the user to speak with another person securely.<br />
<br />
==== GSM Encryption ====<br />
<br />
This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel. <br />
<br />
[[OSvS]]<br />
<br />
==== My Voice is my Passport ====<br />
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."<br />
<br />
==== Firewall ====<br />
A network firewall<br />
<br />
==== Full Mac Support ====<br />
Full mac support, preferably with full software and full sync capabilities with iCal and iMail <br />
<br />
==== Anti Theft Application ====<br />
<br />
This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.<br />
<br />
Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.<br />
<br />
====RFID based personal alerts====<br />
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.<br />
<br />
Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.<br />
<br />
====OpenVPN Client====<br />
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.<br />
<br />
=== Integrated Help System ===<br />
<br />
A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.<br />
<br />
===Performance optimisation===<br />
==== Use DMA engine in CPU for blitter ====<br />
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.<br />
<br />
==== Use virtual screen to optimise scrolling ====<br />
In some other cases, the hardware supported virtual screen may also speed it up.<br />
===Reusable Display/UI Widgets===<br />
====Use BigPage for full page zoom, scroll, scale in many apps====<br />
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen<br />
<br />
==Bluetooth==<br />
<br />
=== Voice Dialing ===<br />
<br />
Dial by voice commands.<br />
<br>Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.<br />
<br />
=== Music through Bluetooth Headset ===<br />
<br />
Music can be played through a Bluetooth headset, but would stop playing when a call comes in.<br />
<br />
=== Walkie Talkie ===<br />
<br />
Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.<br />
<br />
Features for this applications can be:<br />
* Push To Talk (PTT) button<br />
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.<br />
* Optionally a full duplex mode<br />
* Different channels to choose from<br />
* Monitor different (preselected or all) channels for traffic.<br />
* Content encryption<br />
* Active noise control<br />
* Allow zero config use (units can talk without any access point helping)<br />
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel<br />
<br />
Local (non-GPRS) use cases include chatting while biking<br />
or motorcycling in a group; perhaps also in a car caravan.<br />
This application could also be used as a baby-phone to monitor your siblings.<br />
<br />
This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.<br />
<br />
(One thumbs up from me) Jackcday<br />
<br />
See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
=== Automatic Sync ===<br />
<br />
Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.<br />
<br />
=== GPS Assisted Bluetooth Management ===<br />
<br />
Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.<br />
<br />
A Bluetooth device is configured for automatic reacquisition based on the following profiles:<br />
* Manual - only when Bluetooth is on<br />
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.<br />
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.<br />
<br />
Each target device is configured as follows:<br />
* Automatic acquisition at last known location: enable/disable<br />
* Automatic acquisition at these locations: list of nickname + coordinates + range<br />
<br />
==== Non-mobile devices ====<br />
<br />
Examples devices include: computers<br />
<br />
The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.<br />
<br />
Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.<br />
<br />
==== Mobile devices ====<br />
<br />
Example devices include: automobiles<br />
<br />
Mobile devices are configured to have two types of locations:<br />
# Last known location<br />
# Non-mobile locations (homes)<br />
<br />
===== Last known location =====<br />
<br />
A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.<br />
<br />
===== Non-mobile locations (homes) =====<br />
<br />
As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.<br />
<br />
=== Bluetooth neighbor detection and multiuser apps ===<br />
<br />
Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.<br />
<br />
=== Bluetooth environment detection ===<br />
<br />
Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.<br />
<br />
=== Remote control ===<br />
<br />
==== Wireless presenter ====<br />
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features: <br />
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.<br />
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point<br />
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature). <br />
* If you want to be super-cool, you give a preview of the notes of the next slide in the show. <br />
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.<br />
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Initiated from another device ====<br />
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.<br />
==== Directed at another device ====<br />
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.<br />
<br />
[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)<br />
<br />
Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]<br />
<br />
=== Bluetooth Car Connection ===<br />
<br />
Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.<br />
<br />
Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]<br />
<br />
==== Dude, Where's My Car? ====<br />
<br />
When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.<br />
<br />
=== [[Bluetooth powered Multi-SIM support]] ===<br />
<br />
As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.<br />
<br />
Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:<br />
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)<br />
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset<br />
* Same for Short Messages/MMS/Internet<br />
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.<br />
Advantage: No 'switching' between cards<br />
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.<br />
<br />
===Internet Gateway===<br />
<br />
If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.<br />
<br />
=== Social Networking ===<br />
<br />
Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.<br />
<br />
=== Give userspace api control over bluetooth signal strength ===<br />
<br />
I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.<br />
<br />
<br />
== WiFi ==<br />
<br />
=== Industrial grade Wifi management ===<br />
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.<br />
<br />
: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.<br />
<br />
=== Captive portal auto-login support ===<br />
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".<br />
<br />
=== WiFi Walkie Talkie ===<br />
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
== Wireless Piggyback ==<br />
<br />
HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.<br />
<br />
== Other ==<br />
<br />
=== Auto Update ===<br />
<br />
A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .<br />
<br />
=== Vibrate Pattern Recorder ===<br />
<br />
An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).<br />
<br />
One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.<br />
<br />
- or just use MIDI, using a separate channel for the vibrator.<br />
<br />
An implementation of RTTL could also be used to define vibration patterns.<br />
<br />
=== PC Input Device ===<br />
<br />
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.<br />
<br />
Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.<br />
<br />
Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.<br />
<br />
=== Advanced Notification And Ringtone Manager ===<br />
{{Main|Wishlist-ANARM}}<br />
<br />
ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.<br />
<br />
=== Location based reminders ===<br />
{{Main|Wishlist:Location_based_reminders}}<br />
Location based reminders can be used to notify users of various events or reminders that are location based.<br />
<br />
=== Synergy Client ===<br />
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]<br />
<br />
=== Next device ===<br />
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)<br />
<br />
==== There is no device ====<br />
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:<br />
<br />
Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.<br />
<br />
I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...<br />
<br />
(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)<br />
<br />
Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?<br />
<br />
Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...<br />
<br />
A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]<br />
<br />
== GPS Software ==<br />
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]<br />
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features<br />
** Overlay of satellite images with existing streetmaps<br />
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)<br />
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )<br />
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.<br />
* "Geomark" function: if you have to save the current time with your current location, only hit one button...<br />
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...<br />
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''<br />
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.<br />
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes<br />
<br />
<br>[[Community Based Traffic Information]]<br />
<br />
== Hardware ==<br />
{{Main|Wish List - Hardware}}<br />
<br />
It could be use for beepway Online service too <br />
[http://www.beepway.com]<br />
<br />
=== Dedicated Power / Charger Pinout ===<br />
<br />
Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.<br />
<br />
Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.<br />
<br />
The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.<br />
<br />
This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now". <br />
<br />
I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).<br />
<br />
=== Inductive charging ===<br />
<br />
[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.<br />
<br />
=== Tactile feedback via buzzer ===<br />
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.<br />
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)<br />
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)<br />
<br />
=== Detachable keyboard ===<br />
Hardware keyboard that can be attached with magnets to a future version of the Neo.<br />
<br />
A bluetooth mini-qwerty keyboard that straps to my wrist!<br />
<br />
: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]<br />
<br />
=== SD Card Slot ===<br />
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]<br />
<br />
SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:<br />
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.<br />
* Enable '''storage''' of:<br />
** podcasts, full-length movies, or large photo collections<br />
** photo and video from an on-board high-res camera<br />
** entire email database at your fingertips, even in poor phone signal areas<br />
** more detailed maps and charts<br />
** encrypted work databases that are not available online<br />
* Have easy '''external access''', without requiring battery removal like the microSD card<br />
* Support '''SDIO''' accessories<br />
* Enable '''transfer''' of data from an external camera's full SD memory to:<br />
** a portable USB hard drive, offsetting the need to travel with a notebook PC<br />
** the internet, via wifi or phone network<br />
* Enable editing of videos and photos obtained from external cameras<br />
<br />
Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?<br />
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)<br />
<br />
: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)<br />
<br />
: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.<br />
<br />
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)<br />
<br />
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)<br />
<br />
[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.<br />
<br />
: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.<br />
<br />
: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]<br />
<br />
: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)<br />
<br />
: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)<br />
<br />
=== IR port ===<br />
Remote control applications<br />
<br />
Would be great to use openmoko as a Harmony remote controller.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/Wish_ListWish List2008-05-12T17:36:18Z<p>Lally: /* My Account */</p>
<hr />
<div>This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].<br />
<br />
== Development ==<br />
=== Painless SDK installation & Setup ===<br />
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]<br />
<br />
* one command for installation (apt-get install openmoko)<br />
* one command to start Xnest (openmoko-xephyr?)<br />
* one command to start an i386 shell (openmoko-386-shell)<br />
* one command to start an armel shell (openmoko-armel-shell)<br />
<br />
No extra configuration required.<br />
<br />
==== IDE Plugins ====<br />
People like to see plugins for<br />
* [http://anjuta.sourceforge.net Anjuta]<br />
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].<br />
* [http://www.netbeans.org NetBeans]<br />
* Game engine - Game Creation plugins<br />
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]<br />
* [http://www.kdevelop.org KDevelop]<br />
* [http://developer.apple.com/tools/xcode/ XCode]<br />
* [http://www.monodevelop.com MonoDevelop]<br />
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]<br />
<br />
==== UI Designer ====<br />
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]<br />
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?<br />
<br />
<br />
==== Built-in Scripting Language ====<br />
{{Main|Wishlist:BuiltInScriptingLanguage}}<br />
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.<br />
==== Easy build of the existing autotools - based packages ====<br />
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.<br />
<br />
===Foreign Widget Set Bindings ===<br />
==== Qt Integration ====<br />
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.<br />
<br />
==== Maemo Integration ====<br />
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.<br />
<br />
==== wxWidgets Integration ====<br />
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.<br />
<br />
wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]<br />
<br />
==== SDL Integration ====<br />
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.<br />
<br />
==== Cocoa / GNUstep ====<br />
Allows to use MacOS X as a development platform.<br />
<br />
=== Software: Language bindings ===<br />
==== Python bindings ====<br />
Python bindings seem to be a commonly requested feature. <br />
<br />
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."<br />
<br />
==== C++ bindings ====<br />
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.<br />
<br />
==== Ruby bindings ====<br />
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)<br />
<br />
==== Java bindings ====<br />
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported. <br />
==== Other bindings ====<br />
* Perl<br />
* C#<br />
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings<br />
<br />
== Community Support ==<br />
<br />
=== [http://projects.openmoko.org projects.openmoko.org] ===<br />
Infrastructure for developers with<br />
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)<br />
* One mailing list for project<br />
<br />
== Platform ==<br />
=== Community Images ===<br />
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.<br />
<br />
=== Wishlist voting ===<br />
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.<br />
<br />
Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]<br />
<br />
== Software: Additional features ==<br />
<br />
===PDA Mode===<br />
<br />
There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.<br />
<br />
===Driving Mode===<br />
<br />
It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones<br />
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.<br />
<br />
===Calling===<br />
<br />
==== Mask ID based on dialed numbers ====<br />
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.<br />
<br />
==== Use calling cards and similar routing techniques for lower-cost calling ====<br />
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.<br />
<br />
==== Outgoing black/white lists ====<br />
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.<br />
<br />
Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.<br />
<br />
==== Time-based blocking/unblocking of calls ====<br />
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.<br />
<br />
====Speaker-phone====<br />
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.<br />
<br />
====Advanced Airtime Tracking====<br />
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.<br />
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.<br />
<br />
* Call duration should consider billing increments and show the durations according to accounting period<br />
<br />
<br />
<br />
==== Anti-stutter software ====<br />
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.<br />
<br />
====Minimize In-Call mode (check address book while in call)====<br />
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.<br />
<br />
Similar request when using the browser (lookup passwords, todo list, etc).<br />
<br />
====Hold Music (Ringback Tone)====<br />
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.<br />
This can partially be implemented on the phone.<br />
Issues are:<br />
*In countries where callers pay, this will make you unpopular.<br />
*In countries where the called party pays, it will use your minutes, or cost you money.<br />
**A list of people to activate this function for would alleviate this.<br />
*[[GPRS]] internet connection will stall while the hold music is being played.<br />
*Extra battery used when playing music.<br />
<br />
Also see [[Answering Machine]].<br />
<br />
====Play sound clips over the air====<br />
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104<br />
The buttons can have default sounds, but also have the ability to be customized.<br />
<br />
It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.<br />
<br />
==== DTMF Landline Dialing ====<br />
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.<br />
<br />
Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.<br />
<br />
For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.<br />
<br />
==== Conversation Recorder ====<br />
<br />
An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.<br />
<br />
====Unlicensed Mobile Access (UMA)====<br />
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.<br />
<br />
This can be combined with a GPS map to show where local free hubs are.<br />
<br />
==== Ignore-Call Button ====<br />
{{Main|Wishlist:Ignore Call Button}}<br />
<br />
Shut up a ringing phone, without accepting or rejecting the call.<br />
<br />
Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises. <br />
<br />
A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.<br />
<br />
The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).<br />
<br />
==== Voice Mailbox ====<br />
{{Main|Voice Mailbox}}<br />
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.<br />
Can act profile-dependent.<br />
<br />
==== Hold Button ====<br />
<br />
Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.<br />
<br />
==== Unanswered Call, Fast Call ====<br />
<br />
In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.<br />
Then the user of the mobile phone calls the other user(using the CallerID recognition).<br />
<br />
===Audio===<br />
<br />
==== Ambient Noise Detection ====<br />
{{Main|Wishlist:Software:Ambient Noise Detection}}<br />
<br />
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.<br />
<br />
If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.<br />
<br />
Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.<br />
<br />
==== Active noise control ====<br />
<br />
Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.<br />
<br />
==== Hear Impaired Mode ====<br />
<br />
Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).<br />
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.<br />
<br />
Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.<br />
<br />
==== Mute Button ====<br />
<br />
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.<br />
<br />
<br />
===Web Browser===<br />
<br />
==== Full-page Zoom Support ====<br />
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.<br />
<br />
The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.<br />
<br />
* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.<br />
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.<br />
* If this is not practical, Minimo with full-page-zoom ability is good.<br />
<br />
==== Plugins Support ====<br />
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].<br />
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.<br />
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.<br />
<br />
==== Widget support ====<br />
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)<br />
<br />
There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.<br />
<br />
===Media===<br />
====Music/Video Software====<br />
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular. <br />
<br />
Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.<br />
<br />
It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!<br />
<br />
- Possible copyright issues sharing music files?<br />
<br />
Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.<br />
<br />
==== Reading Support ====<br />
It would be really great to be able to read :<br />
<br />
*PDF<br />
*Open Document files<br />
*Text / RTF files<br />
*fb2 files (fbreader)<br />
*MS Office files<br />
*Aportis Doc (pdb)<br />
*DjVu<br />
*...<br />
<br />
In both landscape and portrait<br />
<br />
==== Wikipedia Mirror ====<br />
{{Main|Wishlist:Wikipedia_Mirror}}<br />
<br />
==== Blog ScribblePad ====<br />
<br />
Draw an image (and maybe add some text), then post to your blog.<br />
<br />
==== E-Book Reader ====<br />
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.<br />
<br />
==== Personal Wiki ====<br />
{{Main|Wishlist:PersonalWiki}}<br />
<br />
Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].<br />
<br />
[http://www.didiwiki.org/ Didiwiki]<br />
<br />
<br />
==== Dictionary, thesaurus, translator and flashcards ====<br />
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.<br />
<br />
'''Dictionary'''<br />
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:<br />
<br />
advantages:<br />
* small<br />
* very efficient + useful<br />
* only limited to really needed functions<br />
<br />
Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)<br />
<br />
==== Flickr uploader ====<br />
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.<br />
<br />
===PIM (Personal Information Managment)===<br />
====Context Sensitivity====<br />
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?<br />
<br />
==== Notes ====<br />
<br />
Something for taking notes would be a nice feature:<br />
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.<br />
<br />
Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].<br />
<br />
==== Calendar ====<br />
<br />
A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.<br />
The tool should have a reminder feature and other features like other mobile phones already have.<br />
<br />
I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)<br />
<br />
* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)<br />
<br />
==== Address Book ====<br />
<br />
* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP<br />
servers or whatever.<br />
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.<br />
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done<br />
by integrating with whatever on-phone GPS mapping software the Neo ends up using.<br />
* Random text input 'notes' about a contact<br />
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's<br />
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant<br />
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account<br />
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.<br />
* Support for:<br />
**[http://en.wikipedia.org/wiki/SyncML SyncML]<br />
**[http://abook.sourceforge.net/ abook] a text-based addressbook program<br />
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book<br />
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).<br />
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.<br />
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).<br />
<br />
==== Database/List Display/Edit ====<br />
{{Main|Wishlist:PilotDB}}<br />
<br />
One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.<br />
<br />
==== To-Do lists ====<br />
<br />
* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.<br />
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.<br />
<br />
<br />
==== Context based To-Do list ====<br />
{{Main|Wishlist:context based to-do list}}<br />
<br />
If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.<br />
<br />
==== Workout ====<br />
<br />
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.<br />
<br />
==== Shopping List ====<br />
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.<br />
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.<br />
<br />
==== [[Fuel Log]] ====<br />
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).<br />
Advanced features could include:<br />
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)<br />
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)<br />
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)<br />
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server<br />
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.<br />
<br />
==== Keep in touch reminder ====<br />
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.<br />
<br />
<br />
==== Menstruation period timer ====<br />
Fill in statistics and compute probabilities for menstruation, fertility, mood.<br />
See http://www.getjar.com/products/48/MyGirls<br />
<br />
==== Tagging ====<br />
{{Main|Wishlist:Tagging}}<br />
Tags can be used by various applications. Requirement is interoperability for further enhancement.<br />
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.<br />
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.<br />
<br />
<br />
<br />
==== Exchange Integration ====<br />
<br />
Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.<br />
<br />
* Is the time right to name names ? Add as your liking...<br />
** Plugin/integration to & from Kontact<br />
** Same with Evolution - Thunderbird - Seamonkey<br />
** ?? Google Calendars ?? (this one is tough)<br />
** Ms Exchange<br />
<br />
==== An electronic wallet ====<br />
<br />
A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).<br />
<br />
Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]<br />
<br />
==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====<br />
<br />
Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.<br />
<br />
Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.<br />
<br />
PROS: <br />
*genuine saving in time for social and business situations<br />
<br />
CONS: <br />
*I am sure there are some security hassles to be pondered....<br />
*not going to be used every day... definitely not an immediate priority.....<br />
*only at geek conferences will all have a neo....<br />
<br />
==== SMS Counter ====<br />
<br />
An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.<br />
<br />
==== Data Storage ====<br />
<br />
Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.<br />
Make this list available through the address book.<br />
This would be great for people who are switching between one or more communication channels frequently<br />
<br />
===Profiles===<br />
{{Main|Wishlist:Profiles}}<br />
<br />
The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.<br />
And how to automatically switch between them.<br />
<br />
===Text Messaging===<br />
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included<br />
For current development status of the messaging-app see: [[Messages]].<br />
<br />
There are many useful options that now can be used to full capacity:<br />
<br />
* '''Instant Messaging'''<br />
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net<br />
<br />
* '''Acknowledge/status SMS'''<br />
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.<br />
<br />
** '''Special handling of status-SMS''' <br />
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.<br />
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date<br />
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See: <br />
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]<br />
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)<br />
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung<br />
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/<br />
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.<br />
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.<br />
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])<br />
** Implement a script that abbreviates :-)<br />
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.<br />
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).<br />
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel<br />
* '''Searching''' allow full-text search or string search.<br />
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...<br />
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.<br />
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.<br />
* '''SMS-EMail-Gateway'''<br />
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS<br />
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).<br />
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it<br />
** By standard carrier SMS - cost 10cents<br />
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE<br />
** By email/Wifi - cost FREE<br />
** By email/GPRS - cost ?<br />
** Too many options!!!<br />
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.<br />
<br />
=== Text input ===<br />
{{Main|Wishlist:Text Input}}<br />
There are many good suggestions for text input on the specific text input ideas page.<br />
<br />
=== More/Custom Input Method Widgets ===<br />
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}<br />
Additional and customizable Input Method Widgets (similar to virtual keyboard). <br />
This could add soft-key functionality to games or other applications such as:<br />
*D-Pads<br />
*buttons<br />
*virtual trackballs<br />
*...<br />
Personalized layouts could be associated with each application.<br />
<br />
=== Games ===<br />
{{Main|Wishlist:Games}}<br />
<br />
=== Mesh Networking ===<br />
{{Main|Wishlist:Mesh Networking}}<br />
<br />
=== Printing Support ===<br />
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:<br />
<br />
* Notes<br />
* Maps<br />
* Email<br />
* Calendars<br />
* ...<br />
<br />
Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on<br />
<br />
# GTK+'s printing support<br />
# Making cups run on a really small system<br />
<br />
{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}<br />
<br />
There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.<br />
<br />
Further details:<br />
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]<br />
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]<br />
* [http://www.j5live.com/?p=204 j5live.com]<br />
<br />
===Misc Software===<br />
====Clocks/timers/Activity meters====<br />
===== Sport tracker =====<br />
{{Main|Wishlist:Sport_tracker}}<br />
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.<br />
<br />
===== Standby clock =====<br />
{{Main|Wishlist:Standby_clock}}<br />
A quick way to see what time it is.<br />
<br />
===== Egg Timer =====<br />
{{Main|Wishlist:EggTimer}}<br />
<br />
Very simple (one click) count up / count down timers are very useful.<br />
<br />
===== Cycle Computer =====<br />
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.<br />
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)<br />
<br />
===== NTP Server =====<br />
<br />
Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices. <br />
<br />
I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.<br />
<br />
<br />
===== Find Keys/locate stuff =====<br />
<br />
This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.<br />
<br />
A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you. <br />
<br />
Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.<br />
<br />
For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].<br />
<br />
===== Reality check reminder =====<br />
{{Main|Wishlist:Reality check reminder}}<br />
<br />
A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]<br />
<br />
===== Automatic timezone changing (GPS) =====<br />
<br />
Check the timezone with GPS and adapt them.<br />
<br />
====Calculators====<br />
===== A Universal Unit Converter Tool =====<br />
<br />
One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers. <br />
<br />
Ideas what kind of conversions a converter tool could do:<br />
<br />
Length<br />
- Acceleration<br />
- Angle<br />
- Angular Velocity<br />
- Area<br />
- Capacitance<br />
- Radioactivity<br />
- Currency <br />
- Charge<br />
- Computer Memory<br />
- Conductance<br />
- Density<br />
- Energy<br />
- Illumination<br />
- Power<br />
- Force <br />
- Flow<br />
- Pressure<br />
- Speed<br />
- Temperature<br />
- Time<br />
- Torque<br />
- Viscosity<br />
- Volume<br />
- Weight<br />
<br />
Roman Numerals<br />
- ASCII, Hex<br />
- Cooking<br />
- BMI<br />
- Clothing Sizes<br />
<br />
Money Converter based on current rates from Internet...<br />
e. g. Dollar <-> Euro<br />
<br />
Physical and Mathematical Constants<br />
GPS conversions <br />
<br />
- link to or integration of a scientific calculator<br />
- link to or integration of a simple calculator<br />
<br />
A good basis for such a converter tool could be the Palm program "units" from <br />
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.<br />
<br />
For GPS conversions see gpsbabel [http://www.gpsbabel.org]<br />
<br />
===== An Postfix Notation (RPN) calculator =====<br />
<br />
Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.<br />
<br />
==== Windows CE Emulator ====<br />
<br />
On ARM machine, Windows CE API emulator, like Wine on x86 machines. <br />
<br />
==== PalmOS Emulator ====<br />
<br />
The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.<br />
<br />
I'd like to see a Windows CE Emulator with active sync support.<br />
<br />
==== Chumby Emulator ====<br />
<br />
Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.<br />
<br />
==== TV Guide ====<br />
Display a TV guide using [http://xmltv.org xmltv].<br />
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)<br />
<br />
==== Alcohol meter ====<br />
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.<br />
See, for example (German text) http://www.misterio-online.de/promille.htm<br />
<br />
==== Interaction with LEGO Mindstorm ====<br />
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.<br />
<br />
==== Flashlight ====<br />
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!<br />
<br />
==== Wii Controller Emulator ====<br />
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.<br />
<br />
==== FUSE support ====<br />
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)<br />
<br />
=== Accessibility ===<br />
Accessibility features for the visually impaired.<br />
* High Contrast Themes.<br />
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.<br />
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]<br />
<br />
==== VOIP ====<br />
* [[Dialer]] should be able to use SIP.<br />
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.<br />
* A standard SIP client would probably fit better into the "free and open" philosophy.<br />
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.<br />
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)<br />
<br />
''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''<br />
<br />
Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.<br />
Edw/<br />
<br />
==== Power Meter ====<br />
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.<br />
<br />
Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?<br />
<br />
=== Accelerometer wishes ===<br />
==== Flick interface ====<br />
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.<br />
<br />
Sensitivity of the scrolling should be configurable and a test option provided.<br />
<br />
==== Reading navigation of documents enhanced by accelerometers ====<br />
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.<br />
<br />
I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)<br />
<br />
==== Wand UI ====<br />
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.<br />
==== Panning interface ====<br />
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.<br />
<br />
In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.<br />
<br />
When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.<br />
<br />
==== Shake-to-Wake ====<br />
Giving the phone a shake enables voice commands for a few seconds.<br />
Usage Examples: <br />
<br />
* {Shake} "Call" ''ContactName'' ''PhoneType''<br />
* {Shake} "Call John Mobile" (Calls John's mobile)<br />
* {Shake} ''ApplicationName''<br />
* {Shake} "Reader" (Opens the e-book application)<br />
<br />
Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)<br />
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)<br />
<br />
I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.<br />
<br />
==== Emergency call ====<br />
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.<br />
<br />
A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).<br />
<br />
:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)<br />
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)<br />
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]<br />
<br />
==== Movement detection ====<br />
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.<br />
<br />
==== Games ====<br />
Imagine a first person shooter that you look around by turning your body.<br />
<br />
==== Sloshing battery indicator ====<br />
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.<br />
==== Steady screen ====<br />
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.<br />
* being mounted inside a vehicle<br />
* during certain sports<br />
* while the internal vibrator is activated (perhaps)<br />
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.<br />
<br />
At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements. <br />
<br />
Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.<br />
<br />
In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.<br />
<br />
These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.<br />
<br />
==== Taping as input ====<br />
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.<br />
<br />
==== Others ====<br />
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].<br />
<br />
=== Connectivity ===<br />
<br />
==== VNC ====<br />
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.<br />
<br />
==== Networked X-Windows ====<br />
<br />
Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.<br />
<br />
==== NX client ====<br />
<br />
A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]<br />
<br />
==== OpenOffice Presenter Control ====<br />
<br />
I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.<br />
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.<br />
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse <br />
click than to fast than you must go back.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Amarok and other Media Player remote control ====<br />
<br />
Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.<br />
<br />
==== Read informations with SMS ====<br />
Send a SMS with Code to the OpenMoko (from a specific number).<br />
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).<br />
<br />
=== Security ===<br />
<br />
==== General Filesystem Encryption ====<br />
<br />
If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed. <br />
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).<br />
<br />
http://luks.endorphin.org<br />
<br />
==== My Account ====<br />
{{Main|My Account}}<br />
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.<br />
<br />
Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.<br />
<br />
==== [http://zfoneproject.com/ Zfone] or similar ====<br />
<br />
Something that allows the user to speak with another person securely.<br />
<br />
==== GSM Encryption ====<br />
<br />
This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel. <br />
<br />
[[OSvS]]<br />
<br />
==== My Voice is my Passport ====<br />
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."<br />
<br />
==== Firewall ====<br />
A network firewall<br />
<br />
==== Full Mac Support ====<br />
Full mac support, preferably with full software and full sync capabilities with iCal and iMail <br />
<br />
==== Anti Theft Application ====<br />
<br />
This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.<br />
<br />
====RFID based personal alerts====<br />
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.<br />
<br />
Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.<br />
<br />
====OpenVPN Client====<br />
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.<br />
<br />
=== Integrated Help System ===<br />
<br />
A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.<br />
<br />
===Performance optimisation===<br />
==== Use DMA engine in CPU for blitter ====<br />
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.<br />
<br />
==== Use virtual screen to optimise scrolling ====<br />
In some other cases, the hardware supported virtual screen may also speed it up.<br />
===Reusable Display/UI Widgets===<br />
====Use BigPage for full page zoom, scroll, scale in many apps====<br />
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen<br />
<br />
==Bluetooth==<br />
<br />
=== Voice Dialing ===<br />
<br />
Dial by voice commands.<br />
<br>Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.<br />
<br />
=== Music through Bluetooth Headset ===<br />
<br />
Music can be played through a Bluetooth headset, but would stop playing when a call comes in.<br />
<br />
=== Walkie Talkie ===<br />
<br />
Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.<br />
<br />
Features for this applications can be:<br />
* Push To Talk (PTT) button<br />
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.<br />
* Optionally a full duplex mode<br />
* Different channels to choose from<br />
* Monitor different (preselected or all) channels for traffic.<br />
* Content encryption<br />
* Active noise control<br />
* Allow zero config use (units can talk without any access point helping)<br />
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel<br />
<br />
Local (non-GPRS) use cases include chatting while biking<br />
or motorcycling in a group; perhaps also in a car caravan.<br />
This application could also be used as a baby-phone to monitor your siblings.<br />
<br />
This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.<br />
<br />
(One thumbs up from me) Jackcday<br />
<br />
See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
=== Automatic Sync ===<br />
<br />
Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.<br />
<br />
=== GPS Assisted Bluetooth Management ===<br />
<br />
Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.<br />
<br />
A Bluetooth device is configured for automatic reacquisition based on the following profiles:<br />
* Manual - only when Bluetooth is on<br />
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.<br />
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.<br />
<br />
Each target device is configured as follows:<br />
* Automatic acquisition at last known location: enable/disable<br />
* Automatic acquisition at these locations: list of nickname + coordinates + range<br />
<br />
==== Non-mobile devices ====<br />
<br />
Examples devices include: computers<br />
<br />
The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.<br />
<br />
Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.<br />
<br />
==== Mobile devices ====<br />
<br />
Example devices include: automobiles<br />
<br />
Mobile devices are configured to have two types of locations:<br />
# Last known location<br />
# Non-mobile locations (homes)<br />
<br />
===== Last known location =====<br />
<br />
A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.<br />
<br />
===== Non-mobile locations (homes) =====<br />
<br />
As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.<br />
<br />
=== Bluetooth neighbor detection and multiuser apps ===<br />
<br />
Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.<br />
<br />
=== Bluetooth environment detection ===<br />
<br />
Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.<br />
<br />
=== Remote control ===<br />
<br />
==== Wireless presenter ====<br />
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features: <br />
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.<br />
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point<br />
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature). <br />
* If you want to be super-cool, you give a preview of the notes of the next slide in the show. <br />
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.<br />
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Initiated from another device ====<br />
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.<br />
==== Directed at another device ====<br />
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.<br />
<br />
[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)<br />
<br />
Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]<br />
<br />
=== Bluetooth Car Connection ===<br />
<br />
Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.<br />
<br />
Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]<br />
<br />
==== Dude, Where's My Car? ====<br />
<br />
When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.<br />
<br />
=== [[Bluetooth powered Multi-SIM support]] ===<br />
<br />
As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.<br />
<br />
Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:<br />
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)<br />
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset<br />
* Same for Short Messages/MMS/Internet<br />
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.<br />
Advantage: No 'switching' between cards<br />
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.<br />
<br />
===Internet Gateway===<br />
<br />
If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.<br />
<br />
=== Social Networking ===<br />
<br />
Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.<br />
<br />
=== Give userspace api control over bluetooth signal strength ===<br />
<br />
I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.<br />
<br />
<br />
== WiFi ==<br />
<br />
=== Industrial grade Wifi management ===<br />
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.<br />
<br />
: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.<br />
<br />
=== Captive portal auto-login support ===<br />
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".<br />
<br />
=== WiFi Walkie Talkie ===<br />
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
== Wireless Piggyback ==<br />
<br />
HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.<br />
<br />
== Other ==<br />
<br />
=== Auto Update ===<br />
<br />
A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .<br />
<br />
=== Vibrate Pattern Recorder ===<br />
<br />
An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).<br />
<br />
One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.<br />
<br />
- or just use MIDI, using a separate channel for the vibrator.<br />
<br />
An implementation of RTTL could also be used to define vibration patterns.<br />
<br />
=== PC Input Device ===<br />
<br />
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.<br />
<br />
Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.<br />
<br />
Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.<br />
<br />
=== Advanced Notification And Ringtone Manager ===<br />
{{Main|Wishlist-ANARM}}<br />
<br />
ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.<br />
<br />
=== Location based reminders ===<br />
{{Main|Wishlist:Location_based_reminders}}<br />
Location based reminders can be used to notify users of various events or reminders that are location based.<br />
<br />
=== Synergy Client ===<br />
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]<br />
<br />
=== Next device ===<br />
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)<br />
<br />
==== There is no device ====<br />
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:<br />
<br />
Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.<br />
<br />
I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...<br />
<br />
(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)<br />
<br />
Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?<br />
<br />
Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...<br />
<br />
A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]<br />
<br />
== GPS Software ==<br />
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]<br />
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features<br />
** Overlay of satellite images with existing streetmaps<br />
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)<br />
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )<br />
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.<br />
* "Geomark" function: if you have to save the current time with your current location, only hit one button...<br />
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...<br />
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''<br />
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.<br />
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes<br />
<br />
<br>[[Community Based Traffic Information]]<br />
<br />
== Hardware ==<br />
{{Main|Wish List - Hardware}}<br />
<br />
It could be use for beepway Online service too <br />
[http://www.beepway.com]<br />
<br />
=== Dedicated Power / Charger Pinout ===<br />
<br />
Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.<br />
<br />
Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.<br />
<br />
The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.<br />
<br />
This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now". <br />
<br />
I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).<br />
<br />
=== Inductive charging ===<br />
<br />
[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.<br />
<br />
=== Tactile feedback via buzzer ===<br />
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.<br />
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)<br />
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)<br />
<br />
=== Detachable keyboard ===<br />
Hardware keyboard that can be attached with magnets to a future version of the Neo.<br />
<br />
A bluetooth mini-qwerty keyboard that straps to my wrist!<br />
<br />
: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]<br />
<br />
=== SD Card Slot ===<br />
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]<br />
<br />
SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:<br />
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.<br />
* Enable '''storage''' of:<br />
** podcasts, full-length movies, or large photo collections<br />
** photo and video from an on-board high-res camera<br />
** entire email database at your fingertips, even in poor phone signal areas<br />
** more detailed maps and charts<br />
** encrypted work databases that are not available online<br />
* Have easy '''external access''', without requiring battery removal like the microSD card<br />
* Support '''SDIO''' accessories<br />
* Enable '''transfer''' of data from an external camera's full SD memory to:<br />
** a portable USB hard drive, offsetting the need to travel with a notebook PC<br />
** the internet, via wifi or phone network<br />
* Enable editing of videos and photos obtained from external cameras<br />
<br />
Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?<br />
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)<br />
<br />
: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)<br />
<br />
: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.<br />
<br />
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)<br />
<br />
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)<br />
<br />
[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.<br />
<br />
: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.<br />
<br />
: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]<br />
<br />
: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)<br />
<br />
: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)<br />
<br />
=== IR port ===<br />
Remote control applications<br />
<br />
Would be great to use openmoko as a Harmony remote controller.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/Wish_ListWish List2008-05-12T17:33:31Z<p>Lally: /* Next device */</p>
<hr />
<div>This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].<br />
<br />
== Development ==<br />
=== Painless SDK installation & Setup ===<br />
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]<br />
<br />
* one command for installation (apt-get install openmoko)<br />
* one command to start Xnest (openmoko-xephyr?)<br />
* one command to start an i386 shell (openmoko-386-shell)<br />
* one command to start an armel shell (openmoko-armel-shell)<br />
<br />
No extra configuration required.<br />
<br />
==== IDE Plugins ====<br />
People like to see plugins for<br />
* [http://anjuta.sourceforge.net Anjuta]<br />
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].<br />
* [http://www.netbeans.org NetBeans]<br />
* Game engine - Game Creation plugins<br />
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]<br />
* [http://www.kdevelop.org KDevelop]<br />
* [http://developer.apple.com/tools/xcode/ XCode]<br />
* [http://www.monodevelop.com MonoDevelop]<br />
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]<br />
<br />
==== UI Designer ====<br />
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]<br />
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?<br />
<br />
<br />
==== Built-in Scripting Language ====<br />
{{Main|Wishlist:BuiltInScriptingLanguage}}<br />
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.<br />
==== Easy build of the existing autotools - based packages ====<br />
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.<br />
<br />
===Foreign Widget Set Bindings ===<br />
==== Qt Integration ====<br />
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.<br />
<br />
==== Maemo Integration ====<br />
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.<br />
<br />
==== wxWidgets Integration ====<br />
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.<br />
<br />
wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]<br />
<br />
==== SDL Integration ====<br />
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.<br />
<br />
==== Cocoa / GNUstep ====<br />
Allows to use MacOS X as a development platform.<br />
<br />
=== Software: Language bindings ===<br />
==== Python bindings ====<br />
Python bindings seem to be a commonly requested feature. <br />
<br />
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."<br />
<br />
==== C++ bindings ====<br />
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.<br />
<br />
==== Ruby bindings ====<br />
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)<br />
<br />
==== Java bindings ====<br />
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported. <br />
==== Other bindings ====<br />
* Perl<br />
* C#<br />
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings<br />
<br />
== Community Support ==<br />
<br />
=== [http://projects.openmoko.org projects.openmoko.org] ===<br />
Infrastructure for developers with<br />
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)<br />
* One mailing list for project<br />
<br />
== Platform ==<br />
=== Community Images ===<br />
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.<br />
<br />
=== Wishlist voting ===<br />
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.<br />
<br />
Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]<br />
<br />
== Software: Additional features ==<br />
<br />
===PDA Mode===<br />
<br />
There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.<br />
<br />
===Driving Mode===<br />
<br />
It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones<br />
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.<br />
<br />
===Calling===<br />
<br />
==== Mask ID based on dialed numbers ====<br />
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.<br />
<br />
==== Use calling cards and similar routing techniques for lower-cost calling ====<br />
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.<br />
<br />
==== Outgoing black/white lists ====<br />
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.<br />
<br />
Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.<br />
<br />
==== Time-based blocking/unblocking of calls ====<br />
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.<br />
<br />
====Speaker-phone====<br />
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.<br />
<br />
====Advanced Airtime Tracking====<br />
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.<br />
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.<br />
<br />
* Call duration should consider billing increments and show the durations according to accounting period<br />
<br />
<br />
<br />
==== Anti-stutter software ====<br />
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.<br />
<br />
====Minimize In-Call mode (check address book while in call)====<br />
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.<br />
<br />
Similar request when using the browser (lookup passwords, todo list, etc).<br />
<br />
====Hold Music (Ringback Tone)====<br />
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.<br />
This can partially be implemented on the phone.<br />
Issues are:<br />
*In countries where callers pay, this will make you unpopular.<br />
*In countries where the called party pays, it will use your minutes, or cost you money.<br />
**A list of people to activate this function for would alleviate this.<br />
*[[GPRS]] internet connection will stall while the hold music is being played.<br />
*Extra battery used when playing music.<br />
<br />
Also see [[Answering Machine]].<br />
<br />
====Play sound clips over the air====<br />
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104<br />
The buttons can have default sounds, but also have the ability to be customized.<br />
<br />
It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.<br />
<br />
==== DTMF Landline Dialing ====<br />
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.<br />
<br />
Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.<br />
<br />
For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.<br />
<br />
==== Conversation Recorder ====<br />
<br />
An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.<br />
<br />
====Unlicensed Mobile Access (UMA)====<br />
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.<br />
<br />
This can be combined with a GPS map to show where local free hubs are.<br />
<br />
==== Ignore-Call Button ====<br />
{{Main|Wishlist:Ignore Call Button}}<br />
<br />
Shut up a ringing phone, without accepting or rejecting the call.<br />
<br />
Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises. <br />
<br />
A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.<br />
<br />
The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).<br />
<br />
==== Voice Mailbox ====<br />
{{Main|Voice Mailbox}}<br />
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.<br />
Can act profile-dependent.<br />
<br />
==== Hold Button ====<br />
<br />
Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.<br />
<br />
==== Unanswered Call, Fast Call ====<br />
<br />
In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.<br />
Then the user of the mobile phone calls the other user(using the CallerID recognition).<br />
<br />
===Audio===<br />
<br />
==== Ambient Noise Detection ====<br />
{{Main|Wishlist:Software:Ambient Noise Detection}}<br />
<br />
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.<br />
<br />
If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.<br />
<br />
Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.<br />
<br />
==== Active noise control ====<br />
<br />
Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.<br />
<br />
==== Hear Impaired Mode ====<br />
<br />
Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).<br />
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.<br />
<br />
Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.<br />
<br />
==== Mute Button ====<br />
<br />
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.<br />
<br />
<br />
===Web Browser===<br />
<br />
==== Full-page Zoom Support ====<br />
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.<br />
<br />
The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.<br />
<br />
* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.<br />
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.<br />
* If this is not practical, Minimo with full-page-zoom ability is good.<br />
<br />
==== Plugins Support ====<br />
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].<br />
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.<br />
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.<br />
<br />
==== Widget support ====<br />
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)<br />
<br />
There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.<br />
<br />
===Media===<br />
====Music/Video Software====<br />
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular. <br />
<br />
Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.<br />
<br />
It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!<br />
<br />
- Possible copyright issues sharing music files?<br />
<br />
Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.<br />
<br />
==== Reading Support ====<br />
It would be really great to be able to read :<br />
<br />
*PDF<br />
*Open Document files<br />
*Text / RTF files<br />
*fb2 files (fbreader)<br />
*MS Office files<br />
*Aportis Doc (pdb)<br />
*DjVu<br />
*...<br />
<br />
In both landscape and portrait<br />
<br />
==== Wikipedia Mirror ====<br />
{{Main|Wishlist:Wikipedia_Mirror}}<br />
<br />
==== Blog ScribblePad ====<br />
<br />
Draw an image (and maybe add some text), then post to your blog.<br />
<br />
==== E-Book Reader ====<br />
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.<br />
<br />
==== Personal Wiki ====<br />
{{Main|Wishlist:PersonalWiki}}<br />
<br />
Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].<br />
<br />
[http://www.didiwiki.org/ Didiwiki]<br />
<br />
<br />
==== Dictionary, thesaurus, translator and flashcards ====<br />
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.<br />
<br />
'''Dictionary'''<br />
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:<br />
<br />
advantages:<br />
* small<br />
* very efficient + useful<br />
* only limited to really needed functions<br />
<br />
Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)<br />
<br />
==== Flickr uploader ====<br />
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.<br />
<br />
===PIM (Personal Information Managment)===<br />
====Context Sensitivity====<br />
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?<br />
<br />
==== Notes ====<br />
<br />
Something for taking notes would be a nice feature:<br />
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.<br />
<br />
Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].<br />
<br />
==== Calendar ====<br />
<br />
A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.<br />
The tool should have a reminder feature and other features like other mobile phones already have.<br />
<br />
I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)<br />
<br />
* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)<br />
<br />
==== Address Book ====<br />
<br />
* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP<br />
servers or whatever.<br />
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.<br />
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done<br />
by integrating with whatever on-phone GPS mapping software the Neo ends up using.<br />
* Random text input 'notes' about a contact<br />
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's<br />
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant<br />
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account<br />
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.<br />
* Support for:<br />
**[http://en.wikipedia.org/wiki/SyncML SyncML]<br />
**[http://abook.sourceforge.net/ abook] a text-based addressbook program<br />
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book<br />
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).<br />
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.<br />
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).<br />
<br />
==== Database/List Display/Edit ====<br />
{{Main|Wishlist:PilotDB}}<br />
<br />
One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.<br />
<br />
==== To-Do lists ====<br />
<br />
* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.<br />
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.<br />
<br />
<br />
==== Context based To-Do list ====<br />
{{Main|Wishlist:context based to-do list}}<br />
<br />
If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.<br />
<br />
==== Workout ====<br />
<br />
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.<br />
<br />
==== Shopping List ====<br />
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.<br />
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.<br />
<br />
==== [[Fuel Log]] ====<br />
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).<br />
Advanced features could include:<br />
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)<br />
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)<br />
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)<br />
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server<br />
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.<br />
<br />
==== Keep in touch reminder ====<br />
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.<br />
<br />
<br />
==== Menstruation period timer ====<br />
Fill in statistics and compute probabilities for menstruation, fertility, mood.<br />
See http://www.getjar.com/products/48/MyGirls<br />
<br />
==== Tagging ====<br />
{{Main|Wishlist:Tagging}}<br />
Tags can be used by various applications. Requirement is interoperability for further enhancement.<br />
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.<br />
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.<br />
<br />
<br />
<br />
==== Exchange Integration ====<br />
<br />
Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.<br />
<br />
* Is the time right to name names ? Add as your liking...<br />
** Plugin/integration to & from Kontact<br />
** Same with Evolution - Thunderbird - Seamonkey<br />
** ?? Google Calendars ?? (this one is tough)<br />
** Ms Exchange<br />
<br />
==== An electronic wallet ====<br />
<br />
A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).<br />
<br />
Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]<br />
<br />
==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====<br />
<br />
Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.<br />
<br />
Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.<br />
<br />
PROS: <br />
*genuine saving in time for social and business situations<br />
<br />
CONS: <br />
*I am sure there are some security hassles to be pondered....<br />
*not going to be used every day... definitely not an immediate priority.....<br />
*only at geek conferences will all have a neo....<br />
<br />
==== SMS Counter ====<br />
<br />
An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.<br />
<br />
==== Data Storage ====<br />
<br />
Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.<br />
Make this list available through the address book.<br />
This would be great for people who are switching between one or more communication channels frequently<br />
<br />
===Profiles===<br />
{{Main|Wishlist:Profiles}}<br />
<br />
The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.<br />
And how to automatically switch between them.<br />
<br />
===Text Messaging===<br />
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included<br />
For current development status of the messaging-app see: [[Messages]].<br />
<br />
There are many useful options that now can be used to full capacity:<br />
<br />
* '''Instant Messaging'''<br />
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net<br />
<br />
* '''Acknowledge/status SMS'''<br />
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.<br />
<br />
** '''Special handling of status-SMS''' <br />
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.<br />
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date<br />
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See: <br />
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]<br />
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)<br />
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung<br />
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/<br />
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.<br />
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.<br />
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])<br />
** Implement a script that abbreviates :-)<br />
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.<br />
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).<br />
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel<br />
* '''Searching''' allow full-text search or string search.<br />
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...<br />
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.<br />
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.<br />
* '''SMS-EMail-Gateway'''<br />
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS<br />
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).<br />
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it<br />
** By standard carrier SMS - cost 10cents<br />
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE<br />
** By email/Wifi - cost FREE<br />
** By email/GPRS - cost ?<br />
** Too many options!!!<br />
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.<br />
<br />
=== Text input ===<br />
{{Main|Wishlist:Text Input}}<br />
There are many good suggestions for text input on the specific text input ideas page.<br />
<br />
=== More/Custom Input Method Widgets ===<br />
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}<br />
Additional and customizable Input Method Widgets (similar to virtual keyboard). <br />
This could add soft-key functionality to games or other applications such as:<br />
*D-Pads<br />
*buttons<br />
*virtual trackballs<br />
*...<br />
Personalized layouts could be associated with each application.<br />
<br />
=== Games ===<br />
{{Main|Wishlist:Games}}<br />
<br />
=== Mesh Networking ===<br />
{{Main|Wishlist:Mesh Networking}}<br />
<br />
=== Printing Support ===<br />
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:<br />
<br />
* Notes<br />
* Maps<br />
* Email<br />
* Calendars<br />
* ...<br />
<br />
Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on<br />
<br />
# GTK+'s printing support<br />
# Making cups run on a really small system<br />
<br />
{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}<br />
<br />
There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.<br />
<br />
Further details:<br />
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]<br />
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]<br />
* [http://www.j5live.com/?p=204 j5live.com]<br />
<br />
===Misc Software===<br />
====Clocks/timers/Activity meters====<br />
===== Sport tracker =====<br />
{{Main|Wishlist:Sport_tracker}}<br />
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.<br />
<br />
===== Standby clock =====<br />
{{Main|Wishlist:Standby_clock}}<br />
A quick way to see what time it is.<br />
<br />
===== Egg Timer =====<br />
{{Main|Wishlist:EggTimer}}<br />
<br />
Very simple (one click) count up / count down timers are very useful.<br />
<br />
===== Cycle Computer =====<br />
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.<br />
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)<br />
<br />
===== NTP Server =====<br />
<br />
Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices. <br />
<br />
I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.<br />
<br />
<br />
===== Find Keys/locate stuff =====<br />
<br />
This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.<br />
<br />
A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you. <br />
<br />
Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.<br />
<br />
For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].<br />
<br />
===== Reality check reminder =====<br />
{{Main|Wishlist:Reality check reminder}}<br />
<br />
A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]<br />
<br />
===== Automatic timezone changing (GPS) =====<br />
<br />
Check the timezone with GPS and adapt them.<br />
<br />
====Calculators====<br />
===== A Universal Unit Converter Tool =====<br />
<br />
One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers. <br />
<br />
Ideas what kind of conversions a converter tool could do:<br />
<br />
Length<br />
- Acceleration<br />
- Angle<br />
- Angular Velocity<br />
- Area<br />
- Capacitance<br />
- Radioactivity<br />
- Currency <br />
- Charge<br />
- Computer Memory<br />
- Conductance<br />
- Density<br />
- Energy<br />
- Illumination<br />
- Power<br />
- Force <br />
- Flow<br />
- Pressure<br />
- Speed<br />
- Temperature<br />
- Time<br />
- Torque<br />
- Viscosity<br />
- Volume<br />
- Weight<br />
<br />
Roman Numerals<br />
- ASCII, Hex<br />
- Cooking<br />
- BMI<br />
- Clothing Sizes<br />
<br />
Money Converter based on current rates from Internet...<br />
e. g. Dollar <-> Euro<br />
<br />
Physical and Mathematical Constants<br />
GPS conversions <br />
<br />
- link to or integration of a scientific calculator<br />
- link to or integration of a simple calculator<br />
<br />
A good basis for such a converter tool could be the Palm program "units" from <br />
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.<br />
<br />
For GPS conversions see gpsbabel [http://www.gpsbabel.org]<br />
<br />
===== An Postfix Notation (RPN) calculator =====<br />
<br />
Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.<br />
<br />
==== Windows CE Emulator ====<br />
<br />
On ARM machine, Windows CE API emulator, like Wine on x86 machines. <br />
<br />
==== PalmOS Emulator ====<br />
<br />
The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.<br />
<br />
I'd like to see a Windows CE Emulator with active sync support.<br />
<br />
==== Chumby Emulator ====<br />
<br />
Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.<br />
<br />
==== TV Guide ====<br />
Display a TV guide using [http://xmltv.org xmltv].<br />
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)<br />
<br />
==== Alcohol meter ====<br />
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.<br />
See, for example (German text) http://www.misterio-online.de/promille.htm<br />
<br />
==== Interaction with LEGO Mindstorm ====<br />
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.<br />
<br />
==== Flashlight ====<br />
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!<br />
<br />
==== Wii Controller Emulator ====<br />
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.<br />
<br />
==== FUSE support ====<br />
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)<br />
<br />
=== Accessibility ===<br />
Accessibility features for the visually impaired.<br />
* High Contrast Themes.<br />
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.<br />
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]<br />
<br />
==== VOIP ====<br />
* [[Dialer]] should be able to use SIP.<br />
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.<br />
* A standard SIP client would probably fit better into the "free and open" philosophy.<br />
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.<br />
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)<br />
<br />
''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''<br />
<br />
Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.<br />
Edw/<br />
<br />
==== Power Meter ====<br />
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.<br />
<br />
Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?<br />
<br />
=== Accelerometer wishes ===<br />
==== Flick interface ====<br />
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.<br />
<br />
Sensitivity of the scrolling should be configurable and a test option provided.<br />
<br />
==== Reading navigation of documents enhanced by accelerometers ====<br />
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.<br />
<br />
I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)<br />
<br />
==== Wand UI ====<br />
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.<br />
==== Panning interface ====<br />
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.<br />
<br />
In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.<br />
<br />
When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.<br />
<br />
==== Shake-to-Wake ====<br />
Giving the phone a shake enables voice commands for a few seconds.<br />
Usage Examples: <br />
<br />
* {Shake} "Call" ''ContactName'' ''PhoneType''<br />
* {Shake} "Call John Mobile" (Calls John's mobile)<br />
* {Shake} ''ApplicationName''<br />
* {Shake} "Reader" (Opens the e-book application)<br />
<br />
Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)<br />
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)<br />
<br />
I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.<br />
<br />
==== Emergency call ====<br />
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.<br />
<br />
A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).<br />
<br />
:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)<br />
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)<br />
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]<br />
<br />
==== Movement detection ====<br />
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.<br />
<br />
==== Games ====<br />
Imagine a first person shooter that you look around by turning your body.<br />
<br />
==== Sloshing battery indicator ====<br />
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.<br />
==== Steady screen ====<br />
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.<br />
* being mounted inside a vehicle<br />
* during certain sports<br />
* while the internal vibrator is activated (perhaps)<br />
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.<br />
<br />
At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements. <br />
<br />
Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.<br />
<br />
In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.<br />
<br />
These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.<br />
<br />
==== Taping as input ====<br />
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.<br />
<br />
==== Others ====<br />
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].<br />
<br />
=== Connectivity ===<br />
<br />
==== VNC ====<br />
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.<br />
<br />
==== Networked X-Windows ====<br />
<br />
Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.<br />
<br />
==== NX client ====<br />
<br />
A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]<br />
<br />
==== OpenOffice Presenter Control ====<br />
<br />
I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.<br />
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.<br />
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse <br />
click than to fast than you must go back.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Amarok and other Media Player remote control ====<br />
<br />
Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.<br />
<br />
==== Read informations with SMS ====<br />
Send a SMS with Code to the OpenMoko (from a specific number).<br />
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).<br />
<br />
=== Security ===<br />
<br />
==== General Filesystem Encryption ====<br />
<br />
If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed. <br />
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).<br />
<br />
http://luks.endorphin.org<br />
<br />
==== My Account ====<br />
{{Main|My Account}}<br />
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.<br />
<br />
==== [http://zfoneproject.com/ Zfone] or similar ====<br />
<br />
Something that allows the user to speak with another person securely.<br />
<br />
==== GSM Encryption ====<br />
<br />
This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel. <br />
<br />
[[OSvS]]<br />
<br />
==== My Voice is my Passport ====<br />
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."<br />
<br />
==== Firewall ====<br />
A network firewall<br />
<br />
==== Full Mac Support ====<br />
Full mac support, preferably with full software and full sync capabilities with iCal and iMail <br />
<br />
==== Anti Theft Application ====<br />
<br />
This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.<br />
<br />
====RFID based personal alerts====<br />
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.<br />
<br />
Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.<br />
<br />
====OpenVPN Client====<br />
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.<br />
<br />
=== Integrated Help System ===<br />
<br />
A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.<br />
<br />
===Performance optimisation===<br />
==== Use DMA engine in CPU for blitter ====<br />
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.<br />
<br />
==== Use virtual screen to optimise scrolling ====<br />
In some other cases, the hardware supported virtual screen may also speed it up.<br />
===Reusable Display/UI Widgets===<br />
====Use BigPage for full page zoom, scroll, scale in many apps====<br />
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen<br />
<br />
==Bluetooth==<br />
<br />
=== Voice Dialing ===<br />
<br />
Dial by voice commands.<br />
<br>Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.<br />
<br />
=== Music through Bluetooth Headset ===<br />
<br />
Music can be played through a Bluetooth headset, but would stop playing when a call comes in.<br />
<br />
=== Walkie Talkie ===<br />
<br />
Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.<br />
<br />
Features for this applications can be:<br />
* Push To Talk (PTT) button<br />
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.<br />
* Optionally a full duplex mode<br />
* Different channels to choose from<br />
* Monitor different (preselected or all) channels for traffic.<br />
* Content encryption<br />
* Active noise control<br />
* Allow zero config use (units can talk without any access point helping)<br />
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel<br />
<br />
Local (non-GPRS) use cases include chatting while biking<br />
or motorcycling in a group; perhaps also in a car caravan.<br />
This application could also be used as a baby-phone to monitor your siblings.<br />
<br />
This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.<br />
<br />
(One thumbs up from me) Jackcday<br />
<br />
See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
=== Automatic Sync ===<br />
<br />
Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.<br />
<br />
=== GPS Assisted Bluetooth Management ===<br />
<br />
Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.<br />
<br />
A Bluetooth device is configured for automatic reacquisition based on the following profiles:<br />
* Manual - only when Bluetooth is on<br />
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.<br />
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.<br />
<br />
Each target device is configured as follows:<br />
* Automatic acquisition at last known location: enable/disable<br />
* Automatic acquisition at these locations: list of nickname + coordinates + range<br />
<br />
==== Non-mobile devices ====<br />
<br />
Examples devices include: computers<br />
<br />
The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.<br />
<br />
Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.<br />
<br />
==== Mobile devices ====<br />
<br />
Example devices include: automobiles<br />
<br />
Mobile devices are configured to have two types of locations:<br />
# Last known location<br />
# Non-mobile locations (homes)<br />
<br />
===== Last known location =====<br />
<br />
A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.<br />
<br />
===== Non-mobile locations (homes) =====<br />
<br />
As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.<br />
<br />
=== Bluetooth neighbor detection and multiuser apps ===<br />
<br />
Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.<br />
<br />
=== Bluetooth environment detection ===<br />
<br />
Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.<br />
<br />
=== Remote control ===<br />
<br />
==== Wireless presenter ====<br />
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features: <br />
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.<br />
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point<br />
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature). <br />
* If you want to be super-cool, you give a preview of the notes of the next slide in the show. <br />
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.<br />
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Initiated from another device ====<br />
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.<br />
==== Directed at another device ====<br />
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.<br />
<br />
[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)<br />
<br />
Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]<br />
<br />
=== Bluetooth Car Connection ===<br />
<br />
Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.<br />
<br />
Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]<br />
<br />
==== Dude, Where's My Car? ====<br />
<br />
When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.<br />
<br />
=== [[Bluetooth powered Multi-SIM support]] ===<br />
<br />
As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.<br />
<br />
Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:<br />
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)<br />
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset<br />
* Same for Short Messages/MMS/Internet<br />
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.<br />
Advantage: No 'switching' between cards<br />
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.<br />
<br />
===Internet Gateway===<br />
<br />
If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.<br />
<br />
=== Social Networking ===<br />
<br />
Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.<br />
<br />
=== Give userspace api control over bluetooth signal strength ===<br />
<br />
I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.<br />
<br />
<br />
== WiFi ==<br />
<br />
=== Industrial grade Wifi management ===<br />
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.<br />
<br />
: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.<br />
<br />
=== Captive portal auto-login support ===<br />
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".<br />
<br />
=== WiFi Walkie Talkie ===<br />
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
== Wireless Piggyback ==<br />
<br />
HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.<br />
<br />
== Other ==<br />
<br />
=== Auto Update ===<br />
<br />
A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .<br />
<br />
=== Vibrate Pattern Recorder ===<br />
<br />
An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).<br />
<br />
One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.<br />
<br />
- or just use MIDI, using a separate channel for the vibrator.<br />
<br />
An implementation of RTTL could also be used to define vibration patterns.<br />
<br />
=== PC Input Device ===<br />
<br />
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.<br />
<br />
Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.<br />
<br />
Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.<br />
<br />
=== Advanced Notification And Ringtone Manager ===<br />
{{Main|Wishlist-ANARM}}<br />
<br />
ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.<br />
<br />
=== Location based reminders ===<br />
{{Main|Wishlist:Location_based_reminders}}<br />
Location based reminders can be used to notify users of various events or reminders that are location based.<br />
<br />
=== Synergy Client ===<br />
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]<br />
<br />
=== Next device ===<br />
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)<br />
<br />
==== There is no device ====<br />
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:<br />
<br />
Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.<br />
<br />
I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...<br />
<br />
(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)<br />
<br />
Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?<br />
<br />
Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...<br />
<br />
A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]<br />
<br />
== GPS Software ==<br />
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]<br />
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features<br />
** Overlay of satellite images with existing streetmaps<br />
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)<br />
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )<br />
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.<br />
* "Geomark" function: if you have to save the current time with your current location, only hit one button...<br />
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...<br />
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''<br />
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.<br />
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes<br />
<br />
<br>[[Community Based Traffic Information]]<br />
<br />
== Hardware ==<br />
{{Main|Wish List - Hardware}}<br />
<br />
It could be use for beepway Online service too <br />
[http://www.beepway.com]<br />
<br />
=== Dedicated Power / Charger Pinout ===<br />
<br />
Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.<br />
<br />
Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.<br />
<br />
The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.<br />
<br />
This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now". <br />
<br />
I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).<br />
<br />
=== Inductive charging ===<br />
<br />
[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.<br />
<br />
=== Tactile feedback via buzzer ===<br />
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.<br />
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)<br />
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)<br />
<br />
=== Detachable keyboard ===<br />
Hardware keyboard that can be attached with magnets to a future version of the Neo.<br />
<br />
A bluetooth mini-qwerty keyboard that straps to my wrist!<br />
<br />
: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]<br />
<br />
=== SD Card Slot ===<br />
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]<br />
<br />
SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:<br />
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.<br />
* Enable '''storage''' of:<br />
** podcasts, full-length movies, or large photo collections<br />
** photo and video from an on-board high-res camera<br />
** entire email database at your fingertips, even in poor phone signal areas<br />
** more detailed maps and charts<br />
** encrypted work databases that are not available online<br />
* Have easy '''external access''', without requiring battery removal like the microSD card<br />
* Support '''SDIO''' accessories<br />
* Enable '''transfer''' of data from an external camera's full SD memory to:<br />
** a portable USB hard drive, offsetting the need to travel with a notebook PC<br />
** the internet, via wifi or phone network<br />
* Enable editing of videos and photos obtained from external cameras<br />
<br />
Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?<br />
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)<br />
<br />
: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)<br />
<br />
: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.<br />
<br />
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)<br />
<br />
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)<br />
<br />
[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.<br />
<br />
: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.<br />
<br />
: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]<br />
<br />
: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)<br />
<br />
: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)<br />
<br />
=== IR port ===<br />
Remote control applications<br />
<br />
Would be great to use openmoko as a Harmony remote controller.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/Wish_ListWish List2008-05-12T17:28:28Z<p>Lally: /* Industrial grade Wifi management */</p>
<hr />
<div>This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].<br />
<br />
== Development ==<br />
=== Painless SDK installation & Setup ===<br />
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]<br />
<br />
* one command for installation (apt-get install openmoko)<br />
* one command to start Xnest (openmoko-xephyr?)<br />
* one command to start an i386 shell (openmoko-386-shell)<br />
* one command to start an armel shell (openmoko-armel-shell)<br />
<br />
No extra configuration required.<br />
<br />
==== IDE Plugins ====<br />
People like to see plugins for<br />
* [http://anjuta.sourceforge.net Anjuta]<br />
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].<br />
* [http://www.netbeans.org NetBeans]<br />
* Game engine - Game Creation plugins<br />
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]<br />
* [http://www.kdevelop.org KDevelop]<br />
* [http://developer.apple.com/tools/xcode/ XCode]<br />
* [http://www.monodevelop.com MonoDevelop]<br />
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]<br />
<br />
==== UI Designer ====<br />
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]<br />
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?<br />
<br />
<br />
==== Built-in Scripting Language ====<br />
{{Main|Wishlist:BuiltInScriptingLanguage}}<br />
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.<br />
==== Easy build of the existing autotools - based packages ====<br />
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.<br />
<br />
===Foreign Widget Set Bindings ===<br />
==== Qt Integration ====<br />
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.<br />
<br />
==== Maemo Integration ====<br />
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.<br />
<br />
==== wxWidgets Integration ====<br />
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.<br />
<br />
wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]<br />
<br />
==== SDL Integration ====<br />
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.<br />
<br />
==== Cocoa / GNUstep ====<br />
Allows to use MacOS X as a development platform.<br />
<br />
=== Software: Language bindings ===<br />
==== Python bindings ====<br />
Python bindings seem to be a commonly requested feature. <br />
<br />
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."<br />
<br />
==== C++ bindings ====<br />
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.<br />
<br />
==== Ruby bindings ====<br />
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)<br />
<br />
==== Java bindings ====<br />
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported. <br />
==== Other bindings ====<br />
* Perl<br />
* C#<br />
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings<br />
<br />
== Community Support ==<br />
<br />
=== [http://projects.openmoko.org projects.openmoko.org] ===<br />
Infrastructure for developers with<br />
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)<br />
* One mailing list for project<br />
<br />
== Platform ==<br />
=== Community Images ===<br />
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.<br />
<br />
=== Wishlist voting ===<br />
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.<br />
<br />
Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]<br />
<br />
== Software: Additional features ==<br />
<br />
===PDA Mode===<br />
<br />
There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.<br />
<br />
===Driving Mode===<br />
<br />
It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones<br />
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.<br />
<br />
===Calling===<br />
<br />
==== Mask ID based on dialed numbers ====<br />
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.<br />
<br />
==== Use calling cards and similar routing techniques for lower-cost calling ====<br />
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.<br />
<br />
==== Outgoing black/white lists ====<br />
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.<br />
<br />
Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.<br />
<br />
==== Time-based blocking/unblocking of calls ====<br />
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.<br />
<br />
====Speaker-phone====<br />
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.<br />
<br />
====Advanced Airtime Tracking====<br />
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.<br />
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.<br />
<br />
* Call duration should consider billing increments and show the durations according to accounting period<br />
<br />
<br />
<br />
==== Anti-stutter software ====<br />
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.<br />
<br />
====Minimize In-Call mode (check address book while in call)====<br />
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.<br />
<br />
Similar request when using the browser (lookup passwords, todo list, etc).<br />
<br />
====Hold Music (Ringback Tone)====<br />
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.<br />
This can partially be implemented on the phone.<br />
Issues are:<br />
*In countries where callers pay, this will make you unpopular.<br />
*In countries where the called party pays, it will use your minutes, or cost you money.<br />
**A list of people to activate this function for would alleviate this.<br />
*[[GPRS]] internet connection will stall while the hold music is being played.<br />
*Extra battery used when playing music.<br />
<br />
Also see [[Answering Machine]].<br />
<br />
====Play sound clips over the air====<br />
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104<br />
The buttons can have default sounds, but also have the ability to be customized.<br />
<br />
It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.<br />
<br />
==== DTMF Landline Dialing ====<br />
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.<br />
<br />
Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.<br />
<br />
For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.<br />
<br />
==== Conversation Recorder ====<br />
<br />
An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.<br />
<br />
====Unlicensed Mobile Access (UMA)====<br />
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.<br />
<br />
This can be combined with a GPS map to show where local free hubs are.<br />
<br />
==== Ignore-Call Button ====<br />
{{Main|Wishlist:Ignore Call Button}}<br />
<br />
Shut up a ringing phone, without accepting or rejecting the call.<br />
<br />
Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises. <br />
<br />
A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.<br />
<br />
The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).<br />
<br />
==== Voice Mailbox ====<br />
{{Main|Voice Mailbox}}<br />
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.<br />
Can act profile-dependent.<br />
<br />
==== Hold Button ====<br />
<br />
Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.<br />
<br />
==== Unanswered Call, Fast Call ====<br />
<br />
In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.<br />
Then the user of the mobile phone calls the other user(using the CallerID recognition).<br />
<br />
===Audio===<br />
<br />
==== Ambient Noise Detection ====<br />
{{Main|Wishlist:Software:Ambient Noise Detection}}<br />
<br />
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.<br />
<br />
If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.<br />
<br />
Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.<br />
<br />
==== Active noise control ====<br />
<br />
Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.<br />
<br />
==== Hear Impaired Mode ====<br />
<br />
Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).<br />
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.<br />
<br />
Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.<br />
<br />
==== Mute Button ====<br />
<br />
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.<br />
<br />
<br />
===Web Browser===<br />
<br />
==== Full-page Zoom Support ====<br />
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.<br />
<br />
The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.<br />
<br />
* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.<br />
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.<br />
* If this is not practical, Minimo with full-page-zoom ability is good.<br />
<br />
==== Plugins Support ====<br />
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].<br />
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.<br />
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.<br />
<br />
==== Widget support ====<br />
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)<br />
<br />
There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.<br />
<br />
===Media===<br />
====Music/Video Software====<br />
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular. <br />
<br />
Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.<br />
<br />
It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!<br />
<br />
- Possible copyright issues sharing music files?<br />
<br />
Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.<br />
<br />
==== Reading Support ====<br />
It would be really great to be able to read :<br />
<br />
*PDF<br />
*Open Document files<br />
*Text / RTF files<br />
*fb2 files (fbreader)<br />
*MS Office files<br />
*Aportis Doc (pdb)<br />
*DjVu<br />
*...<br />
<br />
In both landscape and portrait<br />
<br />
==== Wikipedia Mirror ====<br />
{{Main|Wishlist:Wikipedia_Mirror}}<br />
<br />
==== Blog ScribblePad ====<br />
<br />
Draw an image (and maybe add some text), then post to your blog.<br />
<br />
==== E-Book Reader ====<br />
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.<br />
<br />
==== Personal Wiki ====<br />
{{Main|Wishlist:PersonalWiki}}<br />
<br />
Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].<br />
<br />
[http://www.didiwiki.org/ Didiwiki]<br />
<br />
<br />
==== Dictionary, thesaurus, translator and flashcards ====<br />
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.<br />
<br />
'''Dictionary'''<br />
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:<br />
<br />
advantages:<br />
* small<br />
* very efficient + useful<br />
* only limited to really needed functions<br />
<br />
Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)<br />
<br />
==== Flickr uploader ====<br />
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.<br />
<br />
===PIM (Personal Information Managment)===<br />
====Context Sensitivity====<br />
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?<br />
<br />
==== Notes ====<br />
<br />
Something for taking notes would be a nice feature:<br />
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.<br />
<br />
Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].<br />
<br />
==== Calendar ====<br />
<br />
A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.<br />
The tool should have a reminder feature and other features like other mobile phones already have.<br />
<br />
I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)<br />
<br />
* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)<br />
<br />
==== Address Book ====<br />
<br />
* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP<br />
servers or whatever.<br />
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.<br />
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done<br />
by integrating with whatever on-phone GPS mapping software the Neo ends up using.<br />
* Random text input 'notes' about a contact<br />
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's<br />
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant<br />
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account<br />
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.<br />
* Support for:<br />
**[http://en.wikipedia.org/wiki/SyncML SyncML]<br />
**[http://abook.sourceforge.net/ abook] a text-based addressbook program<br />
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book<br />
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).<br />
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.<br />
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).<br />
<br />
==== Database/List Display/Edit ====<br />
{{Main|Wishlist:PilotDB}}<br />
<br />
One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.<br />
<br />
==== To-Do lists ====<br />
<br />
* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.<br />
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.<br />
<br />
<br />
==== Context based To-Do list ====<br />
{{Main|Wishlist:context based to-do list}}<br />
<br />
If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.<br />
<br />
==== Workout ====<br />
<br />
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.<br />
<br />
==== Shopping List ====<br />
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.<br />
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.<br />
<br />
==== [[Fuel Log]] ====<br />
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).<br />
Advanced features could include:<br />
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)<br />
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)<br />
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)<br />
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server<br />
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.<br />
<br />
==== Keep in touch reminder ====<br />
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.<br />
<br />
<br />
==== Menstruation period timer ====<br />
Fill in statistics and compute probabilities for menstruation, fertility, mood.<br />
See http://www.getjar.com/products/48/MyGirls<br />
<br />
==== Tagging ====<br />
{{Main|Wishlist:Tagging}}<br />
Tags can be used by various applications. Requirement is interoperability for further enhancement.<br />
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.<br />
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.<br />
<br />
<br />
<br />
==== Exchange Integration ====<br />
<br />
Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.<br />
<br />
* Is the time right to name names ? Add as your liking...<br />
** Plugin/integration to & from Kontact<br />
** Same with Evolution - Thunderbird - Seamonkey<br />
** ?? Google Calendars ?? (this one is tough)<br />
** Ms Exchange<br />
<br />
==== An electronic wallet ====<br />
<br />
A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).<br />
<br />
Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]<br />
<br />
==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====<br />
<br />
Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.<br />
<br />
Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.<br />
<br />
PROS: <br />
*genuine saving in time for social and business situations<br />
<br />
CONS: <br />
*I am sure there are some security hassles to be pondered....<br />
*not going to be used every day... definitely not an immediate priority.....<br />
*only at geek conferences will all have a neo....<br />
<br />
==== SMS Counter ====<br />
<br />
An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.<br />
<br />
==== Data Storage ====<br />
<br />
Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.<br />
Make this list available through the address book.<br />
This would be great for people who are switching between one or more communication channels frequently<br />
<br />
===Profiles===<br />
{{Main|Wishlist:Profiles}}<br />
<br />
The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.<br />
And how to automatically switch between them.<br />
<br />
===Text Messaging===<br />
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included<br />
For current development status of the messaging-app see: [[Messages]].<br />
<br />
There are many useful options that now can be used to full capacity:<br />
<br />
* '''Instant Messaging'''<br />
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net<br />
<br />
* '''Acknowledge/status SMS'''<br />
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.<br />
<br />
** '''Special handling of status-SMS''' <br />
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.<br />
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date<br />
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See: <br />
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]<br />
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)<br />
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung<br />
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/<br />
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.<br />
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.<br />
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])<br />
** Implement a script that abbreviates :-)<br />
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.<br />
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).<br />
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel<br />
* '''Searching''' allow full-text search or string search.<br />
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...<br />
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.<br />
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.<br />
* '''SMS-EMail-Gateway'''<br />
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS<br />
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).<br />
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it<br />
** By standard carrier SMS - cost 10cents<br />
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE<br />
** By email/Wifi - cost FREE<br />
** By email/GPRS - cost ?<br />
** Too many options!!!<br />
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.<br />
<br />
=== Text input ===<br />
{{Main|Wishlist:Text Input}}<br />
There are many good suggestions for text input on the specific text input ideas page.<br />
<br />
=== More/Custom Input Method Widgets ===<br />
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}<br />
Additional and customizable Input Method Widgets (similar to virtual keyboard). <br />
This could add soft-key functionality to games or other applications such as:<br />
*D-Pads<br />
*buttons<br />
*virtual trackballs<br />
*...<br />
Personalized layouts could be associated with each application.<br />
<br />
=== Games ===<br />
{{Main|Wishlist:Games}}<br />
<br />
=== Mesh Networking ===<br />
{{Main|Wishlist:Mesh Networking}}<br />
<br />
=== Printing Support ===<br />
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:<br />
<br />
* Notes<br />
* Maps<br />
* Email<br />
* Calendars<br />
* ...<br />
<br />
Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on<br />
<br />
# GTK+'s printing support<br />
# Making cups run on a really small system<br />
<br />
{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}<br />
<br />
There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.<br />
<br />
Further details:<br />
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]<br />
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]<br />
* [http://www.j5live.com/?p=204 j5live.com]<br />
<br />
===Misc Software===<br />
====Clocks/timers/Activity meters====<br />
===== Sport tracker =====<br />
{{Main|Wishlist:Sport_tracker}}<br />
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.<br />
<br />
===== Standby clock =====<br />
{{Main|Wishlist:Standby_clock}}<br />
A quick way to see what time it is.<br />
<br />
===== Egg Timer =====<br />
{{Main|Wishlist:EggTimer}}<br />
<br />
Very simple (one click) count up / count down timers are very useful.<br />
<br />
===== Cycle Computer =====<br />
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.<br />
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)<br />
<br />
===== NTP Server =====<br />
<br />
Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices. <br />
<br />
I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.<br />
<br />
<br />
===== Find Keys/locate stuff =====<br />
<br />
This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.<br />
<br />
A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you. <br />
<br />
Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.<br />
<br />
For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].<br />
<br />
===== Reality check reminder =====<br />
{{Main|Wishlist:Reality check reminder}}<br />
<br />
A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]<br />
<br />
===== Automatic timezone changing (GPS) =====<br />
<br />
Check the timezone with GPS and adapt them.<br />
<br />
====Calculators====<br />
===== A Universal Unit Converter Tool =====<br />
<br />
One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers. <br />
<br />
Ideas what kind of conversions a converter tool could do:<br />
<br />
Length<br />
- Acceleration<br />
- Angle<br />
- Angular Velocity<br />
- Area<br />
- Capacitance<br />
- Radioactivity<br />
- Currency <br />
- Charge<br />
- Computer Memory<br />
- Conductance<br />
- Density<br />
- Energy<br />
- Illumination<br />
- Power<br />
- Force <br />
- Flow<br />
- Pressure<br />
- Speed<br />
- Temperature<br />
- Time<br />
- Torque<br />
- Viscosity<br />
- Volume<br />
- Weight<br />
<br />
Roman Numerals<br />
- ASCII, Hex<br />
- Cooking<br />
- BMI<br />
- Clothing Sizes<br />
<br />
Money Converter based on current rates from Internet...<br />
e. g. Dollar <-> Euro<br />
<br />
Physical and Mathematical Constants<br />
GPS conversions <br />
<br />
- link to or integration of a scientific calculator<br />
- link to or integration of a simple calculator<br />
<br />
A good basis for such a converter tool could be the Palm program "units" from <br />
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.<br />
<br />
For GPS conversions see gpsbabel [http://www.gpsbabel.org]<br />
<br />
===== An Postfix Notation (RPN) calculator =====<br />
<br />
Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.<br />
<br />
==== Windows CE Emulator ====<br />
<br />
On ARM machine, Windows CE API emulator, like Wine on x86 machines. <br />
<br />
==== PalmOS Emulator ====<br />
<br />
The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.<br />
<br />
I'd like to see a Windows CE Emulator with active sync support.<br />
<br />
==== Chumby Emulator ====<br />
<br />
Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.<br />
<br />
==== TV Guide ====<br />
Display a TV guide using [http://xmltv.org xmltv].<br />
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)<br />
<br />
==== Alcohol meter ====<br />
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.<br />
See, for example (German text) http://www.misterio-online.de/promille.htm<br />
<br />
==== Interaction with LEGO Mindstorm ====<br />
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.<br />
<br />
==== Flashlight ====<br />
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!<br />
<br />
==== Wii Controller Emulator ====<br />
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.<br />
<br />
==== FUSE support ====<br />
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)<br />
<br />
=== Accessibility ===<br />
Accessibility features for the visually impaired.<br />
* High Contrast Themes.<br />
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.<br />
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]<br />
<br />
==== VOIP ====<br />
* [[Dialer]] should be able to use SIP.<br />
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.<br />
* A standard SIP client would probably fit better into the "free and open" philosophy.<br />
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.<br />
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)<br />
<br />
''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''<br />
<br />
Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.<br />
Edw/<br />
<br />
==== Power Meter ====<br />
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.<br />
<br />
Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?<br />
<br />
=== Accelerometer wishes ===<br />
==== Flick interface ====<br />
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.<br />
<br />
Sensitivity of the scrolling should be configurable and a test option provided.<br />
<br />
==== Reading navigation of documents enhanced by accelerometers ====<br />
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.<br />
<br />
I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)<br />
<br />
==== Wand UI ====<br />
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.<br />
==== Panning interface ====<br />
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.<br />
<br />
In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.<br />
<br />
When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.<br />
<br />
==== Shake-to-Wake ====<br />
Giving the phone a shake enables voice commands for a few seconds.<br />
Usage Examples: <br />
<br />
* {Shake} "Call" ''ContactName'' ''PhoneType''<br />
* {Shake} "Call John Mobile" (Calls John's mobile)<br />
* {Shake} ''ApplicationName''<br />
* {Shake} "Reader" (Opens the e-book application)<br />
<br />
Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)<br />
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)<br />
<br />
I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.<br />
<br />
==== Emergency call ====<br />
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.<br />
<br />
A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).<br />
<br />
:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)<br />
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)<br />
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]<br />
<br />
==== Movement detection ====<br />
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.<br />
<br />
==== Games ====<br />
Imagine a first person shooter that you look around by turning your body.<br />
<br />
==== Sloshing battery indicator ====<br />
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.<br />
==== Steady screen ====<br />
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.<br />
* being mounted inside a vehicle<br />
* during certain sports<br />
* while the internal vibrator is activated (perhaps)<br />
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.<br />
<br />
At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements. <br />
<br />
Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.<br />
<br />
In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.<br />
<br />
These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.<br />
<br />
==== Taping as input ====<br />
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.<br />
<br />
==== Others ====<br />
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].<br />
<br />
=== Connectivity ===<br />
<br />
==== VNC ====<br />
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.<br />
<br />
==== Networked X-Windows ====<br />
<br />
Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.<br />
<br />
==== NX client ====<br />
<br />
A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]<br />
<br />
==== OpenOffice Presenter Control ====<br />
<br />
I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.<br />
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.<br />
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse <br />
click than to fast than you must go back.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Amarok and other Media Player remote control ====<br />
<br />
Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.<br />
<br />
==== Read informations with SMS ====<br />
Send a SMS with Code to the OpenMoko (from a specific number).<br />
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).<br />
<br />
=== Security ===<br />
<br />
==== General Filesystem Encryption ====<br />
<br />
If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed. <br />
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).<br />
<br />
http://luks.endorphin.org<br />
<br />
==== My Account ====<br />
{{Main|My Account}}<br />
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.<br />
<br />
==== [http://zfoneproject.com/ Zfone] or similar ====<br />
<br />
Something that allows the user to speak with another person securely.<br />
<br />
==== GSM Encryption ====<br />
<br />
This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel. <br />
<br />
[[OSvS]]<br />
<br />
==== My Voice is my Passport ====<br />
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."<br />
<br />
==== Firewall ====<br />
A network firewall<br />
<br />
==== Full Mac Support ====<br />
Full mac support, preferably with full software and full sync capabilities with iCal and iMail <br />
<br />
==== Anti Theft Application ====<br />
<br />
This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.<br />
<br />
====RFID based personal alerts====<br />
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.<br />
<br />
Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.<br />
<br />
====OpenVPN Client====<br />
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.<br />
<br />
=== Integrated Help System ===<br />
<br />
A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.<br />
<br />
===Performance optimisation===<br />
==== Use DMA engine in CPU for blitter ====<br />
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.<br />
<br />
==== Use virtual screen to optimise scrolling ====<br />
In some other cases, the hardware supported virtual screen may also speed it up.<br />
===Reusable Display/UI Widgets===<br />
====Use BigPage for full page zoom, scroll, scale in many apps====<br />
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen<br />
<br />
==Bluetooth==<br />
<br />
=== Voice Dialing ===<br />
<br />
Dial by voice commands.<br />
<br>Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.<br />
<br />
=== Music through Bluetooth Headset ===<br />
<br />
Music can be played through a Bluetooth headset, but would stop playing when a call comes in.<br />
<br />
=== Walkie Talkie ===<br />
<br />
Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.<br />
<br />
Features for this applications can be:<br />
* Push To Talk (PTT) button<br />
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.<br />
* Optionally a full duplex mode<br />
* Different channels to choose from<br />
* Monitor different (preselected or all) channels for traffic.<br />
* Content encryption<br />
* Active noise control<br />
* Allow zero config use (units can talk without any access point helping)<br />
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel<br />
<br />
Local (non-GPRS) use cases include chatting while biking<br />
or motorcycling in a group; perhaps also in a car caravan.<br />
This application could also be used as a baby-phone to monitor your siblings.<br />
<br />
This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.<br />
<br />
(One thumbs up from me) Jackcday<br />
<br />
See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
=== Automatic Sync ===<br />
<br />
Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.<br />
<br />
=== GPS Assisted Bluetooth Management ===<br />
<br />
Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.<br />
<br />
A Bluetooth device is configured for automatic reacquisition based on the following profiles:<br />
* Manual - only when Bluetooth is on<br />
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.<br />
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.<br />
<br />
Each target device is configured as follows:<br />
* Automatic acquisition at last known location: enable/disable<br />
* Automatic acquisition at these locations: list of nickname + coordinates + range<br />
<br />
==== Non-mobile devices ====<br />
<br />
Examples devices include: computers<br />
<br />
The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.<br />
<br />
Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.<br />
<br />
==== Mobile devices ====<br />
<br />
Example devices include: automobiles<br />
<br />
Mobile devices are configured to have two types of locations:<br />
# Last known location<br />
# Non-mobile locations (homes)<br />
<br />
===== Last known location =====<br />
<br />
A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.<br />
<br />
===== Non-mobile locations (homes) =====<br />
<br />
As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.<br />
<br />
=== Bluetooth neighbor detection and multiuser apps ===<br />
<br />
Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.<br />
<br />
=== Bluetooth environment detection ===<br />
<br />
Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.<br />
<br />
=== Remote control ===<br />
<br />
==== Wireless presenter ====<br />
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features: <br />
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.<br />
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point<br />
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature). <br />
* If you want to be super-cool, you give a preview of the notes of the next slide in the show. <br />
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.<br />
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Initiated from another device ====<br />
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.<br />
==== Directed at another device ====<br />
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.<br />
<br />
[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)<br />
<br />
Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]<br />
<br />
=== Bluetooth Car Connection ===<br />
<br />
Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.<br />
<br />
Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]<br />
<br />
==== Dude, Where's My Car? ====<br />
<br />
When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.<br />
<br />
=== [[Bluetooth powered Multi-SIM support]] ===<br />
<br />
As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.<br />
<br />
Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:<br />
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)<br />
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset<br />
* Same for Short Messages/MMS/Internet<br />
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.<br />
Advantage: No 'switching' between cards<br />
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.<br />
<br />
===Internet Gateway===<br />
<br />
If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.<br />
<br />
=== Social Networking ===<br />
<br />
Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.<br />
<br />
=== Give userspace api control over bluetooth signal strength ===<br />
<br />
I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.<br />
<br />
<br />
== WiFi ==<br />
<br />
=== Industrial grade Wifi management ===<br />
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.<br />
<br />
: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.<br />
<br />
=== Captive portal auto-login support ===<br />
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".<br />
<br />
=== WiFi Walkie Talkie ===<br />
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
== Wireless Piggyback ==<br />
<br />
HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.<br />
<br />
== Other ==<br />
<br />
=== Auto Update ===<br />
<br />
A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .<br />
<br />
=== Vibrate Pattern Recorder ===<br />
<br />
An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).<br />
<br />
One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.<br />
<br />
- or just use MIDI, using a separate channel for the vibrator.<br />
<br />
An implementation of RTTL could also be used to define vibration patterns.<br />
<br />
=== PC Input Device ===<br />
<br />
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.<br />
<br />
Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.<br />
<br />
Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.<br />
<br />
=== Advanced Notification And Ringtone Manager ===<br />
{{Main|Wishlist-ANARM}}<br />
<br />
ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.<br />
<br />
=== Location based reminders ===<br />
{{Main|Wishlist:Location_based_reminders}}<br />
Location based reminders can be used to notify users of various events or reminders that are location based.<br />
<br />
=== Synergy Client ===<br />
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]<br />
<br />
=== Next device ===<br />
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)<br />
<br />
==== There is no device ====<br />
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:<br />
<br />
Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.<br />
<br />
I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...<br />
<br />
(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)<br />
<br />
Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?<br />
<br />
Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...<br />
<br />
== GPS Software ==<br />
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]<br />
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features<br />
** Overlay of satellite images with existing streetmaps<br />
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)<br />
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )<br />
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.<br />
* "Geomark" function: if you have to save the current time with your current location, only hit one button...<br />
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...<br />
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''<br />
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.<br />
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes<br />
<br />
<br>[[Community Based Traffic Information]]<br />
<br />
== Hardware ==<br />
{{Main|Wish List - Hardware}}<br />
<br />
It could be use for beepway Online service too <br />
[http://www.beepway.com]<br />
<br />
=== Dedicated Power / Charger Pinout ===<br />
<br />
Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.<br />
<br />
Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.<br />
<br />
The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.<br />
<br />
This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now". <br />
<br />
I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).<br />
<br />
=== Inductive charging ===<br />
<br />
[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.<br />
<br />
=== Tactile feedback via buzzer ===<br />
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.<br />
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)<br />
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)<br />
<br />
=== Detachable keyboard ===<br />
Hardware keyboard that can be attached with magnets to a future version of the Neo.<br />
<br />
A bluetooth mini-qwerty keyboard that straps to my wrist!<br />
<br />
: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]<br />
<br />
=== SD Card Slot ===<br />
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]<br />
<br />
SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:<br />
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.<br />
* Enable '''storage''' of:<br />
** podcasts, full-length movies, or large photo collections<br />
** photo and video from an on-board high-res camera<br />
** entire email database at your fingertips, even in poor phone signal areas<br />
** more detailed maps and charts<br />
** encrypted work databases that are not available online<br />
* Have easy '''external access''', without requiring battery removal like the microSD card<br />
* Support '''SDIO''' accessories<br />
* Enable '''transfer''' of data from an external camera's full SD memory to:<br />
** a portable USB hard drive, offsetting the need to travel with a notebook PC<br />
** the internet, via wifi or phone network<br />
* Enable editing of videos and photos obtained from external cameras<br />
<br />
Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?<br />
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)<br />
<br />
: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)<br />
<br />
: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.<br />
<br />
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)<br />
<br />
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)<br />
<br />
[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.<br />
<br />
: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.<br />
<br />
: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]<br />
<br />
: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)<br />
<br />
: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)<br />
<br />
=== IR port ===<br />
Remote control applications<br />
<br />
Would be great to use openmoko as a Harmony remote controller.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/Wish_ListWish List2008-05-12T17:01:49Z<p>Lally: /* SD Card Slot */</p>
<hr />
<div>This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].<br />
<br />
== Development ==<br />
=== Painless SDK installation & Setup ===<br />
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]<br />
<br />
* one command for installation (apt-get install openmoko)<br />
* one command to start Xnest (openmoko-xephyr?)<br />
* one command to start an i386 shell (openmoko-386-shell)<br />
* one command to start an armel shell (openmoko-armel-shell)<br />
<br />
No extra configuration required.<br />
<br />
==== IDE Plugins ====<br />
People like to see plugins for<br />
* [http://anjuta.sourceforge.net Anjuta]<br />
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].<br />
* [http://www.netbeans.org NetBeans]<br />
* Game engine - Game Creation plugins<br />
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]<br />
* [http://www.kdevelop.org KDevelop]<br />
* [http://developer.apple.com/tools/xcode/ XCode]<br />
* [http://www.monodevelop.com MonoDevelop]<br />
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]<br />
<br />
==== UI Designer ====<br />
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]<br />
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?<br />
<br />
<br />
==== Built-in Scripting Language ====<br />
{{Main|Wishlist:BuiltInScriptingLanguage}}<br />
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.<br />
==== Easy build of the existing autotools - based packages ====<br />
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.<br />
<br />
===Foreign Widget Set Bindings ===<br />
==== Qt Integration ====<br />
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.<br />
<br />
==== Maemo Integration ====<br />
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.<br />
<br />
==== wxWidgets Integration ====<br />
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.<br />
<br />
wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]<br />
<br />
==== SDL Integration ====<br />
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.<br />
<br />
==== Cocoa / GNUstep ====<br />
Allows to use MacOS X as a development platform.<br />
<br />
=== Software: Language bindings ===<br />
==== Python bindings ====<br />
Python bindings seem to be a commonly requested feature. <br />
<br />
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."<br />
<br />
==== C++ bindings ====<br />
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.<br />
<br />
==== Ruby bindings ====<br />
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)<br />
<br />
==== Java bindings ====<br />
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported. <br />
==== Other bindings ====<br />
* Perl<br />
* C#<br />
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings<br />
<br />
== Community Support ==<br />
<br />
=== [http://projects.openmoko.org projects.openmoko.org] ===<br />
Infrastructure for developers with<br />
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)<br />
* One mailing list for project<br />
<br />
== Platform ==<br />
=== Community Images ===<br />
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.<br />
<br />
=== Wishlist voting ===<br />
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.<br />
<br />
Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]<br />
<br />
== Software: Additional features ==<br />
<br />
===PDA Mode===<br />
<br />
There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.<br />
<br />
===Driving Mode===<br />
<br />
It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones<br />
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.<br />
<br />
===Calling===<br />
<br />
==== Mask ID based on dialed numbers ====<br />
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.<br />
<br />
==== Use calling cards and similar routing techniques for lower-cost calling ====<br />
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.<br />
<br />
==== Outgoing black/white lists ====<br />
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.<br />
<br />
Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.<br />
<br />
==== Time-based blocking/unblocking of calls ====<br />
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.<br />
<br />
====Speaker-phone====<br />
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.<br />
<br />
====Advanced Airtime Tracking====<br />
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.<br />
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.<br />
<br />
* Call duration should consider billing increments and show the durations according to accounting period<br />
<br />
<br />
<br />
==== Anti-stutter software ====<br />
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.<br />
<br />
====Minimize In-Call mode (check address book while in call)====<br />
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.<br />
<br />
Similar request when using the browser (lookup passwords, todo list, etc).<br />
<br />
====Hold Music (Ringback Tone)====<br />
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.<br />
This can partially be implemented on the phone.<br />
Issues are:<br />
*In countries where callers pay, this will make you unpopular.<br />
*In countries where the called party pays, it will use your minutes, or cost you money.<br />
**A list of people to activate this function for would alleviate this.<br />
*[[GPRS]] internet connection will stall while the hold music is being played.<br />
*Extra battery used when playing music.<br />
<br />
Also see [[Answering Machine]].<br />
<br />
====Play sound clips over the air====<br />
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104<br />
The buttons can have default sounds, but also have the ability to be customized.<br />
<br />
It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.<br />
<br />
==== DTMF Landline Dialing ====<br />
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.<br />
<br />
Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.<br />
<br />
For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.<br />
<br />
==== Conversation Recorder ====<br />
<br />
An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.<br />
<br />
====Unlicensed Mobile Access (UMA)====<br />
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.<br />
<br />
This can be combined with a GPS map to show where local free hubs are.<br />
<br />
==== Ignore-Call Button ====<br />
{{Main|Wishlist:Ignore Call Button}}<br />
<br />
Shut up a ringing phone, without accepting or rejecting the call.<br />
<br />
Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises. <br />
<br />
A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.<br />
<br />
The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).<br />
<br />
==== Voice Mailbox ====<br />
{{Main|Voice Mailbox}}<br />
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.<br />
Can act profile-dependent.<br />
<br />
==== Hold Button ====<br />
<br />
Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.<br />
<br />
==== Unanswered Call, Fast Call ====<br />
<br />
In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.<br />
Then the user of the mobile phone calls the other user(using the CallerID recognition).<br />
<br />
===Audio===<br />
<br />
==== Ambient Noise Detection ====<br />
{{Main|Wishlist:Software:Ambient Noise Detection}}<br />
<br />
Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.<br />
<br />
If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.<br />
<br />
Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.<br />
<br />
==== Active noise control ====<br />
<br />
Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.<br />
<br />
==== Hear Impaired Mode ====<br />
<br />
Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).<br />
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.<br />
<br />
Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.<br />
<br />
==== Mute Button ====<br />
<br />
Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.<br />
<br />
<br />
===Web Browser===<br />
<br />
==== Full-page Zoom Support ====<br />
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.<br />
<br />
The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.<br />
<br />
* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.<br />
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.<br />
* If this is not practical, Minimo with full-page-zoom ability is good.<br />
<br />
==== Plugins Support ====<br />
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].<br />
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.<br />
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.<br />
<br />
==== Widget support ====<br />
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)<br />
<br />
There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.<br />
<br />
===Media===<br />
====Music/Video Software====<br />
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular. <br />
<br />
Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.<br />
<br />
It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!<br />
<br />
- Possible copyright issues sharing music files?<br />
<br />
Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.<br />
<br />
==== Reading Support ====<br />
It would be really great to be able to read :<br />
<br />
*PDF<br />
*Open Document files<br />
*Text / RTF files<br />
*fb2 files (fbreader)<br />
*MS Office files<br />
*Aportis Doc (pdb)<br />
*DjVu<br />
*...<br />
<br />
In both landscape and portrait<br />
<br />
==== Wikipedia Mirror ====<br />
{{Main|Wishlist:Wikipedia_Mirror}}<br />
<br />
==== Blog ScribblePad ====<br />
<br />
Draw an image (and maybe add some text), then post to your blog.<br />
<br />
==== E-Book Reader ====<br />
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.<br />
<br />
==== Personal Wiki ====<br />
{{Main|Wishlist:PersonalWiki}}<br />
<br />
Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].<br />
<br />
[http://www.didiwiki.org/ Didiwiki]<br />
<br />
<br />
==== Dictionary, thesaurus, translator and flashcards ====<br />
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.<br />
<br />
'''Dictionary'''<br />
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:<br />
<br />
advantages:<br />
* small<br />
* very efficient + useful<br />
* only limited to really needed functions<br />
<br />
Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)<br />
<br />
==== Flickr uploader ====<br />
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.<br />
<br />
===PIM (Personal Information Managment)===<br />
====Context Sensitivity====<br />
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?<br />
<br />
==== Notes ====<br />
<br />
Something for taking notes would be a nice feature:<br />
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.<br />
<br />
Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].<br />
<br />
==== Calendar ====<br />
<br />
A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.<br />
The tool should have a reminder feature and other features like other mobile phones already have.<br />
<br />
I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)<br />
<br />
* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)<br />
<br />
==== Address Book ====<br />
<br />
* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP<br />
servers or whatever.<br />
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.<br />
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done<br />
by integrating with whatever on-phone GPS mapping software the Neo ends up using.<br />
* Random text input 'notes' about a contact<br />
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's<br />
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant<br />
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account<br />
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.<br />
* Support for:<br />
**[http://en.wikipedia.org/wiki/SyncML SyncML]<br />
**[http://abook.sourceforge.net/ abook] a text-based addressbook program<br />
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book<br />
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).<br />
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.<br />
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).<br />
<br />
==== Database/List Display/Edit ====<br />
{{Main|Wishlist:PilotDB}}<br />
<br />
One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.<br />
<br />
==== To-Do lists ====<br />
<br />
* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.<br />
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.<br />
<br />
<br />
==== Context based To-Do list ====<br />
{{Main|Wishlist:context based to-do list}}<br />
<br />
If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.<br />
<br />
==== Workout ====<br />
<br />
Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.<br />
<br />
==== Shopping List ====<br />
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.<br />
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.<br />
<br />
==== [[Fuel Log]] ====<br />
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).<br />
Advanced features could include:<br />
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)<br />
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)<br />
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)<br />
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server<br />
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.<br />
<br />
==== Keep in touch reminder ====<br />
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.<br />
<br />
<br />
==== Menstruation period timer ====<br />
Fill in statistics and compute probabilities for menstruation, fertility, mood.<br />
See http://www.getjar.com/products/48/MyGirls<br />
<br />
==== Tagging ====<br />
{{Main|Wishlist:Tagging}}<br />
Tags can be used by various applications. Requirement is interoperability for further enhancement.<br />
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.<br />
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.<br />
<br />
<br />
<br />
==== Exchange Integration ====<br />
<br />
Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.<br />
<br />
* Is the time right to name names ? Add as your liking...<br />
** Plugin/integration to & from Kontact<br />
** Same with Evolution - Thunderbird - Seamonkey<br />
** ?? Google Calendars ?? (this one is tough)<br />
** Ms Exchange<br />
<br />
==== An electronic wallet ====<br />
<br />
A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).<br />
<br />
Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]<br />
<br />
==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====<br />
<br />
Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.<br />
<br />
Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.<br />
<br />
PROS: <br />
*genuine saving in time for social and business situations<br />
<br />
CONS: <br />
*I am sure there are some security hassles to be pondered....<br />
*not going to be used every day... definitely not an immediate priority.....<br />
*only at geek conferences will all have a neo....<br />
<br />
==== SMS Counter ====<br />
<br />
An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.<br />
<br />
==== Data Storage ====<br />
<br />
Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.<br />
Make this list available through the address book.<br />
This would be great for people who are switching between one or more communication channels frequently<br />
<br />
===Profiles===<br />
{{Main|Wishlist:Profiles}}<br />
<br />
The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.<br />
And how to automatically switch between them.<br />
<br />
===Text Messaging===<br />
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included<br />
For current development status of the messaging-app see: [[Messages]].<br />
<br />
There are many useful options that now can be used to full capacity:<br />
<br />
* '''Instant Messaging'''<br />
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net<br />
<br />
* '''Acknowledge/status SMS'''<br />
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.<br />
<br />
** '''Special handling of status-SMS''' <br />
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.<br />
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date<br />
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See: <br />
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]<br />
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)<br />
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung<br />
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/<br />
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.<br />
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.<br />
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])<br />
** Implement a script that abbreviates :-)<br />
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.<br />
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).<br />
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel<br />
* '''Searching''' allow full-text search or string search.<br />
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...<br />
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.<br />
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.<br />
* '''SMS-EMail-Gateway'''<br />
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS<br />
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).<br />
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it<br />
** By standard carrier SMS - cost 10cents<br />
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE<br />
** By email/Wifi - cost FREE<br />
** By email/GPRS - cost ?<br />
** Too many options!!!<br />
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.<br />
<br />
=== Text input ===<br />
{{Main|Wishlist:Text Input}}<br />
There are many good suggestions for text input on the specific text input ideas page.<br />
<br />
=== More/Custom Input Method Widgets ===<br />
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}<br />
Additional and customizable Input Method Widgets (similar to virtual keyboard). <br />
This could add soft-key functionality to games or other applications such as:<br />
*D-Pads<br />
*buttons<br />
*virtual trackballs<br />
*...<br />
Personalized layouts could be associated with each application.<br />
<br />
=== Games ===<br />
{{Main|Wishlist:Games}}<br />
<br />
=== Mesh Networking ===<br />
{{Main|Wishlist:Mesh Networking}}<br />
<br />
=== Printing Support ===<br />
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:<br />
<br />
* Notes<br />
* Maps<br />
* Email<br />
* Calendars<br />
* ...<br />
<br />
Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on<br />
<br />
# GTK+'s printing support<br />
# Making cups run on a really small system<br />
<br />
{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}<br />
<br />
There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.<br />
<br />
Further details:<br />
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]<br />
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]<br />
* [http://www.j5live.com/?p=204 j5live.com]<br />
<br />
===Misc Software===<br />
====Clocks/timers/Activity meters====<br />
===== Sport tracker =====<br />
{{Main|Wishlist:Sport_tracker}}<br />
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.<br />
<br />
===== Standby clock =====<br />
{{Main|Wishlist:Standby_clock}}<br />
A quick way to see what time it is.<br />
<br />
===== Egg Timer =====<br />
{{Main|Wishlist:EggTimer}}<br />
<br />
Very simple (one click) count up / count down timers are very useful.<br />
<br />
===== Cycle Computer =====<br />
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.<br />
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)<br />
<br />
===== NTP Server =====<br />
<br />
Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices. <br />
<br />
I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.<br />
<br />
<br />
===== Find Keys/locate stuff =====<br />
<br />
This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.<br />
<br />
A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you. <br />
<br />
Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.<br />
<br />
For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].<br />
<br />
===== Reality check reminder =====<br />
{{Main|Wishlist:Reality check reminder}}<br />
<br />
A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]<br />
<br />
===== Automatic timezone changing (GPS) =====<br />
<br />
Check the timezone with GPS and adapt them.<br />
<br />
====Calculators====<br />
===== A Universal Unit Converter Tool =====<br />
<br />
One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers. <br />
<br />
Ideas what kind of conversions a converter tool could do:<br />
<br />
Length<br />
- Acceleration<br />
- Angle<br />
- Angular Velocity<br />
- Area<br />
- Capacitance<br />
- Radioactivity<br />
- Currency <br />
- Charge<br />
- Computer Memory<br />
- Conductance<br />
- Density<br />
- Energy<br />
- Illumination<br />
- Power<br />
- Force <br />
- Flow<br />
- Pressure<br />
- Speed<br />
- Temperature<br />
- Time<br />
- Torque<br />
- Viscosity<br />
- Volume<br />
- Weight<br />
<br />
Roman Numerals<br />
- ASCII, Hex<br />
- Cooking<br />
- BMI<br />
- Clothing Sizes<br />
<br />
Money Converter based on current rates from Internet...<br />
e. g. Dollar <-> Euro<br />
<br />
Physical and Mathematical Constants<br />
GPS conversions <br />
<br />
- link to or integration of a scientific calculator<br />
- link to or integration of a simple calculator<br />
<br />
A good basis for such a converter tool could be the Palm program "units" from <br />
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.<br />
<br />
For GPS conversions see gpsbabel [http://www.gpsbabel.org]<br />
<br />
===== An Postfix Notation (RPN) calculator =====<br />
<br />
Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.<br />
<br />
==== Windows CE Emulator ====<br />
<br />
On ARM machine, Windows CE API emulator, like Wine on x86 machines. <br />
<br />
==== PalmOS Emulator ====<br />
<br />
The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.<br />
<br />
I'd like to see a Windows CE Emulator with active sync support.<br />
<br />
==== Chumby Emulator ====<br />
<br />
Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.<br />
<br />
==== TV Guide ====<br />
Display a TV guide using [http://xmltv.org xmltv].<br />
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)<br />
<br />
==== Alcohol meter ====<br />
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.<br />
See, for example (German text) http://www.misterio-online.de/promille.htm<br />
<br />
==== Interaction with LEGO Mindstorm ====<br />
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.<br />
<br />
==== Flashlight ====<br />
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!<br />
<br />
==== Wii Controller Emulator ====<br />
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.<br />
<br />
==== FUSE support ====<br />
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)<br />
<br />
=== Accessibility ===<br />
Accessibility features for the visually impaired.<br />
* High Contrast Themes.<br />
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.<br />
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]<br />
<br />
==== VOIP ====<br />
* [[Dialer]] should be able to use SIP.<br />
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.<br />
* A standard SIP client would probably fit better into the "free and open" philosophy.<br />
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.<br />
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)<br />
<br />
''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''<br />
<br />
Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.<br />
Edw/<br />
<br />
==== Power Meter ====<br />
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.<br />
<br />
Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?<br />
<br />
=== Accelerometer wishes ===<br />
==== Flick interface ====<br />
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.<br />
<br />
Sensitivity of the scrolling should be configurable and a test option provided.<br />
<br />
==== Reading navigation of documents enhanced by accelerometers ====<br />
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.<br />
<br />
I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)<br />
<br />
==== Wand UI ====<br />
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.<br />
==== Panning interface ====<br />
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.<br />
<br />
In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.<br />
<br />
When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.<br />
<br />
==== Shake-to-Wake ====<br />
Giving the phone a shake enables voice commands for a few seconds.<br />
Usage Examples: <br />
<br />
* {Shake} "Call" ''ContactName'' ''PhoneType''<br />
* {Shake} "Call John Mobile" (Calls John's mobile)<br />
* {Shake} ''ApplicationName''<br />
* {Shake} "Reader" (Opens the e-book application)<br />
<br />
Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)<br />
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)<br />
<br />
I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.<br />
<br />
==== Emergency call ====<br />
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.<br />
<br />
A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).<br />
<br />
:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)<br />
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)<br />
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]<br />
<br />
==== Movement detection ====<br />
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.<br />
<br />
==== Games ====<br />
Imagine a first person shooter that you look around by turning your body.<br />
<br />
==== Sloshing battery indicator ====<br />
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.<br />
==== Steady screen ====<br />
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.<br />
* being mounted inside a vehicle<br />
* during certain sports<br />
* while the internal vibrator is activated (perhaps)<br />
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.<br />
<br />
At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements. <br />
<br />
Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.<br />
<br />
In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.<br />
<br />
These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.<br />
<br />
==== Taping as input ====<br />
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.<br />
<br />
==== Others ====<br />
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].<br />
<br />
=== Connectivity ===<br />
<br />
==== VNC ====<br />
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.<br />
<br />
==== Networked X-Windows ====<br />
<br />
Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.<br />
<br />
==== NX client ====<br />
<br />
A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]<br />
<br />
==== OpenOffice Presenter Control ====<br />
<br />
I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.<br />
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.<br />
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse <br />
click than to fast than you must go back.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Amarok and other Media Player remote control ====<br />
<br />
Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.<br />
<br />
==== Read informations with SMS ====<br />
Send a SMS with Code to the OpenMoko (from a specific number).<br />
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).<br />
<br />
=== Security ===<br />
<br />
==== General Filesystem Encryption ====<br />
<br />
If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed. <br />
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).<br />
<br />
http://luks.endorphin.org<br />
<br />
==== My Account ====<br />
{{Main|My Account}}<br />
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.<br />
<br />
==== [http://zfoneproject.com/ Zfone] or similar ====<br />
<br />
Something that allows the user to speak with another person securely.<br />
<br />
==== GSM Encryption ====<br />
<br />
This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel. <br />
<br />
[[OSvS]]<br />
<br />
==== My Voice is my Passport ====<br />
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."<br />
<br />
==== Firewall ====<br />
A network firewall<br />
<br />
==== Full Mac Support ====<br />
Full mac support, preferably with full software and full sync capabilities with iCal and iMail <br />
<br />
==== Anti Theft Application ====<br />
<br />
This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.<br />
<br />
====RFID based personal alerts====<br />
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.<br />
<br />
Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.<br />
<br />
====OpenVPN Client====<br />
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.<br />
<br />
=== Integrated Help System ===<br />
<br />
A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.<br />
<br />
===Performance optimisation===<br />
==== Use DMA engine in CPU for blitter ====<br />
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.<br />
<br />
==== Use virtual screen to optimise scrolling ====<br />
In some other cases, the hardware supported virtual screen may also speed it up.<br />
===Reusable Display/UI Widgets===<br />
====Use BigPage for full page zoom, scroll, scale in many apps====<br />
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen<br />
<br />
==Bluetooth==<br />
<br />
=== Voice Dialing ===<br />
<br />
Dial by voice commands.<br />
<br>Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.<br />
<br />
=== Music through Bluetooth Headset ===<br />
<br />
Music can be played through a Bluetooth headset, but would stop playing when a call comes in.<br />
<br />
=== Walkie Talkie ===<br />
<br />
Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.<br />
<br />
Features for this applications can be:<br />
* Push To Talk (PTT) button<br />
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.<br />
* Optionally a full duplex mode<br />
* Different channels to choose from<br />
* Monitor different (preselected or all) channels for traffic.<br />
* Content encryption<br />
* Active noise control<br />
* Allow zero config use (units can talk without any access point helping)<br />
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel<br />
<br />
Local (non-GPRS) use cases include chatting while biking<br />
or motorcycling in a group; perhaps also in a car caravan.<br />
This application could also be used as a baby-phone to monitor your siblings.<br />
<br />
This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.<br />
<br />
(One thumbs up from me) Jackcday<br />
<br />
See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
=== Automatic Sync ===<br />
<br />
Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.<br />
<br />
=== GPS Assisted Bluetooth Management ===<br />
<br />
Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.<br />
<br />
A Bluetooth device is configured for automatic reacquisition based on the following profiles:<br />
* Manual - only when Bluetooth is on<br />
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.<br />
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.<br />
<br />
Each target device is configured as follows:<br />
* Automatic acquisition at last known location: enable/disable<br />
* Automatic acquisition at these locations: list of nickname + coordinates + range<br />
<br />
==== Non-mobile devices ====<br />
<br />
Examples devices include: computers<br />
<br />
The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.<br />
<br />
Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.<br />
<br />
==== Mobile devices ====<br />
<br />
Example devices include: automobiles<br />
<br />
Mobile devices are configured to have two types of locations:<br />
# Last known location<br />
# Non-mobile locations (homes)<br />
<br />
===== Last known location =====<br />
<br />
A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.<br />
<br />
===== Non-mobile locations (homes) =====<br />
<br />
As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.<br />
<br />
=== Bluetooth neighbor detection and multiuser apps ===<br />
<br />
Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.<br />
<br />
=== Bluetooth environment detection ===<br />
<br />
Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.<br />
<br />
=== Remote control ===<br />
<br />
==== Wireless presenter ====<br />
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features: <br />
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.<br />
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point<br />
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature). <br />
* If you want to be super-cool, you give a preview of the notes of the next slide in the show. <br />
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.<br />
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.<br />
<br />
Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]<br />
<br />
==== Initiated from another device ====<br />
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.<br />
==== Directed at another device ====<br />
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.<br />
<br />
[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)<br />
<br />
Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]<br />
<br />
=== Bluetooth Car Connection ===<br />
<br />
Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.<br />
<br />
Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]<br />
<br />
==== Dude, Where's My Car? ====<br />
<br />
When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.<br />
<br />
=== [[Bluetooth powered Multi-SIM support]] ===<br />
<br />
As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.<br />
<br />
Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:<br />
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)<br />
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset<br />
* Same for Short Messages/MMS/Internet<br />
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.<br />
Advantage: No 'switching' between cards<br />
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.<br />
<br />
===Internet Gateway===<br />
<br />
If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.<br />
<br />
=== Social Networking ===<br />
<br />
Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.<br />
<br />
=== Give userspace api control over bluetooth signal strength ===<br />
<br />
I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.<br />
<br />
<br />
== WiFi ==<br />
<br />
=== Industrial grade Wifi management ===<br />
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys. <br />
=== Captive portal auto-login support ===<br />
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".<br />
<br />
=== WiFi Walkie Talkie ===<br />
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.<br />
<br />
== Wireless Piggyback ==<br />
<br />
HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.<br />
<br />
== Other ==<br />
<br />
=== Auto Update ===<br />
<br />
A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .<br />
<br />
=== Vibrate Pattern Recorder ===<br />
<br />
An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).<br />
<br />
One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.<br />
<br />
- or just use MIDI, using a separate channel for the vibrator.<br />
<br />
An implementation of RTTL could also be used to define vibration patterns.<br />
<br />
=== PC Input Device ===<br />
<br />
Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.<br />
<br />
Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.<br />
<br />
Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.<br />
<br />
=== Advanced Notification And Ringtone Manager ===<br />
{{Main|Wishlist-ANARM}}<br />
<br />
ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.<br />
<br />
=== Location based reminders ===<br />
{{Main|Wishlist:Location_based_reminders}}<br />
Location based reminders can be used to notify users of various events or reminders that are location based.<br />
<br />
=== Synergy Client ===<br />
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]<br />
<br />
=== Next device ===<br />
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)<br />
<br />
==== There is no device ====<br />
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:<br />
<br />
Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.<br />
<br />
I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...<br />
<br />
(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)<br />
<br />
Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?<br />
<br />
Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...<br />
<br />
== GPS Software ==<br />
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]<br />
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features<br />
** Overlay of satellite images with existing streetmaps<br />
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)<br />
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )<br />
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.<br />
* "Geomark" function: if you have to save the current time with your current location, only hit one button...<br />
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...<br />
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''<br />
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.<br />
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes<br />
<br />
<br>[[Community Based Traffic Information]]<br />
<br />
== Hardware ==<br />
{{Main|Wish List - Hardware}}<br />
<br />
It could be use for beepway Online service too <br />
[http://www.beepway.com]<br />
<br />
=== Dedicated Power / Charger Pinout ===<br />
<br />
Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.<br />
<br />
Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.<br />
<br />
The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.<br />
<br />
This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now". <br />
<br />
I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).<br />
<br />
=== Inductive charging ===<br />
<br />
[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.<br />
<br />
=== Tactile feedback via buzzer ===<br />
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.<br />
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)<br />
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)<br />
<br />
=== Detachable keyboard ===<br />
Hardware keyboard that can be attached with magnets to a future version of the Neo.<br />
<br />
A bluetooth mini-qwerty keyboard that straps to my wrist!<br />
<br />
: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]<br />
<br />
=== SD Card Slot ===<br />
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]<br />
<br />
SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:<br />
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.<br />
* Enable '''storage''' of:<br />
** podcasts, full-length movies, or large photo collections<br />
** photo and video from an on-board high-res camera<br />
** entire email database at your fingertips, even in poor phone signal areas<br />
** more detailed maps and charts<br />
** encrypted work databases that are not available online<br />
* Have easy '''external access''', without requiring battery removal like the microSD card<br />
* Support '''SDIO''' accessories<br />
* Enable '''transfer''' of data from an external camera's full SD memory to:<br />
** a portable USB hard drive, offsetting the need to travel with a notebook PC<br />
** the internet, via wifi or phone network<br />
* Enable editing of videos and photos obtained from external cameras<br />
<br />
Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?<br />
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)<br />
<br />
: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)<br />
<br />
: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.<br />
<br />
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)<br />
<br />
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)<br />
<br />
[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.<br />
<br />
: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.<br />
<br />
: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]<br />
<br />
: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)<br />
<br />
: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)<br />
<br />
=== IR port ===<br />
Remote control applications<br />
<br />
Would be great to use openmoko as a Harmony remote controller.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/Group_salesGroup sales2008-05-05T09:42:26Z<p>Lally: /* Virginia */ Just adding Lally in.</p>
<hr />
<div>Openmoko have announced a scheme to sell the forthcoming Neo Freerunner at a discount if bought in multiples of 10 (US$369, instead of 399), to be shipped in one package. Group buying will thus save money on the purchase, and on the shipping. This page is to to organise group purchases by region.<br />
<br />
Steve from Openmoko announced "Every 10 pack, will come with a box of stuff. 10 pouches and 10 head sets."<br />
So join us within a local group !<br />
<br />
<div style='float:right'>__TOC__</div><br />
<br />
== Australia ==<br />
=== Western Australia ===<br />
==== Perth ====<br />
<br />
* 1x Fred Janon mailto:fjanon@yahoo.com<br />
<br />
* 1x Shanon Loughton [http://wiki.openmoko.org/wiki/Special:Emailuser/cgltower contact me here]<br />
<br />
* 1x Simon Matthews [http://wiki.openmoko.org/wiki/Special:Emailuser/simat contact me here]<br />
<br />
* 1x ([[Image:MokoBox.jpg]] - advanced) Msquared [http://www.msquared.id.au/ contact me here]<br />
<br />
* 1x Alex Wilkinson mailto:alex.wilkinson@dsto.defence.gov.au<br />
<br />
=== New South Whales ===<br />
==== Sydney ====<br />
status: 7/10<br />
Please add a I exist to end of your name here. <br />
Also, sydney seems to now have 7 people perhaps if we do not reach 10 we can join with Melbourne and get them shipped to Australia then moved domestically to the other city.<br />
* 1X dbmoodb ---> [http://wiki.openmoko.org/wiki/Special:Emailuser/Dbmoodb contact me here] I exist.<br />
* 1 x Mark Chandler [http://wiki.openmoko.org/wiki/Special:Emailuser/Openmarko contact me here]<br />
* 1 x bing [http://wiki.openmoko.org/wiki/Special:Emailuser/Bingquick contact me here]<br />
* 1 x ch0gan [http://wiki.openmoko.org/wiki/Special:Emailuser/ch0gan contact me here]<br />
* 1 x Neil Brown [http://wiki.openmoko.org/wiki/Special:Emailuser/Neilbrown contact me here]<br />
* 1 x Rob [http://wiki.openmoko.org/wiki/Special:Emailuser/Rob contact me here]<br />
* 1 x Tim [http://wiki.openmoko.org/wiki/Special:Emailuser/Voyd contact me here] I am almost certain I exist.<br />
<br />
=== Victoria ===<br />
==== Melbourne ====<br />
Status: 6/10<br />
<br />
* 4x Dennis Wollersheim, mailto: dewoller (at) gmail (dot) com<br />
* 1x Nigel Cunningham, mailto: ncunningham (at) crca (dot) org (dot) au<br />
(I'm actually in Cobden, in the south-west)<br />
* 1x Dale Maggee, mailto: antisol (at) earthling (dot) net<br />
<br />
=== ACT ===<br />
==== Canberra ====<br />
Status: 2/10<br />
<br />
* J Dinale [http://wiki.openmoko.org/wiki/Special:Emailuser/Noledil Contact me here]<br />
* Fergus [http://wiki.openmoko.org/wiki/Special:Emailuser/Someone Contact me here]<br />
<br />
=== Queensland ===<br />
==== Brisbane ====<br />
Status: 4/10 (possibly 20)<br />
<br />
* Nick Devereaux x 2 [http://wiki.openmoko.org/wiki/Special:Emailuser/Monkeypanic Contact me here]<br />
* Matt Gallagher [http://wiki.openmoko.org/wiki/Special:Emailuser/mattg Contact me here]<br />
* Jordan Keith [http://wiki.openmoko.org/wiki/Special:Emailuser/Zedd_D1abl0 Contact me here]<br />
<br />
=== South Australia ===<br />
==== Adelaide ====<br />
Status: 3/10<br />
<br />
* Adrian Billiau [http://wiki.openmoko.org/wiki/Special:Emailuser/Carcin Contact me here]<br />
* John Briggs [http://wiki.openmoko.org/wiki/Special:Emailuser/Erflungued Contact me here]<br />
* Daniel Sobey [http://wiki.openmoko.org/wiki/Special:Emailuser/dns Contact me here]<br />
<br />
== Austria ==<br />
There is a group-buy page at MetaLab, available here: http://metalab.at/wiki/OpenMoko .. we almost have the full 10 slots assigned, and its quite possible that we will order *20* phones, so please register on the Metalab pages and let us know if you're interested .. <br />
<br />
=== Salzburg ===<br />
Status: 1/10<br />
<br />
* D. Kepplinger [http://wiki.openmoko.org/wiki/Special:Emailuser/Wedge Contact me here]<br />
=== Wien ===<br />
Status: 1/10<br />
* M. Greifeneder [http://wiki.openmoko.org/wiki/Special:Emailuser/mikegr Contact me here]<br />
* J. Vaughan (torpor) -- http://metalab.at/wiki/OpenMoko [http://wiki.openmoko.org/wiki/Special:Emailuser/torpor Contact me here]<br />
<br />
<br />
=== Styria ===<br />
==== Graz ====<br />
Status: 6/10<br />
<br />
* F Hackenberger [http://wiki.openmoko.org/wiki/Special:Emailuser/Deadman66 Contact me here]<br />
* J Florineth [http://wiki.openmoko.org/wiki/Special:Emailuser/Flojoh Contact me here]<br />
* G Michelitsch [http://wiki.openmoko.org/wiki/Special:Emailuser/graf_ithaka Contact me here] (I've found others @ TU Graz !)<br />
* R Stoegbuchner [http://wiki.openmoko.org/wiki/Special:Emailuser/stoero Contact me here]<br />
* M Lipp [http://wiki.openmoko.org/wiki/Special:Emailuser/Neldoreth Contact me here]<br />
* M Maier [http://wiki.openmoko.org/wiki/Special:Emailuser/species Contact me here]<br />
<br />
== Belgium ==<br />
=== Flanders ===<br />
==== Brussel/Aalst/Gent/Brugge ====<br />
Status 7/10<br />
* Yorick, mailto: yorick DOT matthys AT gmail DOT com<br />
* 2x Dolfje [http://wiki.openmoko.org/wiki/Special:Emailuser/Dolfje Contact me here]<br />
* XVens, mailto: xavier DOT vens AT gmail DOT com<br />
* Arno85, mailto: aaron DOT helin AT gmail DOT com, Kortrijk<br />
* Philoufr, mailto: philoufr AT gmail DOT com<br />
* Js Op de Beeck [http://wiki.openmoko.org/wiki/Special:Emailuser/Js.opdebeeck Contact me here]<br />
ps: Dolfje can bring freerunners to Brugge if needed<br />
<br />
==== Antwerp ====<br />
Status 5/10<br />
<br />
* michielv [http://wiki.openmoko.org/wiki/Special:Emailuser/Michielv Contact me here]<br />
* Peter N [http://wiki.openmoko.org/wiki/Special:Emailuser/Bubsy Contact me here]<br />
* Ivo [http://wiki.openmoko.org/wiki/Special:Emailuser/Ivo Contact me here]<br />
* Peter Leemans, mailto: peter AT x-tend DOT be<br />
* Richard B [http://wiki.openmoko.org/wiki/Special:Emailuser/richardb Contact me here]<br />
<br />
== Bulgaria ==<br />
=== Sofia ===<br />
==== Sofia ====<br />
Status : 2/10<br />
<br />
* Dimitar Staykov, mailto:meditache@gmail.com<br />
* Vernim, [http://wiki.openmoko.org/wiki/Special:Emailuser/Vernim Contact]<br />
<br />
== Canada ==<br />
<br />
=== British Columbia ===<br />
Status : 9/10<br />
<br />
* Justin (Vancouver): mailto: stryderjzw AT gmail<br />
* Dave (Vancouver) Vancouver Linux users group (unconfirmed but about 7 so far): mailto: doc AT skynet REMOVE dot REMOVE ie<br />
* Steven (Victoria) - If someone in the group will remail the package for me. mailto: skurylo --> gmail dot com<br />
<br />
=== Alberta ===<br />
Status : 3/10<br />
<br />
* [[User:Wuth|Wuth]] : [mailto:wuth@acm.org]<br />
* [[User:Slm3095om|stacy]] (2 units) : slm3095om AT millions dOt ca<br />
<br />
=== Ontario/Quebec ===<br />
==== GTA (Toronto) ====<br />
Status : 12/10<br />
<br />
* Gerald A [http://wiki.openmoko.org/wiki/Special:Emailuser/Historybuff Contact me here]<br />
* MattC, mailto: quirkz AT gmail<br />
* Sergey K, openmoko AT deeptown dOt org<br />
* Peter Baldwin, vendor.openmoko AT pointclark DOT net ('''3 units''')<br />
* Kristin Low, kristin dot low at gmail dot com (Kingston)<br />
* Daniel Lister, dan.lister-->gmail<br />
* Ronnie Wong: '''3 units''' - r25wong AT ryerson dOT ca<br />
* Paul V [http://wiki.openmoko.org/wiki/Special:Emailuser/Roju Contact me here]<br />
<br />
Group 2 Status (Hamilton): 1/10<br />
<br />
* Gabriel D - ace AT staticwave DOT ca<br />
<br />
== Chile ==<br />
=== Santiago ===<br />
Status : 4/10<br />
<br />
* [[User:Mankeke]] Ricardo Manríquez C., mailto: ricardo.manriquez "remove this and add AT" gmail "dot" com<br />
* [[User:XKnightmareX]] Gonzalo Pesenti., mailto: mare.knight1 "remove this and add AT" gmail "dot" com<br />
* [[User:Freyes]] Felipe Reyes., mailto: felipereyes "remove this and add AT" gmail "dot" com<br />
* [[User:Zeus]] Jonathan Gonzalez., mailto: zeus "remove this and add AT" gnu "dot" org<br />
<br />
== Denmark ==<br />
If we do not reach a total large enough, Denmark **is** a very small place - surely we could figure out a way of getting them to find their way 'round the country :)<br />
<br />
=== Jutland ===<br />
==== Aalborg ====<br />
Status: 3/10<br />
<br />
Should anyone need it, transportation from Aalborg to Thisted for phones can be arranged, if you don't want to pick it up in Aalborg yourself :) ~~leinir<br />
<br />
* Dan Leinir Turthra Jensen <br /> mailto:admin@leinir.dk <br /> [[User:Leinir]]<br />
* Fabian Olesen <br /> mailto:firewalkerx@gmail.com<br />
* Helge Willum Larsen <br /> mailto:helge.at.helges.dk<br />
<br />
==== Skjern ====<br />
Status: 1/10<br />
<br />
* [[User:Carlo]]<br />
<br />
=== Fyn ===<br />
Status: 2/10<br />
<br />
* [[User:EsbenDamgaard]]<br />
* [[User:apm]]<br />
<br />
=== Sjælland ===<br />
==== Copenhagen ====<br />
Status: 26/10<br />
<br />
* [[User:Fursund]]<br />
* [[User:Rasmusjensen]]<br />
* [[User:tabac]] Thomas Ammitzbøll-Bach<br />
* [[User:chel | Christian E. Lysel ]]<br />
* [[User:UlrikRasmussen | Ulrik Rasmussen]]<br />
* [[User:KlaymenDK | Jan Gundtofte-Bruun]] (Pending final hw, eg. low-power LEDs)<br />
* [[User:OleTange | Ole Tange]] (I need 14 with invoice)<br />
* [[User:Pascal | Pascal d'Hermilly]] (I need 1 with invoice)<br />
* [[User:Miwer]] Michael Andersen<br />
* M. Stenderup [http://wiki.openmoko.org/wiki/Special:Emailuser/Mast contact me here]<br />
* [[User:maha | Martin Hansen]] (3 with invoice)<br />
<br />
== Finland ==<br />
=== Uusimaa ===<br />
==== Helsinki I (Full)====<br />
Status : 10/10<br />
<br />
* Mikko Rauhala x2 [mailto:mjr@iki.fi mjr@iki.fi]<br />
* Aleksi Hankalahti <br /> [mailto:aleksi.hankalahti@iki.fi aleksi.hankalahti@iki.fi]<br />
* Seppo Hätönen <br /> [mailto:karrde@iki.fi karrde@iki.fi]<br />
* Arttu Sund <br /> [mailto:thearttu@gmail.com thearttu@gmail.com]<br />
* Ville-Pekka Vainio <br /> vpivaini AT cs.helsinki.fi<br />
* Heikki Hallamaa <br /> [mailto:heikki.hallamaa@iki.fi heikki.hallamaa@iki.fi]<br />
* Tomi Jylhä-Ollila <br /> tomi.jylha-ollila@helsinki.fi<br />
* Richard Braakman<br />
* Timo Jyrinki <br /> [mailto:timo.jyrinki@iki.fi timo.jyrinki@iki.fi]<br />
<br />
==== Helsinki II & Turku (united)====<br />
<br />
Status : 9/10<br />
<br />
Helsinki:<br />
<br />
* [[User:Piksi]] <br />openmoko ÄT pi-xi PISTE net<br />
* Risto H. Kurppa <br /> risto AT kurppa DOT fi<br />
* Aapo Rantalainen <br /> aapo DOT rantalainen AT gmail DOT com<br />
* Matti Laakso <br /> matti DOT laakso AT kotiposti DOT net<br />
* Ismo Haanaho <br /> ismo DOT haanaho AT gmail DOT com<br />
<br />
Turku:<br />
<br />
* 2x Teemu Välimäki, [mailto:teemu.valimaki@iki.fi teemu.valimaki@iki.fi]<br />
* Jaakko Lehtinen, jaakko dot lehtinen at gmail dot com<br />
* Janne Junnila, janne dot junnila at gmail dot com<br />
<br />
== France ==<br />
=== Bretagne ===<br />
==== Brest ====<br />
Status : 1/10<br />
<br />
* StevenLeRoux [mailto:steven@pourri.fr steven@pourri.fr] Jabber_Id:Steven@jabber.fr<br />
* Acheteur potentiel #2<br />
<br />
==== Rennes ====<br />
Status : 2/10<br />
<br />
* Cédric DUFOUIL (openmoko at tsleg point com)<br />
* Yves MAHE (ymahe at zindep dot com)<br />
<br />
=== Pays de la Loire ===<br />
==== La Roche sur Yon ====<br />
Status : 1/10<br />
<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/Vtouchar Vincent Touchard] (I may soon move to Bretagne/Brest)<br />
<br />
==== Nantes ====<br />
<br />
* [[User:Yoann|Yoann ARNAUD]]. OK for a ship in Rennes if needed. [http://wiki.openmoko.org/wiki/Special:Emailuser/Yoann Contact me here]<br />
<br />
=== Ile de france ===<br />
==== Paris ====<br />
Status : 11/10<br />
<br />
* StevenLeRoux<br />
* [[User:Phyce|Phyce]]<br />
* Yann SLADEK<br />
* [[User:Wilk|Wilk]] [http://wiki.openmoko.org/wiki/Special:Emailuser/Wilk Contact me here]<br />
* Jonathan Magano ([http://wiki.openmoko.org/wiki/Special:Emailuser/JonathanMM Contact me here])<br />
* Benjamin Renard (bn8[AT]zionetrix.net)<br />
* [[User:OlivierBerger|OlivierBerger]]<br />
* [[User:BartGS|BartGS]] [http://wiki.openmoko.org/wiki/Special:Emailuser/BartGS Contact me here]<br />
* [[User:rcoscali|Rémi Cohen-Scali]]<br />
* [[User:Valos|Valéry Febvre]]<br />
* [[User:Manou|Emmanuel Raviart]]<br />
<br />
You may also see :<br />
http://bearstech.com/openmoko/register<br />
<br />
=== Rhône-Alpes ===<br />
==== Lyon ====<br />
Status : 2/10<br />
<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/patou Vincent MEURISSE]<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/pini Gilles FILIPPINI]<br />
<br />
==== Grenoble ====<br />
Status : 2/10<br />
<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/pbollard Philippe BOLLARD]<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/aurelien Aurelien]<br />
<br />
=== Provence Alpes Cote d'Azur ===<br />
==== Sophia Antipolis ====<br />
Status : 1/10<br />
<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/nico.inc Nicolas HUOT]<br />
<br />
== Germany ==<br />
=== Sachsen-Anhalt ===<br />
==== Stendal (evtl. Magdeburg) ====<br />
Status 1/10<br />
<br />
* Fabian Off [http://wiki.openmoko.org/wiki/Special:Emailuser/Fabian2de Contact me here]<br />
<br />
=== Hamburg ===<br />
==== Hamburg ====<br />
Status 9-10<br />
<br />
* Jan 4-5[http://wiki.openmoko.org/wiki/Special:Emailuser/Jan07 Contact me here]<br />
* Varacanero [http://wiki.openmoko.org/wiki/Special:Emailuser/varacanero Contact me here]<br />
* Ole 3-5 pcs [http://wiki.openmoko.org/wiki/Special:Emailuser/Olemoko Contact me here]<br />
* Arne [http://wiki.openmoko.org/wiki/Special:Emailuser/GuraX Contact me here]<br />
<br />
=== Hessen ===<br />
==== Frankfurt ====<br />
Status 1-10<br />
<br />
* Blacky [http://wiki.openmoko.org/wiki/Special:Emailuser/Blacky Contact me here]<br />
<br />
=== Sachsen ===<br />
==== Chemnitz ====<br />
Status 1/10<br />
<br />
* Tobias [http://wiki.openmoko.org/wiki/Special:Emailuser/Tobydox Contact me here]<br />
==== Dresden ====<br />
Status 1/10<br />
<br />
* Martin [http://wiki.openmoko.org/wiki/Special:Emailuser/nodge Contact me here]<br />
<br />
=== Thueringen ===<br />
==== Weimar ====<br />
Status 1/10<br />
<br />
* [[User:Fries43]]<br />
<br />
=== NRW ===<br />
==== Bielefeld ====<br />
Status 4/10<br />
<br />
* David, infos on my [[User:Raven|user page]], or you can [[Special:Emailuser/Raven|contact me here]]<br />
* Sebastian, infos on my [[User:Seppi|user page]], or you can [[Special:Emailuser/Seppi|contact me here]]<br />
* Dackel, infos on my [[User:Killerdackel|user page]], or you can [[Special:Emailuser/Killerdackel|contact me here]]<br />
* Conny<br />
* Arndt, infos on my [[User:Arndot|user page]], or you can [[Special:Emailuser/Arndot|contact me here]]<br />
<br />
==== Aachen ====<br />
Status 2/10<br />
* Henrik, infos on my [[User:Henrikz|user page]], or you can [[Special:Emailuser/Henrikz|contact me here]]<br />
* David, infos on my [[User:TechnoFan|user page]], or you can [[Special:Emailuser/TechnoFan|contact me here]]<br />
<br />
==== Düsseldorf ====<br />
* mac2k, infos on my [[User:mac2k|user page]], or you can [[Special:Emailuser/mac2k|contact me here]]<br />
<br />
=== Baden-Württemberg ===<br />
==== Karlsruhe ====<br />
<br />
Status 11/10<br />
<br />
* 2 for André (one for me and one for a friend), you can [[Special:Emailuser/Spacemarine|contact me here]]<br />
* [[Special:Emailuser/Dr.Nop|Dr.Nop]]<br />
* [[Special:Emailuser/JensB|JensB]]<br />
* [[Special:Emailuser/Tedo|Tedo]]<br />
* 3 devices at least, [[Special:Emailuser/ZaPPaS|ZaPPaS]]<br />
<br />
* [[Special:Emailuser/Gromgull|Gromgull]] (in Kaiserslautern, but Karlsruhe is close enough, and I doubt that I'll find 10 people here.<br />
* [[Special:Emailuser/Ebi|Ebi]]<br />
* [[Special:Emailuser/RIdd3r|Fabian]]<br />
<br />
=== Bayern ===<br />
==== München ====<br />
<br />
Status 3/10<br />
<br />
* [[Special:Emailuser/Eriks|Eriks]]<br />
* --[[User:Imitation|Imitation]] 21:42, 30 April 2008 (CEST)<br />
* [[Special:Emailuser/meyerm|meyerm]] 16:25 CEST, 01. Mai 2008<br />
<br />
=== Berlin===<br />
==== Berlin ====<br />
<br />
for berlin-talk: http://de.groups.yahoo.com/group/openmoko-berlin/<br />
<br />
* Conrad [http://wiki.openmoko.org/wiki/User:Caribu Contact me here]<br />
<br />
This group has finished its forming:<br />
Status 10/10<br />
* Stephan [http://wiki.openmoko.org/wiki/User:Fischel Contact me here]<br />
* Robert [http://wiki.openmoko.org/wiki/User:Thebohemian Contact me here]<br />
* Nico [http://wiki.openmoko.org/wiki/User:Nico Contact me here]<br />
* Torsten [http://wiki.openmoko.org/wiki/User:Torsten_Grote Contact me here]<br />
* Bastian [[User:Fries43]]<br />
* Sven-Ola [http://wiki.openmoko.org/wiki/User:Sven-ola Contact]<br />
* Arne [http://wiki.openmoko.org/wiki/User:arnepp Contact me here]<br />
* MM [http://wiki.openmoko.org/wiki/User:MM Contact]<br />
* Keks [http://wiki.openmoko.org/wiki/User:Keksdosenmann Contact]<br />
* Matthias [http://wiki.openmoko.org/wiki/User:mk Contact]<br />
<br />
== Hungary == <br />
discussion here: http://hup.hu/node/54588<br />
<br />
=== Budapest ===<br />
Status 11/10<br />
<br />
* Lion/Kempelen [http://wiki.openmoko.org/wiki/Special:Emailuser/kempelen Contact]<br />
* rka [http://wiki.openmoko.org/wiki/Special:Emailuser/rka Contact]<br />
* tg [http://wiki.openmoko.org/wiki/Special:Emailuser/tg?wpSubject=OpenMoko%20GroupSales Contact]<br />
* LiRul - lirul [KUKAC] hixsplit [PONT] hu<br />
* Nyosigomboc - nyos [KUKAC] nyos [PONT] homelinux [PONT] net<br />
* hunludvig - hunludvig [KUKAC] gmail [PONT] com<br />
* Dániel Vásárhelyi (asd), asd [at] offtopic [dot] com<br />
* asch, asch [KUKAC] freemail [PONT] hu<br />
* btamas, [http://wiki.openmoko.org/wiki/Special:Emailuser/btamas Contact]<br />
* ka87, andras [kukac] csevego [pont] net<br />
* pcm, pcm [kukac] freemail [pont] hu<br />
<br />
== India ==<br />
=== Delhi/NCR ===<br />
Status 1/10<br />
<br />
* Goldwyn Rodrigues [http://wiki.openmoko.org/wiki/Special:Emailuser/goldwynr Contact]<br />
<br />
== Italy == <br />
If we don't reach the 10 phones limit in each city, maybe we could place an order in the "most requested city", and from shipping to other buyers. We'll have anyway a good discount although the "double-shipping". ([http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/10937/focus=10981 Read here for reference]).<br />
<br />
=== Toscana ===<br />
==== Firenze (e dintorni) ====<br />
Status 6/10<br />
<br />
* [[User:Treviño|Marco Trevisan (Treviño)]] - [http://blog.3v1n0.net/contatti-trevino/ Contacts here]<br />
* [[User:Niccolo|Niccolo Rigacci]] - ''niccolo [AT] rigacci.org''<br />
* [[User:pcav|Paolo Cavallini]] - ''cavallini [AT] faunalia.it''<br />
* [[User:BiggMatt|Mattia Gentile]] - ''biggmatt@hotmail.it''<br />
* Elisa ''[mailto:lab@kkk.it lab@kkk.it]'' (Empoli)<br />
* [[User:Sugacapra|Sugacapra]] - alessio.chemeri [AT] gmailPUNTOcom<br />
<br />
=== Lombardia ===<br />
<br />
==== Milano e dintorni ====<br />
Status 14/10<br />
<br />
* Marco Crociani - [http://wiki.openmoko.org/wiki/Special:Emailuser/Tyrael Contacts here]<br />
* Marcello Gorla<br />
* Maxxer [mailto:maxxer@yetopen.it maxxer@yetopen.it] (Lecco)<br />
* Pietro Montorfano [mailto:monto84@gmail.com monto84@gmail.com] (from como)<br />
* Gianluigi Belli - [http://wiki.openmoko.org/wiki/Special:Emailuser/Pulciux Contacts here] (Milano)<br />
* Michele Castellano - [http://wiki.openmoko.org/wiki/Special:Emailuser/mubumba Contacts here] (Milano)<br />
* Maurizio Lipreri - [http://wiki.openmoko.org/wiki/Special:Emailuser/Maldido Contacts here]( Como )<br />
* Guido Conaldi - [http://wiki.openmoko.org/wiki/Special:Emailuser/skepz Contacts here] (Varese)<br />
* [[User:Furester|Igor Scabini (furester)]] -[http://wiki.openmoko.org/wiki/Special:Emailuser/Furester Contacts here] (Milano)<br />
* Dario Panico [http://wiki.openmoko.org/wiki/Special:Emailuser/Dareus Contacts here] (Busto Arsizio, VA)<br />
* Marco Zanzotera (Milano città) - qualcuno sa indicarmi i metodi di pagamento per favore?<br />
* Francesco Ricci (Milano, Dipartimento di Scienze dell'Informazione, via Comelico 39/41) - possibile punto di ricezione/distribuzione - [http://wiki.openmoko.org/wiki/Special:Emailuser/Alfa21 Contacts here]<br />
* Danilo Sia (Birdack) [http://wiki.openmoko.org/wiki/Special:Emailuser/Birdack Contacts here] (Milano città)<br />
* Federico Belvisi - [http://wiki.openmoko.org/wiki/Special:Emailuser/Armalite Contacts here] (Legnano, MI/Varese)<br />
<br />
=== Piemonte ===<br />
==== Torino (and province) ====<br />
Status 5/10<br />
<br />
* Claudio Carnino <br/> (jollyr0g3r AT gmail DOT com)<br />
* Alessandro Degano <br/> (a.degano AT gmail DOT com)<br />
* Enrico Pigozzi <br/> (videokill71 AT gmail DOT com)<br />
* Max Ciavarella - [http://wiki.openmoko.org/wiki/Special:Emailuser/Cicchetebom Contacts here]<br />
* Giuseppe Barbieri (elect86 at gmail dot com)<br />
<br />
=== Trentino-Alto Adige ===<br />
==== Trento (Padova too :)) ====<br />
Status 1/10<br />
<br />
* Andrea Debortoli <br/> (debortoland AT gmail DOT com)<br />
<br />
=== Friuli Venezia Giulia ===<br />
==== Trieste ====<br />
Status: 1/10<br />
<br />
* dorje [mailto:dorje@libero.it dorje@libero.it] - [[User:dorje|dorje]]<br />
<br />
=== Veneto ===<br />
Status: 7/10<br />
<br />
==== Verona ====<br />
<br />
* Persegat [mailto:persegat@alice.it persegat@alice.it] - [[User:Pecce|Pecce]]<br />
* Sylar91 [mailto:sylar1991@gmail.com sylar1991@gmail.com] - [[User:Sylar91|Sylar91]]<br />
* Marco Franceschetti - [http://wiki.openmoko.org/wiki/Special:Emailuser/vonfritz Contacts here]<br />
<br />
==== Vicenza ====<br />
<br />
* Matteo [mailto:matteo@member.fsf.org matteo@member.fsf.org] - [[User:Tchernobog|Tchernobog]]<br />Also Padova is okay.<br />
<br />
==== Venezia ====<br />
<br />
* Tommaso [mailto:tommaso.gardumi@gmail.com tommaso.gardumi@gmail.com] - [[User:Tobarello|Tobarello]] <br />Also Padova, Vicenza & Trento are ok.<br />
<br />
==== Treviso ====<br />
<br />
* Dario [mailto:aliasbrain@gmail.com aliasbrain(at)gmail.com] - [[User:Rastafan|Rastafan]] <br />one, maybe two.<br />
<br />
* Pedro [mailto:paguilar@junkerhq.net paguilar(at)junkerhq.net] - [[User:Paguilar|Paguilar]] <br/>Also Padova and Vicenza are ok.<br />
<br />
=== Emilia Romagna ===<br />
==== Parma ====<br />
Status : 2/10<br />
<br />
* [[User:Delian|Marco Albanese]] [mailto:delian2@gmail.com delian2@gmail.com] For Me, it's ok for the decentralized shipment ( Milano for example :) ).<br />
<br />
* [[User:Jordano|Marco Grassi]] marco.gra AT Gmail Dot com Also for me it's ok the decentralized shipping.<br />
<br />
=== Puglia ===<br />
==== Lecce ====<br />
Status : 2/10<br />
<br />
* [[User:Morpheus90|Morpheus90]] [mailto:ugopiemontese@rudiaelinux.com ugopiemontese@rudiaelinux.com]<br />
* [[User:Italyanker|italyanker]] [mailto:italyanker@gmail.com italyanker@gmail.com]<br />
<br />
==== Bari ====<br />
Status : 2/10<br />
<br />
* [[User:Fradeve11|Fradeve11]] [mailto:fradeve@ubuntu-it.org fradeve@ubuntu-it.org]<br />
<br />
=== Campania ===<br />
==== Caserta (and province) ====<br />
Status 1/10<br />
<br />
* fenoxxx [mailto:fenoxxx@gmail.com] - Aversa<br />
<br />
=== Lazio ===<br />
==== Roma ====<br />
Status 7/10<br />
<br />
* Hire X 2 [mailto:hiretto@gmail.com hiretto@gmail.com] (Roma)<br />
* Darkbasic X 1 [mailto:darkbasic4(at)gmail darkbasic4(at)gmail] (Ancona)<br />
* zione X 1 [mailto:alessio.filipponio@gmail.com alessio.filipponio@gmail.com](Roma)<br />
* AntoMan X 1 (Roma) Inserisci un contatto di posta elettronica o non potremo contattarti al momento dell'acquisto!<br />
* Christian X 1(Gino46) [mailto:christian.marzola@alice.it] (ferrara) Qualcuno me lo dovrebbe spedire.<br />
* Tempix X 1 [mailto:tempix11@gmail.com tempix11@gmail.com] (Ancona)<br />
<br />
=== Liguria ===<br />
==== Genova ====<br />
Status 6/10<br />
<br />
* Luca Maranzano X 1 (liuk AT linux DOT it) [[User:liuk|liuk]]<br />
* Francesco Frassinelli X 2 (frafra AT autistici DOT org) [[User:Frafra|Frafra]]<br />
* Stefano Cutelle' X 1 (staff@ascservices.it) [[User:ascservices|ascservices]]<br />
* Luca Arrigo X 1 (morph84@gmail.com) [[User:morph|morph]]<br />
* Andrea De Gaetano X 1 (dega1999 AT gmail DOT com) [[User:Dega1999|Dega1999]]<br />
* Salvo Schiavone X 1 (salvoschiavone AT gmail DOT com [[User:Salvador|Salvador]]<br />
<br />
=== Sicilia ===<br />
==== Palermo ====<br />
Status 3/10<br />
<br />
* Giorgio Marciano' X 1 [mailto:giorgio.marciano@email.it giorgio.marciano@email.it]<br />
* Michele Puccio X 1 [mailto:puccio@eng.it michele]<br />
* Roberto Calandra X 1 [mailto:isokazi@yahoo.it roberto]<br />
<br />
==== Messina ====<br />
Status 4/10<br />
<br />
* Melug X 4 [mailto:melug@messinalug.org MeLug]<br />
<br />
=== Calabria ===<br />
==== Catanzaro ====<br />
Status 1/10<br />
<br />
* Carlo Mangani X 1 [mailto:carlo.mangani@gmail.com carlo.mangani@gmail.com] - Lamezia Terme<br />
<br />
== Macedonia ==<br />
=== Skopje ===<br />
* Kristijan Krsteski 1/10 <br /> [[User:neutrino]] <br /> [mailto:kristijan.krsteski@gmail.com]<br />
===Status ===<br />
1/10<br />
<br />
== México ==<br />
=== Ciudad de México ===<br />
* Kozapatista [[Special:Emailuser/User:kozapatista|Contact]]<br />
===Status ===<br />
1/10<br />
<br />
== [http://wiki.openmoko.org/wiki/Talk:GroupSales#The_Netherlands The Netherlands] ==<br />
(Discuss this group sale on the [http://wiki.openmoko.org/wiki/Talk:GroupSales#The_Netherlands talk page])<br />
<br />
* Marijn Kruisselbrink 1 [[Special:Emailuser/User:mkruisselbrink|Contact]]<br />
* Andy Powell 1/10 [[Special:Emailuser/User:ScaredyCat|Contact]]<br />
* Arjan Veenstra 1/10 [[User:AVee]] [[Special:Emailuser/User:AVee|Contact]]<br />
<br />
=== Gelderland ===<br />
<br />
==== Nijmegen ====<br />
* [[User:A.dre|André Disselhorst]] (Nijmegen 1x) [[Special:Emailuser/User:A.dre|Contact]]<br />
<br />
=== Limburg ===<br />
<br />
==== Griendtsveen ====<br />
* [[User:KenSentMe|Jeroen van de Nieuwenhof]] (Griendtsveen 1x) [[Special:Emailuser/User:KenSentMe|Contact]]<br />
<br />
=== Noord-Brabant ===<br />
<br />
==== Bergen op Zoom ====<br />
* [[User:Madjo|Marcel de Jong]] 1/10 [[Special:Emailuser/User:Madjo|Contact]]<br />
<br />
==== Eindhoven ====<br />
* Christ van Willegen 1 [[User:ChristW]]<br />
<br />
=== Noord Holland ===<br />
<br />
==== Amsterdam ====<br />
* Michel van Horssen 1/10 [[Special:Emailuser/User:mivaho|Contact]]<br />
* Frank Richter 1 [[Special:Emailuser/User:res|Contact]]<br />
* Eric Smith 1/10 [[User:Eric Smith]]<br />
<br />
==== Bussum ====<br />
* Remco van Zuijlen 1x [[Special:Emailuser/User:Remco|Contact]]<br />
<br />
=== Overijssel ===<br />
<br />
==== Deventer ====<br />
* Jan de Haan 1/10 [[User:Jan de Haan]] [[Special:Emailuser/User:Jan de Haan|Contact]]<br />
<br />
==== Hengelo ====<br />
* Sander Hoentjen 1/10 [[Special:Emailuser/User:Tjikkun|Contact]]<br />
* Peter Hageman 1 [[Special:Emailuser/User:PingPong|Contact]]<br />
<br />
==== Zwolle ====<br />
* Boudewijn 1/10 [[User:Boudewijn|empty user page]] [[Special:Emailuser/User:Boudewijn|Contact]]; possibly got a second person interested<br />
<br />
=== Den Haag ===<br />
<br />
==== Rijswijk ====<br />
* Fernando Martins 1x [[User:fmartins]] [[Special:Emailuser/User:fmartins|Contact]]<br />
<br />
=== Utrecht ===<br />
<br />
==== Utrecht ====<br />
* Eric Spierings 1/10 [[Special:Emailuser/User:ericsp|Contact]]<br />
* Peter van de Werken 2/10 [[Special:Emailuser/User:PWerken|Contact]]<br />
<br />
=== Status ===<br />
19/20<br />
<br />
== New Zealand ==<br />
As Telecom are using the 850MHz network for their GSM network, and Vodafone/northelia (possibly aka orcon) are using 900/1800MHz, please state which version you want. This may need more research, I'm not 100%; see [http://www.gsmworld.com/roaming/gsminfo/cou_nz.shtml] for more info<br><br />
According to jeremy list, telecom will not be rolling out GSM for four years, so the point becomes moot - no-one is likely to get an 850 gsm phone now and wait that long<br><br />
<br />
Based on info from steve (openmoko marketing) concerning weight and size, shipping via UPS will be about US$185 (NZ$23 each phone) to Auckland.<br><br />
UPS are far from the cheapest, but (again according to steve), OM have a contract with them, so this is what we are stuck with<br><br />
<br />
Someone on the community list suggested using [http://www.myus.com], a shipping company that will re-post items overseas at decent rates. They claim US$66 for a 3kg package, or NZ$8 per phone. Of course, the cost of shipping the phone from OM to the shipping company has to be added in as well.<br />
<br />
As of 2008-04-28, US$399 is worth NZ$508<br />
<br />
import duty on mobile phones is 0%[http://www.customs.govt.nz/importers/Private+Importers/Customs+Charges.htm], and GST is 12.5% so the GST added to each phone will be NZ$66; 12.5% * {508 + 23), cos we pay GST on postage too...<br />
<br />
So, the total cost of a Freerunner as part of a 10 pack, will be:<br><br />
508 + 23 + 66<br><br />
= 597<br><br />
<br />
+ any possible charges to get it posted elsewhere in New Zealand<br />
<br />
=== Auckland ===<br />
==== Auckland ====<br />
Status:7/10<br />
*Rob Paulson [[User:Myfanwy]] 900MHz<br />
**i'm quite happy to organise the purchase, if no-one has any objections. to ease any worries about me running off with the money, we could use an escrow service such as [http://safetrader.co.nz], or paypal. or does anyone have any other ideas?<br />
*Simon Wells [[User:Swel024]]<br />
*Jeremy List [[User:Jeremy-list]] mailto:quick.dudley@gmail.com (Wellington, not Auckland, will pay for courier)<br />
*David Murrell [[User:Viddy]] - [mailto:dmurrell@waikato.ac.nz] I'm in Hamilton, either courier, or I'll drive up :)<br />
*Jeremy Gray [[User:Bogdan237]] [mailto:jgra163@ec.auckland.ac.nz] Auckland, 900MHz<br />
*Glen Ogilvie [[User:Nelg]] {mailto:nelg@linuxsolutions.co.nz] Auckland, 900MHz<br />
*Xuân Baldauf [[User:xbaldauf]] {mailto:xuan--2008.05--GroupSales--wiki.openmoko.org@baldauf.org] Auckland CBD, 900MHz+1800MHz GSM. This is <u>conditional</u>: the transaction must complete by 2008-06-30, else I cannot participate, because I'm leaving the country afterwards.<br />
<br />
== Norway ==<br />
=== Nordland ===<br />
==== Bodø ====<br />
Status 2/10<br />
<br />
* [[User:AlecTBM|Alexander Frøyseth]] [mailto:alexander.froyseth@gmail.com alexander.froyseth@gmail.com]<br />
* Ole Marius<br />
* Stian Vading<br />
<br />
<br />
=== Sør-Trøndelag ===<br />
==== Trondheim ====<br />
Status 12/20<br />
<br />
*[[User:andy000|Andreas Kalvå]] [mailto:andy@samfundet.no andy@samfundet.no]<br />
Send mail om du er interessert.<br />
<br />
=== Østlandet ===<br />
==== Oslo, Akershus, Buskerud, Vestfold ====<br />
Status 20/20(30?)<br />
<br />
* [[User:Ixian|Heikki Sørum]] [mailto:heikkis@matnat.uio.no] <br/> Interessert? mail meg.<br />
* [[User:Bobkare|Knut Arne Bjørndal]] [mailto:bob@cakebox.net]<br />
<br />
== Poland ==<br />
=== dolnośląskie ===<br />
==== Wrocław ====<br />
<br />
* Special group buy site: https://www.kumulator.pl/show/group/35<br />
<br />
=== Podlaskie ===<br />
==== Suwalki ====<br />
Status 1/10<br />
* arteqw [http://wiki.openmoko.org/wiki/Special:Emailuser/Arteqw contact with me]<br />
<br />
== Portugal ==<br />
=== Aveiro ===<br />
==== Aveiro ====<br />
Status : 2/10<br />
<br />
* [[User:Ruben|Ruben Mendes]]<br />
* [[User:kuyky|Tiago Saraiva]] <br /> [mailto:destructhor88@gmail.pt]<br />
<br />
== Sweden ==<br />
If insufficient number of people, orders could be merged and remailed perhaps.<br />
<br />
Domestic remailing with Posten as A-class mail of a letter (criteria: length+width+height max 900 mm) weighing max 1 kg, without insurance should [http://www.posten.se/foretag/vara_tjanster/postageguide/postguideLetterDom.jspv cost 44 SEK]. 50 SEK more for insurance.<br />
<br />
If we end up with more than one 10-pack in Sweden, my guess is that it would probably pay to order everything in one shipment to one address in Sweden to save on the international shipping, and then remail domestically.<br />
<br />
=== Götaland ===<br />
==== Göteborg ====<br />
<br />
* [[User:Fwendt|Fredrik Wendt]] [[Special:Emailuser/Fwendt|Contact]]/wendt.se<br />
<br />
==== Malmö ====<br />
Status : 1/10<br />
<br />
* Lars Jarlvik <br /> mailto:lars@larsfactory.se<br />
<br />
=== Svealand ===<br />
==== Stockholm ====<br />
Status : 5/10<br />
<br />
* Erland Lewin <br /> mailto:erland@lewin.nu<br />
* Simon Kågström <br /> mailto:simon.kagstrom@gmail.com<br />
* Ingvaldur Sigurjonsson <br /> mailto:ingi@ultimalabor.se<br />
* Adam Johansson <br /> mailto:adam@sollentunaholm.se<br />
* Lowe Schmidt <br /> mailto:lowe.schmidt@gmail.com<br />
<br />
==== Örebro ====<br />
Status : 1/10<br />
<br />
* Anders Petersson <br /> [mailto:demitar@worldforge.org demitar@worldforge.org]<br />
<br />
==== Västerås ====<br />
Status : 1/10<br />
* Jörgen Lidholm, could join the Falun/Borlänge or Stockholm group <br /> [mailto:jorgen.lidholm@gmail.com]<br />
<br />
==== Falun & Borlänge ====<br />
Status : 4/10<br />
<br />
* [http://wiki.openstreetmap.org/index.php/User:Jth Johan Thelmén], Åke Hoff & a demo/backup<br />
* [http://wiki.openstreetmap.org/index.php/User:eagle87 Pär Eriksson], Borlänge<br />
<br />
=== Norrland ===<br />
==== Umeå ====<br />
Status : 2/10<br />
<br />
* [[User:Zash|Zash]] [[Special:Emailuser/Zash|Contact]]<br />
* [[User:Benjamin|Benjamin]] [[Special:Emailuser/Benjamin|Contact]]<br />
<br />
==== Luleå ====<br />
Status : 2/10<br />
<br />
* [[User:Mjukis|Mjukis]] [[Special:Emailuser/Mjukis|Contact]] - 2 Units. Can also join the Malmö group order.<br />
<br />
== Switzerland ==<br />
Gabriel Ambuehl would volunteer to order the initial 10pack.<br />
Alexandre Ghisoli could organize the second 10pack.<br />
Both with payment in advance (a 10pack will cost approx 3'800 USD).<br />
<br />
Probably we will organize shipping, if we cannot all move to Zürich to get our Neo.<br />
<br />
==== Shipping ====<br />
If we would ship Neos, here is the Swiss PostPac prices :<br />
<br />
{| border="1" cellspacing="0" cellpadding="2"<br />
! Description<br />
! Size [cm]<br />
! Price CHF TTC<br />
|-<br />
| Size 1<br />
| 22.9 x 14.7 x 9.9<br />
| 2.20<br />
|-<br />
| Size 2<br />
| 31.5 x 22.5 x 12.5<br />
| 2.40<br />
|-<br />
| Shipping Priority<br />
| up to 2Kg<br />
| 8.-<br />
|-<br />
| Shipping Economy<br />
| up to 2Kg<br />
| 6.-<br />
|}<br />
<br />
<br /><br />
<br />
Steve posted informations about boxes that will be out with Neo :<br />
<br />
* 10 pack : 435mm x 371mm x 119mm, approx 3kg, UPS will charge 160USD (need to be verified)<br />
* Individual pack : 178mm x 104mm x 84mm, 237 grams<br />
<br />
So size 1 will fit ! Local delivery in Switzerland will cost 8.20 for Economy or 10.20 Priority.<br />
<br />
==== Zurich ====<br />
Status : 23/20<br />
<br />
It seems that while there are 22 people listed here, actually the device number is 23, because Tobias Kündig is interested in 2 of them. This means that the total number of devices for Swiss people is 26 (23 for Zürich plus 3 for Genève). -- LucaCapello -- updated by FreeMind<br />
<br />
* Simon Wenner <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Nowic Contact]<br />
* Simon Schreiber <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Magbeat Contact]<br />
* Markus Huggler <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Magbeat Contact]<br />
* Andre Timmermann <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/darktim Contact]<br />
* Raffael Schmid <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/darktim Contact]<br />
* Pascal Weller <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/darktim Contact]<br />
* Nick Zbinden (Luzern)<br /> [mailto:nickik@gmx.ch] oder [http://wiki.openmoko.org/wiki/Special:Emailuser/nickik Contact]<br />
* Marcel Wirth <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Skarhand Contact]<br />
* Marcel Lütolf (Luzern)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/NeRo Contact]<br />
* Christian Corrodi <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Matto Contact]<br />
* Mirko Klingauf <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/RealAtaman Contact]<br />
* Marcel Jost <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Onsonic Contact]<br />
* Alexandre Ghisoli (Yverdon)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Agh Contact]<br />
* Marc Andre Tanner (Biel)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/mat Contact]<br />
* Tobias Kündig (2 Geräte) (Luzern)<br /> [mailto:info@it-media.ch]<br />
* Peter Salvisberg<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Psal Contact]<br />
* Robin Farine (Auvernier)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/rfarine Contact]<br />
* Martin Kos <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/KoS Contact]<br />
* Lorenz Schori (Bern) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Znerol Contact]<br />
* Jonas Schwarz (Lausanne) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/jnsc Contact]<br />
* Matthias Cramer (Zürich) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/cramer Contact]<br />
* Pascal Mages (Bern/Zürich) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/FreeMind Contact]<br />
<br />
==== Geneve ====<br />
Status : 4/10<br />
<br />
* Diego Abelenda<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Aelia Contact]<br />
* Luca Capello<br /> [mailto:luca@pca.it]<br />
* Nicolas Produit<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Produit Contact]<br />
<br />
== Spain ==<br />
=== Spain (Country Group Sale) ===<br />
Status: 5/10<br />
=== Madrid ===<br />
==== Madrid ====<br />
Status : 1/10<br />
<br />
* Rafael Campos <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Methril Contact]<br />
<br />
=== Zaragoza ===<br />
==== Zaragoza ====<br />
Status : 2/10<br />
<br />
* Alejandro R. Mosteo <br /> alejandro AT mosteo · com<br />
* Arturo Giner<br/>[[Special:Emailuser/artginer|Contact]]<br />
<br />
=== Barcelona ===<br />
==== Barcelona ====<br />
Status : 3/10<br />
<br />
* José Luis Pérez <br/>[[Special:Emailuser/jluis|Contact]]<br />
* David Reyes Samblas Martinez<br/>[[Special:Emailuser/mutrox|Contact]]<br />
* Sergio Arias <br/>[[Special:Emailuser/saerguio|Contact]]<br />
<br />
== UAE ==<br />
Status: 1/10<br />
* Yaser Ammar <br /> [[Special:Emailuser/Waraqa|Contact]]<br />
<br />
== USA ==<br />
=== Colorado ===<br />
==== Denver (Full) ====<br />
Status: 10/10 (includes the gentleman from Utah)<br />
* Shawn Sullivan <br /> [[mailto:shelbydz87@yahoo.com shelbydz87@yahoo.com]]<br />
* Peter Abplanalp <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/alderion Contact]<br />
* Ben Burdette <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Ansible Contact]<br />
* Tom Russell <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/tazbert Contact]<br />
* Trace <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/gnork Contact]<br />
<br />
=== California ===<br />
==== Los Angeles ====<br />
Status: 4/10<br />
<br />
* Ian Douglas <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Iandouglas Contact me here]<br />
* Matthew <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Wetmoko Contact]<br />
* Daniel <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Beaker82 Contact]<br />
* James Robertson <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/JamesRobertson Contact]<br />
<br />
==== San Diego (inc. San Diego county and surrounding areas) ====<br />
Status: 1/10<br />
<br />
Will combine with LA if too few.<br />
<br />
* Peter Naulls <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Pnaulls Contact]<br />
<br />
==== San Francisco Bay Area ====<br />
Status: 4/10<br />
<br />
* Ajit Natarajan - [http://wiki.openmoko.org/wiki/Special:Emailuser/ajitk Contact]<br />
<br />
* Dirk Bergstrom - [http://wiki.openmoko.org/wiki/Special:Emailuser/krid Contact]<br />
<br />
* Tupshin Harper - [http://wiki.openmoko.org/wiki/Special:Emailuser/tupshin Contact]<br />
<br />
* Lothar Werzinger (900MHz) - [http://wiki.openmoko.org/wiki/Special:Emailuser/Elektrolott Contact]<br />
<br />
==== Monterey ====<br />
Status: 2/10<br />
<br />
* Cry Regarder <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Cry_Regarder Contact]<br />
<br />
=== Midwest (combine Indiana / Iowa / Kentucky / Tennesee / Texas) ===<br />
Status: 5/10<br />
* Geoff Ruscoe [[Special:Emailuser/Geocode|Contact]] - Louisville, KY<br />
* Steven M [[Special:Emailuser/Montgoss|Contact]] - <br />
* Joseph Booker [[Special:Emailuser/Sargas|Contact]] - Chicago<br />
* Bryan DeLuca [[Special:Emailuser/Stupkid|Contact]] - Fort Worth, TX<br />
* Casey Harkins [[Special:Emailuser/Charkins|Contact]] - Madison, WI<br />
<br />
=== Indiana / Kentucky ===<br />
Status: 4/10<br />
* Dan Staley [[Special:Emailuser/Pyrasi|Contact]] (Kentucky)<br />
* Donnie Jones [[Special:Emailuser/Donniejones18|Contact]] (Lexington, KY)<br />
* John Sterling [[Special:Emailuser/Sterling|Contact]] (Lexington, KY)<br />
<br />
=== Ohio / Michigan ===<br />
Status: 2/10<br />
* David Pais [mailto:davioh2001@yahoo.com email]<br />
* Dave Ludlow [[Special:Emailuser/adsllc|Contact]]<br />
* Adam Steele [mailto:adam@laurasteele.net Contact]<br />
<br />
=== Washington ===<br />
==== Seattle ====<br />
Status: 1/10<br />
* Jon Pomeroy [[Special:Emailuser/Jepomeroy|Contact]]<br />
<br />
=== Tennessee ===<br />
==== Memphis ====<br />
Status: 1/10<br />
* Peter O'Connor <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/poconnor Contact]<br />
<br />
=== Texas ===<br />
==== Austin (7/10) ====<br />
* Dale Schumacher [[Special:Emailuser/dalnefre|Contact]]<br />
* Michael Cosby [[Special:Emailuser/mcosby|Contact]]<br />
* Paul Jimenez [[Special:Emailuser/pj|Contact]]<br />
* Charles [[Special:Emailuser/rbn|Contact]]<br />
* Anthony Kitchin [[Special:Emailuser/akitchin|Contact]]<br />
* Carl [[Special:Emailuser/texatopia|Contact]]<br />
* Robert [[Special:Emailuser/SHaRK|Contact]] (Houston)<br />
<br />
==== Dallas/Fort Worth (2/10) ====<br />
* Philip White [[Special:Emailuser/pmw|Contact]] Dallas<br />
* Bryan DeLuca [[Special: Emailuser/Stupkid|Contact]] Fort Worth<br />
<br />
=== Mid-Atlantic ===<br />
==== Virginia====<br />
===== Virginia Tech (1/10) =====<br />
* Lally Singh [[Special:Emailuser/lally|email]] -- yeah, if you're ordering anywhere in VA, lemme know.<br /><br />
===== Richmond (2/10)=====<br />
* Philippe Gerard [[Special:Emailuser/feydreva|Contact]]<br/><br />
*Steve Watson mailto:ssw0213@gmail.com<br/><br />
<br />
==== New York ====<br />
Status: 2/10 or 3/10<br />
<br />
* Bert Hartmann <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/BertHartm Contact me here]<br />
* Michael Cole mailto:mjcole137@gmail.com <br /><br />
* Jake Thebault-Spieker (probably, may not be able to afford it) [http://wiki.openmoko.org/Spcial:Emailuser/Summatusmentis Contact me here]<br />
<br />
==== Maryland (2/10)====<br />
* Paul Buede mailto:paul@buede.com <br /><br />
* Charles Lohr<br />
* Alex (DC/Rosslyn; not 100% sure that will be able to afford it) [[Special:Emailuser/rakukin|Contact]]<br />
<br />
=== Massachusetts ===<br />
Status: 2/10<br />
* Benjamin Moody [[Special:Emailuser/FloppusMaximus|Contact]]<br />
<br />
* Ken Young (Note, if we're not up to 10/10 on the day<br />
the Freerunner is announced, I'm going to drop out and<br />
order individually).[[Special:Emailuser/Dolson|Contact]]<br />
<br />
== UK ==<br />
<br />
* Stroller (Milton Keynes, can travel) <br />mailto:stroller@stellar.eclipse.co.uk 01908 663 513. <br />Thinks that breaking the UK up into regions - at least outside London - is silly. There are unlikely to be 10 people in $your_town who want a Freerunner, so some posting of Freerunners will surely be required; see [http://wiki.openmoko.org/wiki/Talk:GroupSales#Oxford the talk page]. This is the same cost anywhere in the UK.<br />
<br />
=== Scotland ===<br />
==== Edinburgh ====<br />
Status : 3/10<br />
<br />
* Joe Wells (Edinburgh) [http://wiki.openmoko.org/wiki/Special:Emailuser/jbw Contact]<br />
* Dave Ball (Edinburgh) [http://wiki.openmoko.org/wiki/Special:Emailuser/Daveb Contact]<br />
* Stuart MacKinnon(Livingston) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/hoagster Contact]<br />
<br />
=== England ===<br />
<br />
==== Hampshire ====<br />
<br />
http://www.hants.lug.org.uk/cgi-bin/wiki.pl?FreerunnerBulkBuy<br />
<br />
(Sorry, we set up the page before we knew about this one)<br />
<br />
==== London ====<br />
<br />
Status : 7/10<br />
<br />
* Juergen Schinker <br /> mailto:ba1020@homie.homelinux.net<br />
* aled <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/aled Contact]<br />
* Robert Piasek (actually in Southampton)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Queen6 Contact]<br />
* Tom Scholl (Cambridge, travel to London now and then anyway so could pick up) <br /> [mailto:thomasscholl@gmail.com]<br />
* Weiss (Cambridge, could collect from London) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Weiss Contact]<br />
* Neil Bentley (in Wiltshire) [http://wiki.openmoko.org/wiki/Special:Emailuser/Ohnez Contact]<br />
* rhn (one or two sets) <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/rhn Contact]<br />
<br />
==== Oxford ====<br />
<br />
Idea to re-ship within the UK, see [http://wiki.openmoko.org/wiki/Talk:GroupSales#Oxford talk]<br />
<br />
Status : 3/10<br />
<br />
* Tim Coggins<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/sonicated Contact]<br />
<br />
* James Olney <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/Webjames Contact]<br />
* David Pottage (actually in Reading)<br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/chrestomanci Contact]<br />
<br />
==== West Midlands ====<br />
Status : 2/10<br />
<br />
* Mo Abrahams (Walsall) <br /> mailto:moabrahams@dashavoo.com<br />
* Bin Zong (actually in Birmingham)<br /> [mailto:hunter_00zb@hotmail.com]<br />
<br />
== Latvia ==<br />
=== Riga ===<br />
==== Riga ====<br />
Status : 1/10<br />
* Ilya <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/VRGhost Contact]<br />
<br />
== Singapore ==<br />
Status : 2/10<br />
* Wee Kiam Peng [http://wiki.openmoko.org/wiki/Special:Emailuser/Jipi Contact]<br />
* Chen Ruo Fei [http://wiki.openmoko.org/wiki/Special:Emailuser/Crf Contact]<br />
<br />
== Israel==<br />
Status : 2/10<br />
* Ofer Herman <br /> [http://wiki.openmoko.org/wiki/Special:Emailuser/oferhe Contact]<br />
* [http://wiki.openmoko.org/wiki/Special:Emailuser/Talba Talba]<br />
<br />
== Czech Republic ==<br />
=== Brno ===<br />
Status : 11/10<br />
* Martin Šenkeřík - [[Special:Emailuser/ohin|Contact]]<br />
Jakmile budu mít nějaké konkrétnější informace budu vás kontaktovat. Mám ale problém s financováním všech 10 telefonů při objednávání. Buď budu potřebovat, aby mně aspoň půlka z vás poslala peníze předem, nebo kdyby se našel někdo, kdo mně může se zafinancováním pomoct (zaplatil by půlku telefonů a ty be se potom rozeslaly na dobírku nebo předaly osobně) tak se můžeme sejít osobně. Vyskytuji se v Brně a ve Zlíně.<br />
* Radek Bartoň - [[Special:Emailuser/Blackhex|Contact]]<br />
* Martin Holec - [[Special:Emailuser/Martix|Contact]] (Buď přeposlat směrem Zlín nebo osobní odběr někde v Brně.)<br />
* Jozef Mlich - [[Special:Emailuser/joejoe|Contact]]<br />
* Radek Machulka - [[Special:Emailuser/Werty|Contact]] (ja teda taky nejsem z Brna, ale klidne si pro to prijedu...)<br />
* Tom Varga - [[Special:Emailuser/Varg|Contact]]<br />
* Ales Dvorak - [[Special:Emailuser/Setr|Contact]] '''contact ti nefunguje'''<br />
* Pavel Kovar - [[Special:Emailuser/Fox|Contact]](Pokud mi to nekdo z Brna preposlete/předáte na Vsetin případně do konce června Ostrava)Peníze pošlu předem.<br />
* David Kozub - [[Special:Emailuser/Zub|Contact]] (Zlin, idealni by byla Praha, ale evidentne jsem sam, prinejhorsim i to Brno)<br />
* Miloslav Machotka - [[Special:Emailuser/Machy|Contact]] (Peníze pošlu klidně předem.)<br />
* Michal Pěnka - [http://michal.penka.name/kontakt Contact] (Preferuji dobírku, ale klidně pro to zajedu do Brna)<br />
<br />
== Slovak Republic ==<br />
=== Bratislava ===<br />
Status : 1/10<br />
* František Horínek - [[Special:Emailuser/PipBoy2000|Contact]]<br />
<br />
== Croatia ==<br />
Status : 4/10<br />
* w00t - [[Special:Emailuser/W00t|Contact]]<br />
* matija - [[Special:Emailuser/Matija.z|Contact]]<br />
* valajbeg - [[Special:Emailuser/valajbeg|Contact]]<br />
* kost - [[Special:Emailuser/kost|Contact]]<br />
(maybe we should make one group for bosnia, croatia & serbia together?)<br />
[[Category:Community]]</div>Lallyhttp://wiki.openmoko.org/wiki/Openmoko_Local_Groups:_VirginiaOpenmoko Local Groups: Virginia2008-05-05T09:31:23Z<p>Lally: </p>
<hr />
<div>Welcome to the Virginia OpenMoko page!<br />
<br />
This group is for anyone in Virginia.<br />
<br />
{|border=1<br />
!Name<br />
!Skills<br />
!Level of Interest<br />
!Location<br />
!Other<br />
|-<br />
|Josh<br />
|C++, Java<br />
|Cancelled shipment of SH1. <br />
We'll see if they've got their ordering process fixed by October.<br />
|Tidewater<br />
|<br />
|-<br />
|Joshua<br />
|C++, LAMP, PKI<br />
|Debating SH1<br />
|Norfolk<br />
|<br />
|-<br />
|Paul Bohme<br />
|C/C++, Linux, all-around-geek<br />
|Have SH1<br />
|Fairfax<br />
|<br />
|-<br />
|Lally Singh<br />
|C/C++, compiler development, operating systems, VR<br />
|Will get one asap<br />
|Virginia Tech (Springfield Native)<br />
|<br />
|}<br />
[[Category:Community]]<br />
[[Category: OpenMoko Local Groups| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/OpenmokoFrameworkOpenmokoFramework2008-04-28T20:23:50Z<p>Lally: fixed spelling.</p>
<hr />
<div>''Note: This is the (ongoing) description of the new framework architecture. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2''<br />
<br />
=Purposes=<br />
<br />
* '''Give people the infrastructure to create solid and exciting software products based on the Openmoko platform'''<br />
* '''Support competing UIs while collaborating on developing services'''<br />
* '''Encourage framework users (e.g. application developers) to also contribute to the framework'''<br />
<br />
=Requirements=<br />
<br />
* Make it simple<br />
* Concentrate on core services<br />
* Be programming language agnostic<br />
* Be UI toolkit agnostic<br />
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API<br />
<br />
=How to achieve that technically=<br />
* Chose [[Dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.<br />
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).<br />
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.<br />
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.<br />
<br />
=Mandatory Readings=<br />
<br />
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]<br />
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]<br />
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]<br />
<br />
=What this is NOT about=<br />
<br />
This initiative does not cover low level services such as<br />
* Bootloader,<br />
* Kernel, or<br />
* System Init.<br />
<br />
This initiative does not cover high level services such as<br />
* X-Window-System,<br />
* Window Manager,<br />
* UI Toolkits,<br />
* Application Launchers,<br />
* Applications, or<br />
* Fancy UIs.<br />
<br />
=Overview=<br />
<br />
... picture ...<br />
<br />
=Components=<br />
<br />
... discussion of subsystem purposes ...<br />
<br />
==Low Level==<br />
<br />
===Device===<br />
...<br />
<br />
===GSM===<br />
This involves three components:<br />
<br />
* GSM 07.10 (Multiplexing Daemon)<br />
* GSM 07.07 (Telephony)<br />
* GSM 07.05 (SMS)<br />
<br />
===Bluetooth===<br />
<br />
We base on the official Linux Bluetooth subsystem here, which is [http://www.bluez.org BlueZ]. <br />
<br />
===Network===<br />
<br />
Options: Networkmanager or Intel Connection Manager<br />
<br />
===GPS===<br />
<br />
We base on Gypsy here.<br />
<br />
==High Level==<br />
<br />
===PIM===<br />
* intelligent storage database<br />
<br />
===Events===<br />
* signaling events via I/O (ringing, blinking, vibrating)<br />
* might use fd.o notification API<br />
<br />
===Usage===<br />
* coordinating application I/O requirements (think ''reference counting'' for I/O requirements)<br />
* might use fd.o policy API<br />
<br />
===Preferences===<br />
* settings database<br />
<br />
===Context===<br />
* Intelligent context API, integrating location as one -- among other -- sources<br />
<br />
=Tasks=<br />
<br />
==What's there==<br />
* bluez<br />
* gypsy<br />
* geoclue<br />
* py-odeviced<br />
* pygsmd<br />
* gsmd0710muxd<br />
* networkmanager or intel connection manager<br />
<br />
==What's missing==<br />
* py-ophoned<br />
* pimd (GSoC 2008 project)<br />
* eventd<br />
* usaged<br />
* preferencesd<br />
* contextd<br />
<br />
=The role of Python=<br />
<br />
Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the Dbus APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.<br />
<br />
Once the APIs have been used by application programmers, we can start profiling and possibly reimplementing some of the services with daemons written in Vala. Reimplementing things in RPython would be much easier than Vala and much of the benefits of python remain.<br />
<br />
=Team & Roadmap=<br />
<br />
... talk about the team and the roadmap ...</div>Lallyhttp://wiki.openmoko.org/wiki/Main_PageMain Page2008-03-20T13:32:36Z<p>Lally: Replaced OpenMoko with Openmoko wherever it wasn't part of a WikiLink</p>
<hr />
<div>{{Languages|Main_Page}}<br />
__NOTOC__<br />
__NOEDITSECTION__<br />
__NOTOC__<br />
{| cellspacing="4" cellpadding="0" style="padding: 2%; margin:0em 0em 1em 0em; border:1px solid #c8bbbf; background:#ECE5B6; width:100%" <br />
| <big>'''Welcome to the [[Openmoko]]&trade; public Wiki'''</big><br><br />
|}<br />
<br />
[[Image:GTA02.gif |200px|right|frontside]]<br />
Openmoko&trade; is an [http://en.wikipedia.org/wiki/Open_source Open Source] project under[[License| GPL and LGPL license]]. The aim of Openmoko is to build the world's first free mobile platform which runs a full X server and can therefore run most X applications. You can install any [[OpenMoko]] software over the whole range of [[OpenMoko-supported hardware|supported phones]], and if you upgrade your phone, you won't lose that software. Bugs fixed on any phone are fixed on all. <br />
<br />
The [[Neo1973 | Neo 1973 (GTA01)]] from [[FIC]] is the first of many phones that Openmoko may be used on. You can go to [https://direct.openmoko.com/ Openmoko Online Shop] to get the sales informaiton. [[Neo FreeRunner | Neo FreeRunner (GTA02)]] the new generation Openmoko mobile phone is not yet available - press [[Neo FreeRunner GTA02 Hardware| here]] to get more hardware information. Otherwise, scroll down this page for info on the development status , or you can add your nickname to those interested buying the Neo FreeRunner at [[Buying_Interest_List|Buying Interest List]].<br />
<br />
The [[Openmoko]] project is a community that anyone can join, to help design their ideal phone. Please join us in collaborating on the Openmoko project through any of the [[Development resources | project resources]] including this Openmoko wiki. Please see the [[Help:Contents | wiki editing help]] page for information on making contributions to this wiki. A [[Meet the Core Team | core team]] of developers funded by FIC, Inc. leads the project.<br />
<br />
To the novice, can start by use [[introduction]] page , [[Introduction#Photos|photos]], [[Introduction#Videos|videos]] and [[OPENMOKO WIKI Official Index Page | Openmoko Official Index Page]], to take the overview of Openmoko and wiki. Moreover, the usual [[FAQ | Frequently Asked Questions]] (FAQ) and [http://lists.openmoko.org/mailman/listinfo/| mailing list] pages might be helpful. Developers may find the [[ChangeLog | change log]] an important resource. <br />
<br />
{{warning|'''The Openmoko GUI applications are not suitable for end users yet.''' They are still in beta. Do not expect to always and reliably make and receive calls from the Openmoko GUI. Thanks to the openness of the FIC Neo1973 hardware, there is also an alternative to the Openmoko GUI: Qtopia 4.3.x is released under GPL and is at the edge of being usable for phone use.}}<br />
<br />
{| class="wikitable" cellspacing="0" cellpadding="5" width=100%<br />
! width=100% colspan="2" style="background:#C8B560;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Latest status<br />
|-<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-left:5px solid white;border-bottom:5px solid white;" | <br />
* The latest Qtopia snapshot can now be successfully used to make and receive calls, to send and receive SMS and use Contacts for both. However, if you do not enable suspend, one battery will only last 3-5 hours, but in suspend, incoming calls do not wake up Qtopia! See [[Qtopia on Neo 1973]] for instructions.<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* The [http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/ latest build] can make and receive calls most of the time. Power management (suspend, standby time) are still experiencing problems. Reports on the new snapshots built daily (will break sometimes) are [[Snapshot_review|here]]<br />
* For the latest status updates, see [[Community_Updates|Community Updates]]<br />
* To get the overview of Openmoko Wiki, see [[Openmoko Wiki Official Index Page]].<br />
|}<br />
<br />
{| class="wikitable" cellspacing="0" cellpadding="5" width=100%<br />
! width=100% colspan="2" style="background:#ADA96E;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | What's Your Interest?<br />
|-<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-left:5px solid white;border-bottom:5px solid white;" | <br />
* [[Basic End-user]] - Information for end users who want basic functionality and no surprises<br />
* [[Advanced End-user]] - Information for advanced end-users who want advanced and experimental functionality but who are not programmers<br />
* [[Business Development]] - Exchange of commercial opportunities for promoting widespread end-user acceptance.<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them<br />
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries<br />
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board<br />
|}<br />
<br />
{| class="wikitable" cellspacing="0" cellpadding="5" width=100%<br />
! width=100% colspan="2" style="background:#C9BE62;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | System Specs<br />
|-<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-left:5px solid white;border-bottom:5px solid white;" | <br />
* [[Neo1973_hardware|Neo 1973 (GTA01)]] - Specs of original Neo 1973 (GTA01) Hardware<br />
* [[Neo_FreeRunner_GTA02_Hardware|Neo FreeRunner (GTA02)]] - Specs of Neo FreeRunner (GTA02) Hardware<br />
|valign="TOP" width="50%" style="background:#FAF8CC;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* [[OpenMoko Core Applications]] - Applications included in the core build of Openmoko<br />
* [[OpenMoko Community Applications]] - Featured downloadable applications from the Openmoko community<br />
|}<br />
<br />
{| class="wikitable" cellspacing="0" cellpadding="5" width=100%<br />
! width=33% style="background:#ff9900;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | General<br />
! width=33% style="background:#ff6633;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Developer Guides<br />
! width=33% style="background:#cc3333;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Developer Reference Documentation<br />
|-<br />
|valign="TOP" style="background:#F4F4F4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |<br />
* [[Development resources | Project Resources]] - Provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | IRC]], and other software development oriented resources.<br />
<br />
* [[Current events]] - Information on both past and future events where FIC or Openmoko had or will have a presence.<br />
* [http://forums.makeopensource.com/ Unofficial Openmoko Forums] - Everyone is invited to collaborate with Openmoko users and developers on the forums.<br />
* Most of the documentation and Wiki assumes you are using Linux; here are some notes for users of [[Other OSes]].<br />
* [[MacOS_X|Mac OS X]] - Information specific for those who use Mac OS X<br />
* [[OpenLab]] - A physical area where Openmoko can interact with FOSS community<br />
<br />
'''Administrative + Organizational'''<br />
* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.<br />
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.<br />
* [[Hear Me FIC]] - Information to help FIC know what the community wants.<br />
* [[Listen Up Community]] - Community's To-Do-List<br />
* [[Wiki Issues]] - problems/requests regarding this Wiki<br />
<br />
|valign="TOP" style="background:#F4F4F4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* [[Getting Started with your Neo1973]]<br />
* [[installation_guide|A guide for flashing and emulating the openmoko software]] <br />
** [[Flashing_openmoko|Flashing Neo1973 with the kernel, the root filesystem and optionally u-boot.]]<br />
** [[MokoMakefile|Building Openmoko using the MokoMakefile]]<br />
** [[Application Development Crash Course]] -A very basic how-to for the new people. <br />
** [[OpenMoko2007.2|Building Openmoko 2007.2]]<br />
** [[Building OpenMoko 2007.1 from scratch]]<br />
*** [[Building a hello world application]]<br />
*** Old [[Building OpenMoko from scratch (pre-BBT)]]<br />
** [[Running OpenMoko on PC]]<br />
*** [[Getting OpenMoko working on host with Xoo]]<br />
*** [[Getting OpenMoko working on host with Xephyr]]<br />
*** [[How to run OpenMoko Apps on PC]]<br />
*** [[OpenMoko under QEMU]]<br />
*** [[Test Openmoko Emulation with chroot image|Test Openmoko Emulation with a Prebuilt chroot Image]]<br />
* [[Migration to bad block tolerant builds]]<br />
* [[Booting from SD]]<br />
* [[DailyBuiltImages|Getting daily built images]]<br />
<br />
|valign="TOP" style="background:#F4F4F4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;"| <br />
'''Hardware Reference Documentation'''<br />
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].<br />
* The [[Neo1973 Hardware]] page provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB photographs are also included. A [[Disassembling Neo1973 | photo disassembly story]] may be an interesting starting place.<br />
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] is also provided.<br />
<br />
'''Software Reference Documentation'''<br />
* Architectural<br />
** [[OpenMokoFramework]] - The Openmoko Application Framework<br />
* [[Neo1973 host software]]<br />
* Device Software<br />
** Low-Level<br />
*** [[u-boot]] - The bootloader we use, including documentation for our modifications<br />
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications<br />
** Userspace<br />
*** [[binary compatibility]]<br />
*** [[gsmd]] - the GSM daemon managing the GSM Modem<br />
*** [[gpsd]] - the AGPS (Assisted GPS) daemon<br />
|}<br />
<br />
{| class="wikitable" cellspacing="0" cellpadding="5" width=100%<br />
! width=33% style="background:#99ccff;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Openmoko-specific Development<br />
! width=33% style="background:#B3DDF4;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Openmoko Miscellaneous Development<br />
! width=33% style="background:#00ccff;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Miscellaneous<br />
|-<br />
|valign="TOP" style="background:#F4f4f4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* [[Roadmap]] - Roadmap for further Openmoko development<br />
* [[OpenEmbedded]] - The distribution-building framework<br />
* [[Toolchain]] - The toolchain we use for compilation<br />
* [[OpenMoko]] - The Openmoko distribution<br />
** [[OpenMoko2007]] - The first intended release of it<br />
** [[OpenMoko2007.2]] - An improved release with more formalized style guidelines.<br />
** [[Userspace root image]]<br />
* [[Test Plans]] - How we test our phones<br />
* [[Prototypes]] - Tracking prototypes<br />
* [[GSM network registration]] - Tracking network registration status in the world<br />
<br />
'''User Interface Related'''<br />
* [[GUI Style Guidelines]] -- New for [[OpenMoko2007.2]]<br />
* [[Look & Feel]]<br />
** [[Artwork]]<br />
* [[Applications|Application Roadmap]]<br />
* [[Widgets]]<br />
** [[Widget Inheritance Graph]]<br />
* [[Application UI Design Recommendations]]<br />
<br />
|valign="TOP" style="background:#F4f4f4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |<br />
* [[Thesis work]] <br />
* [[Freshman todo]]<br />
* [[Templates]]<br />
* [[PIM Storage]]<br />
* [[Coding Guidelines]]<br />
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the Openmoko SDK]]<br />
* Alternative distributions for [[Neo1973]] GTA01: [[Angstrom on Neo1973]], [http://pokylinux.org Poky] [http://www.usome.com](instructions needed!)<br />
* [[License]] - How we license our code<br />
* [[Development resources]] - Describes resources for developers (lists, svn, ...)<br />
* [[Neo1973 Phase 0]] - Information for Phase 0 device owners<br />
* [[Wishlist:Neo1973 P0 Review]] - Impressions of the Phase 0 hardware device, also the Phase 0 FAQ<br />
* [[Neo1973 Phase 1]] - Information for Phase 1 device owners<br />
* [[Wishlist:Neo1973 P1 Review]] - Impressions of the Phase 1 hardware device<br />
* [[External Feeds]] - List of feeds from people blogging about Openmoko<br />
<br />
|valign="TOP" style="background:#F4f4f4;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" | <br />
* [[WiFi support in OpenMoko]]<br />
* [[Neo1973 and Windows]]<br />
* [[Press Coverage]] - What the press says about the Openmoko project<br />
* [[mFAQ]] - The Openmoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the Openmoko project<br />
* [[OpenMoko Core Applications]] - Applications (GUI based) currently included in the main/core build of Openmoko <br />
* [[Wish List]]s: [[Wish List - Hardware|Hardware]], [[Wishlist:BuiltInScriptingLanguage|Scripting Languages]], [[Wish List - OpenMoko Ringtones and Sounds|ringtones and sounds]]<br />
* [[Media Content]] - What types of media on the device can we use (that is non-software)?<br />
* [[Testimonials]] - How did you get to Openmoko?<br />
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you put money aside for Neo1973? Put your nick here.<br />
* Comparison with the [[iPhone]]<br />
* [[Translation]] of Openmoko<br />
* Project applications for Google's [[Summer of code]]<br />
* Purchase Openmoko [[SWAG]] T-Shirts!<br />
* The Openmoko [[Trademark Policy]]<br />
|}<br />
<br />
The members of the Openmoko community would like to thank FIC Inc. for their continued leadership of the Openmoko project.<br />
<br />
<span id="bottom"></span><br />
<br />
[[Category:Information| ]]<br />
[[Category:Categories| ]]</div>Lallyhttp://wiki.openmoko.org/wiki/User:LallyUser:Lally2008-02-19T00:57:57Z<p>Lally: </p>
<hr />
<div>Grad student at Virginia Tech.<br />
<br />
Currently working on scalability of virtual environments. Past work in embedded systems and compilers.</div>Lally