Re: om2009/paroli status
On Mon, Aug 3, 2009 at 7:27 PM, Laszlo KREKACS wrote: > Thank you very much for your offer, I will compile my list of > questions, and shoot at you;) > > Besides, I would like to talk with you, how can we more collaborate... No problem. You can sometime find me on freenode IRC as charlie137 (usually online around 1pm to 4pm GTM). Cheers, -- Guillaume Chéreau blogs : http://charlie137.blogspot.com/, http://charlie137-2.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: om2009/paroli status
On Mon, Aug 3, 2009 at 6:42 AM, Laszlo KREKACS wrote: > There are many ongoing work, which needs to be integrated into > paroli. There are two branches by Dietrich, namely tacheles > and rebase. Where tacheles needs some very deep (tichy/paroli) > knowledge, to be able to integrate into paroli. Hello Laszlo, at least for some of the issues concerning tichy, you can look into the actual tichy code, still hosted on its google code website [1]. I don't think you will be able to directly merge from tichy to paroli, for both projects have diverged too much, but I am sure you can get some ideas from it. Beside, even though I stopped working on paroli long before Mirko, I still understand how the core works ; contact me by email (or on this list) if you have any question about it, I can have a -quick- look at it. Regards, -Gui [1] http://code.google.com/p/tichy/ -- Guillaume Chéreau blogs : http://charlie137.blogspot.com/, http://charlie137-2.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tichy version 1.1.0 released
Yes, tichy is *not* a distribution. It is a software. It can run on any distribution that provides the FreesmartPhone dbus services. Then, I mostly tried it on debian, I know there are some issues with SHR and FSO. One of them being that the python-xlib package is missing, and that prohibits tichy from running the terminal or media player applets. On Mon, Jun 1, 2009 at 9:07 AM, jeremy jozwik wrote: > so this runs like a package over SHR? so no reflashing is needed, just > install and poke around? > > On Sun, May 31, 2009 at 9:27 PM, Guillaume Chereau > wrote: >> >> Hello everybody ! >> >> This is the announcement for the release of tichy version 1.1.0. This >> is the second release, coming 2 months after the first one. >> >> For those who don't know, tichy is a python applets manager aimed >> toward telephony applications. I uploaded a video [0] on youtube >> showing how the interface looks like. We can also see some >> screen-shots from the google code page [1] >> >> The release notes, with the list of changes can be seen here [2. >> Beside a lot of internal cleaning, the biggest changes are : >> - improved widget style system >> - improved PIM support >> - improved text editor >> - improved terminal application >> - added unit tests >> >> I provide a package for both debian and SHR/FSO. It has been mostly >> tested on debian, and some things may not work very well on other >> distributions. I hope this will interest people. I would like to >> know if any maintainers of distributions would be interested to add >> tichy into there feeds. >> >> Looking forward for comments, >> >> Cheers, >> Guillaume >> >> [0] http://www.youtube.com/watch?v=Zv8t3XtNF5w >> [1] http://code.google.com/p/tichy/ >> [2] http://tichy.googlecode.com/svn/release/1.1.0/README >> >> -- >> Guillaume Chéreau >> blogs : http://charlie137.blogspot.com/, http://charlie137-2.blogspot.com/ >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- Guillaume Chéreau blogs : http://charlie137.blogspot.com/, http://charlie137-2.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tichy version 1.1.0 released
Hello everybody ! This is the announcement for the release of tichy version 1.1.0. This is the second release, coming 2 months after the first one. For those who don't know, tichy is a python applets manager aimed toward telephony applications. I uploaded a video [0] on youtube showing how the interface looks like. We can also see some screen-shots from the google code page [1] The release notes, with the list of changes can be seen here [2. Beside a lot of internal cleaning, the biggest changes are : - improved widget style system - improved PIM support - improved text editor - improved terminal application - added unit tests I provide a package for both debian and SHR/FSO. It has been mostly tested on debian, and some things may not work very well on other distributions. I hope this will interest people. I would like to know if any maintainers of distributions would be interested to add tichy into there feeds. Looking forward for comments, Cheers, Guillaume [0] http://www.youtube.com/watch?v=Zv8t3XtNF5w [1] http://code.google.com/p/tichy/ [2] http://tichy.googlecode.com/svn/release/1.1.0/README -- Guillaume Chéreau blogs : http://charlie137.blogspot.com/, http://charlie137-2.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ain't it funny..
On Tue, May 5, 2009 at 4:09 PM, Rui Miguel Silva Seabra wrote: > On Tue, May 05, 2009 at 01:22:03PM +0530, rakshat hooja wrote: >> On Tue, May 5, 2009 at 11:57 AM, Risto H. Kurppa wrote: >> >> > The community work seems to be slowing down now (because of the >> > summer?) and the the community doesn't seem to be pushing together for >> > One Working Distro. We have about 15 distributions around but as far >> > as I know (I haven't tested them all..), they all are 'developer >> > skills required', not 'consumer friendly'. We've had Freerunner around >> > now for about a year and there's still not a proper web browser around >> > (packaged, 'just works'). Slow/buggy/not supporting JavaScript/etc... >> > http://wiki.openmoko.org/wiki/Browser_review >> > >> > OM2009 testing 2 was released some days ago. So far ~3 e-mails on the >> > list about it. >> > New version of Mokomaze was released some days ago, too. Around 50 mails. >> > To me this tells that people are more interested in Mokomaze than OM2009. >> > >> > But still, we have open hardware that can be used as a daily phone. >> > >> > r >> > >> > >> >> I have just moved from 2008.12 Kustomizer to SHR Testing and it works as a >> daily phone just fine. Chatted on pidgin for a long time yesterday without >> any problem for the first time. I shifted as I am traveling for the 2 months >> and wont be in office for regular updates so needed a stable phone for >> calling and sms. >> >> I think once paroli becomes non full screen (if it already has announcement >> needed) more people will be interested in OM 2009 as they can have a stable >> phone and also play mokomaze > > Mirko helped me with this! > > Edit /etc/paroli.cfg (or /etc/paroli/paroli.conf, look for it since I don't > know > from heart and the phone is in another room), and set to true the activated > status of "advanced" and restart paroli. > > Then press aux for about 2 seconds until the menu appears, select phone, then > profile, then illume. WARNING: be tolerant and wait a few seconds (maybe 10 at > most) until the UI stabilizes. > > Have fun! > > Rui > > -- > Grudnuk demand sustenance! > Today is Setting Orange, the 52nd day of Discord in the YOLD 3175 > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > I am also still working on Tichy [1] when I have time (that is not so much I am afraid). I plan a new release soon. The next version will (hopefully) have : full screen switch, improved keyboard, a new style, a terminal application, support for exporting PIM data to org-mode format, and a lot of code cleaning. -gui [0] http://code.google.com/p/tichy/ -- http://charlie137.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tichy now hosted on google code + release 1.0.0
On Thu, Apr 9, 2009 at 12:00 AM, Leonti Bielski wrote: > So after using it for a while I can say that I'm impressed. > > When I first saw tichy on FSO distribution it was slow and I thought > nothing would come out of it. > Thanks for proving me wrong! > I like it's distribution independent approach - It has it's own > keyboard and graphical toolkit - must be a lot of work! > > The only thing is that while in fullscreen mode you can run nothing > except for tichy. I didn't find a way to switch between full screen > mode and normal one. > > Also, can you add easier case change for the keyboard? Ruight now if I > wan to write uppercase I have to go through all keyboard to get back > to small letters. > > But in overall I like it, and I see that it has made a lot of progress. Thanks ! you just encouraged me to work on the next release of tichy. Starting other applications from tichy is indeed a problem, but there is an experimental applet -contribution from Michael "Goodwill"- that allow to do that. I want to improve this for the next release. There is currently no way to switch between fullscreen and normal mode, I will try to implement this, shouldn't be a problem. The keyboard needs a lot of work too, it is still too slow (I have some idea why), and as you say, not very good for switching modes. btw : for some reason, tichy is faster on debian. I think this is because the ipkg I did didn't compile the C file with optimisation on. I will also try to solve this. All in all, that would roughly be my TODO list for next release : * Redo the Service system (it is too slow and complicated right now.) * Improve the user interface code (too slow as well, and a little bit messy.) * Add a GTK backend (that is working already, I just need to make it easy to configure) * If possible, improve the keyboard. * Being able to start external applications. * Start to work on tests suits, using py.test [0] module. As I said, I can't really predict how much time I will have to work on it, so I prefer not to give any date for the next release. Thanks again for your inputs ! cheers, Guillaume [0] http://codespeak.net/py/dist/test.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tichy now hosted on google code + release 1.0.0
On Tue, Apr 7, 2009 at 7:16 AM, Leonti Bielski wrote: > Hello! > Thanks for your work! > I have a problem - when I start tichy it gives me just black screen :( Can you try to start it form command line : export DISPLAY=:0 tichy and send me the output. - gui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: auimd-0.2, a user interface for mobile devices (and especially the FreeRunner !)
Hello Pierre, Ha ! I just rear your announcement after I sent mine for a very similar project :O I am going to have a look at AUIMD for sure tomorrow (it is late here in taiwan) I like the idea of using your application as a simple x window manager to start other application embedded into it ! Nice screen shots, it looks very promising ! Guillaume 2009/4/7 Pierre Hébert : > Hello List ! > > I am pleased to announce the availability of AUIMD version 0.2. > In short AUIMD is a user interface targeted at mobile devices, written > with PyQt4. Auimd is both a sort of fullscreen X11 window manager, and a > small "framework" suitable for rapid and easy build of new python/Qt4 > applications. > AUIMD works best on the FreeRunner and relies on FSO for telephony and > other services, but it can also be used on other devices with VGA/QVGA > screens. > This second release includes a minimal phone application, enough to send > and receive calls, but no more. Use it with extreme care as it has been > tested with only one setup ! > > AUIMD is mainly a monolithic application : the idea is to keep resources > as low as possible and reduce applications startup time, while still > providing error management and dynamic application reloading thanks to > python mechanism. > > The simplest way to run AUIMD is probably to use Debian, as apt-get will > easily fetch dependencies (see README for more), but it is also possible > to use OE to build PyQt4 and other needed packages such as python-dbus > (not tried it myself). > > Some more infos here : > http://www.pierrox.net/auimd/ > And some screenshots here : > http://www.pierrox.net/auimd/screenshots.html > > AUIMD started a long time ago as a proof of concept, stagnate for months, > and got some revival a few weeks ago. It may or may not go really > further, but anyway all feedbacks and contributions are welcome :-) > > Cheers, > > Pierre. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- http://charlie137.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tichy now hosted on google code + release 1.0.0
Hello all, (Some of you may know me from my previous openmoko address : char...@openmoko.org) Since I don't work for openmoko anymore, and since I had some free time in my hands recently, I restarted the tichy project (previously hosted on openmoko public git) The project is now hosted on google code [0]. From the web site we can see some screenshots. For the history, tichy is the project that was used as the base for the paroli project [1], officially supported by openmoko. Both projects are python frameworks to write applets for openmoko phones. I decide to restart tichy because in my opinion paroli has forked too much, and now both projects are having very different goals. So why I think people should give tichy a try : * It can run on debian, SHR, and FSO (even thouhg there is currently a problem with the installation on FSO) * it is using the Dbus framework for all the phone applets. * It is very simple to modify it, almost everything is written in python, with some small parts in cython. * It can run on the desktop as well. * There is a release (1.0.0) [2] The first release 1.0.0 [2] contains the source package, a debian packages, and an ipkg package that can be installed on SHR (should also work on FSO, but I see that python-pygame package is currently missing from the FSO feeds.) I will keep working on the project if I think there are interested people. I don't know how much time I will allocate to this, so I can make no statement about plans or future releases. Of course contributions are welcomes. I have to admit I didn't test it so much (I personally only use it for the chinese learning and dictionary applets), if people experience any problems, please let me know and I'll make a bug fix release. I would also be interested to know if the SHR, debian, or FSO people are interested for a collaboration to add tichy in there distributions. Happy programming, Guillaume [0] http://code.google.com/p/tichy [1] http://www.paroli-project.org/ [2] http://tichy.googlecode.com/svn/release/1.0.0/ -- http://charlie137.blogspot.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
On Mon, 2009-02-16 at 09:28 +0100, Michele Renda wrote: > This was my second question. I come from Java, so the convention are > "getName", "setAge". > But now, thinking to pygtk, I remember that the convention was > "get_name","set_age". I will fix it. > Can you please confirm that the Python convention about classes > remain > "MyWondefulClass"? Yes, you can see the python convention in PEP8 [0]. The classes are in CapitalizedWords and the method names in lower_case_with_underscores. Then, it is also said somewhere in the document that consistency is more important than following the style, so in your case I would got for the methods with the same name than the dbus functions (CapitalizedWords) > > Yes I know the pain of trying to write generic code for gobject, qt > or > > efl. The python Dbus library allow you to specify the underlying > > mainloop you are using when you create the bus object, in your case > that > > would be more tricky I guess cause you use GObject as a base class > for > > all you proxies. May be possible though. > > > I don't know Qt, but I think there is something like QObject that do > the > same work (more or less). > I want to have a look... A lot of people told me that developing with > Qt > is more funny than with Gtk. My opinion on that : If I use C++, I prefer using Qt, but if I use C or python, then I prefer gtk. Then, Qt provides things that gtk doesn't (I don't know if the opposite is also true...) gui [0] http://www.python.org/dev/peps/pep-0008/ signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
On Mon, 2009-02-16 at 07:51 +0100, Michele Renda wrote: > On 16/02/2009 03:44, Guillaume Chereau wrote: > > Hi Michele, > > > Hello Guillaume > > I share your feeling that directly using dbus in python is a little bit > > tedious. > > I didn't try your your code, just had a look at it, I like how the dbus > > methods are directly added into the object instead of using the > > __getattr__ method, it means we can use automatic completion from the > > python interpreter, something that is missing with DBus proxy objects. > > > I don't think the code completation will never work, at least in a > editor, because the methods available will be known only > during the execution of the code, not before :( Yes but I was thinking of cli-framework where you interactively create and manipulate the proxies objects. There the auto-completion would work and be very helpful. By the way, why do you change the name convention for the dbus methods, and make them all lowercase ? I know python convention is to use lowercase, but in that case I would prefer having the same name as the original DBus method (just a suggestion.) > The good part it that this library will not need to be updated if > fso-frameworkd will change. > The weak part is that fso-frameworkd deamon will change, all the > applications that use it will continue to need to be updated. > > What I like less is that you are using GObject, which mean I won't be > > able use your library for paroli. > > > Ops... my fault. I use PyGtk, so I thought that GObject is all the > world. And I forgot that exist a world done by other toolkits. > I think it needed to be called PyGtkFso or PyGObjectFso, and if the > ideas is nice, it will not be difficult to create a version of the same > library to > run with Qt and with Efl. I need only to study a bit PyQt and PyEfl. Yes I know the pain of trying to write generic code for gobject, qt or efl. The python Dbus library allow you to specify the underlying mainloop you are using when you create the bus object, in your case that would be more tricky I guess cause you use GObject as a base class for all you proxies. May be possible though. > > Also I though all the signals in GObject class had to be declared at the > > class level, how does it work with your introspection mechanism ? > > > This is the part I like more (but I don't know how much clean it is) > I redefine the method "connect" and if a signal si a signal for dbus > (that I read on runtime), I connect it direct to dbus, else I contine to > connect to the object. Ah I see, nice ! > Still I have to test well the part with signals, I tested well only methods. > To be runned, it need the mdbus script copied as mdbus.py in the same > forlder of pyfso.py (I steal a class from Michael). > > Anyway, I think it is a good initiative, maybe Mickey will consider > > adding this or something similar to the framework git. > > > > > For now I will try to use on some programs I created. But I son't think > it is so good code to enter in framework. For now it is only an experiment. I'll keep an eye on this project. If you could somehow embed it into an interactive python interpreter (see cli-framework), then I would give a try for sure. > > Thank you > Michele Renda > Regards, Guillaume Chereau signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First release of Enscribi - handwriting recognition input method
Most of the other characters I tried worked, only the 好 was a problem, so it is not too bad already :) I remember once I tried a similar software running on windows with a graphic tablet (forgot the name of it) and I was unable to write any character at all, but other people who could write Chinese properly had no problem. On Mon, 2009-02-16 at 11:54 +0800, HouYu Li wrote: > Actually. The recognition is somehow ... poor... > > On Mon, Feb 16, 2009 at 11:44 AM, Guillaume Chereau > wrote: > really great ! I had been looking for this for a long time ! > I can't succeed writing "好" (hao), but I guess it is due to > my poor > Chinese character writing skills. > > gui > > > On Sat, 2009-02-14 at 09:51 +0100, Olof Sjobergh wrote: > > Hi, > > > > This is to announce the first release of Enscribi, a new > handwriting > > recognition input method I've been working on. The main > focus, and the > > only thing supported for now, is writing Japanese and > Chinese > > characters (and numbers, but numbers only won't get you > far...). It > > uses the excellent Zinnia recognition engine for the actual > > recognition. If anyone is interested, please take a look. > > > > There's a project page at http://olofsj.github.com/enscribi/ > with > > screenshots and some more information. > > > > There are packages on opkg.org for trying it out (only > tested on FSO > > milestone 5). The following packages are available: > > http://www.opkg.org/package_133.htmlEnscribi > > http://www.opkg.org/package_130.htmlZinnia (required > dependency) > > http://www.opkg.org/package_131.htmlZinnia-tomoe-ja (for > Japanese support) > > http://www.opkg.org/package_132.htmlZinnia-tomoe-zh (for > Chinese support) > > > > Also, you need a Japanese or Chinese font to see the > characters > > (should be available in the usual repos). > > > > The code is hosted on Github at > http://github.com/olofsj/enscribi/tree/master > > > > Best regards, > > > > Olof Sjöbergh > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > > > > -- > > Best Regards > > HouYu Li, Karajan > > karajan_ii (at) hotmail.com > karadog (at) gmail.com > lihouyu (at) phpex.net > > PHP Programmer > Red Hat Certified Engineer > > 15th Feb, 2008 > Shanghai, China > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First release of Enscribi - handwriting recognition input method
really great ! I had been looking for this for a long time ! I can't succeed writing "好" (hao), but I guess it is due to my poor Chinese character writing skills. gui On Sat, 2009-02-14 at 09:51 +0100, Olof Sjobergh wrote: > Hi, > > This is to announce the first release of Enscribi, a new handwriting > recognition input method I've been working on. The main focus, and the > only thing supported for now, is writing Japanese and Chinese > characters (and numbers, but numbers only won't get you far...). It > uses the excellent Zinnia recognition engine for the actual > recognition. If anyone is interested, please take a look. > > There's a project page at http://olofsj.github.com/enscribi/ with > screenshots and some more information. > > There are packages on opkg.org for trying it out (only tested on FSO > milestone 5). The following packages are available: > http://www.opkg.org/package_133.htmlEnscribi > http://www.opkg.org/package_130.htmlZinnia (required dependency) > http://www.opkg.org/package_131.htmlZinnia-tomoe-ja (for Japanese support) > http://www.opkg.org/package_132.htmlZinnia-tomoe-zh (for Chinese support) > > Also, you need a Japanese or Chinese font to see the characters > (should be available in the usual repos). > > The code is hosted on Github at http://github.com/olofsj/enscribi/tree/master > > Best regards, > > Olof Sjöbergh > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
Hi Michele,
I share your feeling that directly using dbus in python is a little bit
tedious.
I didn't try your your code, just had a look at it, I like how the dbus
methods are directly added into the object instead of using the
__getattr__ method, it means we can use automatic completion from the
python interpreter, something that is missing with DBus proxy objects.
What I like less is that you are using GObject, which mean I won't be
able use your library for paroli.
Also I though all the signals in GObject class had to be declared at the
class level, how does it work with your introspection mechanism ?
Anyway, I think it is a good initiative, maybe Mickey will consider
adding this or something similar to the framework git.
Cheers,
-gui
On Mon, 2009-02-16 at 02:22 +0100, Michele Renda wrote:
> Hello to all
>
> I am writing here to show something I was working today, and I'd like to
> know your opinions.
> I try to explain with a few of words. How someone of you know, I wrote
> Sephora. In lastest day I lost some time to trying to fix sephora with
> the new fso milestone. Where I was working I realized that I hate dbus
> :) Ok, I know it is very important, it is cross language compatibile,
> but I program in python, and I don't like to write too much code. If I
> want to turn on a led I want to do something like:
>
> device = ODeviced()
> device.getLED().getGta02AuxRed().setBlinking(2, 3)
>
> Or if I want to react to a function I want to do something like this:
>
> gps = OGpsd()
> def myfunc(i):
> # I do something here
> gps.connect('fixStatusChanged', myfunc)
>
> So, I studied a bit how to use reflection in Python and the source code
> written by Michael Lauer, and I wrote a Python binding for FSO, and I
> called with a lot of fantasy PyFso (It is only a transitory name,
> because I think this name is already used for another project).
>
> You can have a look here: [1]
>
> To help the navigation, it also print the structure of the object I
> created [2].
>
> For now it is only a proof of concept. I would like to know if someone
> else have the same feeling with dbus.
>
> Thank you
> Michele Renda
>
> [1] http://dl.getdropbox.com/u/562269/PyFso/pyfso.py
> [2] /home/michele/Dropbox/Public/PyFso/structure.txt
>
>
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
signature.asc
Description: This is a digitally signed message part
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO M5] Paroli-Apps crash with 'Screen' object has no attribute 'etk_obj
On Wed, 2009-02-11 at 08:12 +, Arigead wrote: > r...@om-gta02:~# DISPLAY=:0; python -c 'import etk' > [Etk-Warning] (ecore_evas_x11.c:190 - _engine_init()): > Ecore_X initialization failed! > > [Etk-Warning] (etk_engine.c:221 - etk_engine_load()): > Etk can not initialize the requested engine! > > Segmentation fault > r...@om-gta02:~# OK then at least the error doesn't come from paroli. I don't get the error on my gta02, using FSO ms5 (illume) My version of python-etk (opkg info python-etk) is "0.1.1+svnr38544-ml1" and my version of libetk1 is "2:0.1.0.042+svnr38544-r4", what are yours ? Also, which "flavor" of FSO ms5 are you using ? fso-console-image, fso-illume-image, or fso-image ? I am using illume version and haven't tried the other ones. Ah, and just to make sure, can you also try using "export DISPLAY=:0" instead of "DISPLAY=:0" ? -gui signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO M5] Paroli-Apps crash with 'Screen' object has no attribute 'etk_obj
On Tue, 2009-02-10 at 14:39 +, Arigead wrote: > cd ../paroli-scripts/ > DISPLAY=:0; python paroli-launcher > > > results in the following: > > [Etk-Warning] (ecore_evas_x11.c:190 - _engine_init()): > Ecore_X initialization failed! > > [Etk-Warning] (etk_engine.c:221 - etk_engine_load()): > Etk can not initialize the requested engine! > > Segmentation fault I don't know what the problem is. It is the error you get when you don't set DISPLAY=:0 (by the way very annoying to have a seg fault in that case) but since you took care of setting DISPLAY then I don't know. Can you run this simple test : DISPLAY=:0; python -c 'import etk' And see if you get the same error. /Guillaume signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO M5] Paroli-Apps crash with 'Screen' object has no attribute 'etk_obj
On Tue, 2009-02-10 at 08:08 +, Arigead wrote: > As for Tele it does no start up the GSM modem at all, and register to > the network, so I can't make a call with it. Is this a know issue? I'd > like to help out by doing a bit of testing and giving some feedback. > I've probably a lot of opinion but for a start I'd like to be able to > make a phone call if I can't do that I'll have to reinstall zhone, but > I > was hoping to move on from that app. Hi John, They are two things you could look for : First, if you start paroli directy from its source directory, and you don't have it installed, it will read the local config file ./paroli.cfg, wich set GSM service to TEST, so that you will never get connected to the network. If you see this line the log : INFO set service GSM to Test Then it means you have to comment the line defaults = GSM:Test, SIM:Test, Audio:Test, in paroli.cfg Second thing is that even when you run paroli using the correct GSM service, you get no visual indication of the connection status. And it can be quite long before you get a network connection. Could you please repeat the operation and send the log (/tmp/paroli.log) to the mailing list ? Regards, Guillaume signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO M5] Paroli-Apps crash with 'Screen' object has no attribute 'etk_obj
On Mon, 2009-02-09 at 10:06 +, Arigead wrote: > Hello all, > Tried to install Paroli on MS5 and think I've got a repository issue > stopping my success. I installed FSO rootfs: > > openmoko-fso-illume-image-glibc-ipk--20090202-om-gta02.rootfs.jffs2 > > which does not include much stuff and tried to install paroli as per the > web instructions [1]. When I try the command "DISPLAY=:0; python > paroli-launcher" I get an error: > > Traceback (most recent call last): > File "paroli-launcher", line 58, in > import tichy > File "../paroli-core/tichy/__init__.py", line 42, in > import gui_paroli as gui > File "../paroli-core/tichy/gui_paroli/__init__.py", line 20, in > import e_dbus > ImportError: No module named e_dbus > > the web page [1] does say that you need e_dbus so that's fine but if I > issue the command: > > "opkg list | grep e_dbus" > > there are no packages that match that search. The package name is 'python-edbus'. > If I do an opkg update I > get one error which might be the problem: > > Collected errors: > * Failed to download > http://downloads.freesmartphone.org/fso-milestone5/feeds//armv4/Packages.gz, > error 404 It depends, maybe you did get the package from an other feed. Try to type : opkg list | grep python-edbus -gui signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [paroli] update week 6/09
On Mon, 2009-02-02 at 18:11 -0500, Joel Newkirk wrote: > SHR-unstable, 01/29, paroli downloaded 01/31 or 02/01: > > root INFO read config file ./paroli.cfg > root INFO read config file /etc/paroli/paroli.cfg > root INFO read config file /home/root/.paroli/paroli.cfg > root INFO init gui > root WARNING can't use backend paroli : No module named etk > root WARNING can't use backend csdl : No module named gui > root WARNING can't use backend sdl : No module named guip > Traceback (most recent call last): > File "./paroli", line 146, in > tichy.init_gui(None) > File "../paroli-core/tichy/__init__.py", line 71, in init_gui > import guip > ImportError: No module named guip > > > What is missing? Hello Joel, In your case, etk is missing. The error is confusing because when it failed to import the etk backend, paroli then tried to use other eventual graphic backends, but only the edje/etl backend is supported now, so we need to remove this part of the code. you need to install all python e binding (etk, evas, edje, ecore). If you have a neo you can find them with opkg, if you try paroli on the desktop, then you need to get them from the enlightenment website (see the INSTALL file [0] of paroli for more info) -Guillaume "charlie" [0] http://git.paroli-project.org/?p=paroli.git;a=blob;f=INSTALL signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pimlico on the Freerunner ?
On Wed, 2009-01-21 at 10:25 +0100, Laszlo KREKACS wrote: > > Unless I'm quite mistaken, the request was for Openmoko to offer an > > officially-supported development environment, beyond a tarballed toolchain > > and wiki instructions. > > I second that. There are so many bleeding edge software, it has a real > barrier (time-consuming installation) to begin to contibute. > > Eg. What is the most simple method to help paroli (without a freerunner)? > > It requires e17 from svn and their python bindings, it acts with the > FSO stack, need tichy (it is integrated these days,if Im right). > (I personally started to install all this stuff on my Desktop, but just > gave up after a couple of day) I just added an INSTALL file in paroli rep [0] with some instructions hope it may help. I understand that having to install efl from sources may be annoying for people who just want to give paroli a try. But it really the only thing needed, all the other dependencies (mostly python and a few python libraries) have packages for all common linux distribution. Beside, you don't need to have FSO to try paroli. If it can't find FSO, it will use some dummy services that emulate the presence of a phone stack. - Guillaume [0] http://git.paroli-project.org/?p=paroli.git;a=blob;f=INSTALL signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume dictionary for Dutch (Nederlands)
On Thu, 2008-11-20 at 10:14 +1100, Carsten Haitzler wrote: > (japanese) > sakana -> さかな | 魚 | 肴 | 坂な | 茶菓な | 阪な | 差かな | 左かな | > 差かな | > 査かな | 鎖かな | サカナ | sakana > Hi raster, I am curious how we can pass unicode character to applications like those via X. I though the keyboard could only send keycode. How does it work with illume keyboard ? -charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Paroli] Update #3
On Tue, 2008-11-18 at 22:52 +0100, "Marco Trevisan (Treviño)" wrote: > Well, today I've followed your RunParoli wiki to get it working in my > phone. I've used SHR as base updating the FSO framework and getting > tichy and paroli from upstream (respectively from svn and git). > > Well, after applying the changes you've suggested I wasn't able to get > Paroli running but only tichy-etk... Maybe my guy.py wasn't correct > (since it doesn't seem to reflect the wiki), so please could you > provide > a fresh explanation? > I modified gui.py so that we can select backends without manually modifying the code. It relies on a global variable so I don't like it so much, but couldn't think of a better way to modify the behavior of a module at import time (well I could import all backends, and then dynamically decide which one to use, but that would be wasting memory for nothing) This commit allow us to set the backend by setting the global variable 'tichy_gui_backend' from the main script : http://git.openmoko.org/?p=tichy.git;a=commit;h=9b41828f1de05af0183d66c1b46397c0133f831c This one allow us to use command line option in tichy to do so (e.g. ./tichy --gui-backend=etk) http://git.openmoko.org/?p=tichy.git;a=commit;h=c0af0cce3f3567e92378827f8955c53e1a67165e And this one allow use to use paroli specific backend (even though it is not in tichy tree yet): http://git.openmoko.org/?p=tichy.git;a=commit;h=2fe69ed611082770f8200183aa83c308ea55bf9c So now we can just add the line : tichy_gui_backends = ['paroli'] In the main script of paroli to use the correct gui backend. -charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Paroli] Update #3
On Tue, 2008-11-18 at 22:13 +0100, Mirko Lindner wrote: > This is a version without functionality, but implementing this is not > difficult and the dialer has been written to be easily adapted to > actually work. > > The reason for this non-working is that the tichy-fso components do > currently not work on the testing image and thus the phone doesn't > register on a network. As soon as that is solved we'll implement the > functions needed. Should be fixed on last git version of tichy. See this commit for the fix: http://git.openmoko.org/?p=tichy.git;a=commit;h=75ce9fa91083fea79e64a155ce809c0bb57b24c1 charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
On Mon, 2008-11-03 at 18:26 +0100, Marcel wrote: > > However, how will you merge tichy and paroli? I mean, I find tichy a > > nice project, but I don't like it to be used as a laucher, since > we've > > already illume for it and ihmo it does a fantastic job. > > I think so, too... Tichy is nice, of course, but Illume works already > perfectly (at least for me) and I'm used to it. I don't know your > exact > problem, but wouldn't it help to use this python-interpreter-sharing > thing > that came up on devel (?) recently? Well, I think the problem that paroli will try to solve is not only the time to start an application, but mostly the fact that applications don't interact very well between each other. On the desktop it is -almost- ok to have a clear separation between applications because we are used to just copy and past information from one app to an other anyway. Plus we can really feel the logical separation between the applications : each has its own window, I can move them around, resize them etc... On a phone it is not that easy. There is no copy and past, no possibility to resize or move windows. It takes a much closer cooperation between applications. If I see a contact in my contact list I want to be able to click on it, select call, and see the dialer. If I see the same contact in my history application, I want to be able to do the same thing, with the same interface. That is, the whole set of applications should feel like a single application. I guess that is what paroli is about : make the set of phone related applications perfectly integrated. Now my opinion is that if paroli succeed in doing that, then illume shouldn't be needed at all (paroli should have a plugin launcher, so it could be used to start other app as well (in fact, Michael "Goodwill" already implemented a launcher for tichy). But then, nothing prevents illume to stay, just like it works with FSO and zhone. Cheers, - Guillaume signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
On Mon, 2008-11-03 at 15:56 +0100, "Marco Trevisan (Treviño)" wrote: > My main question is how to manage the PIM. Will you wait for the FSO PIM > implementation or is there any other way to manage contacts and SMSs > (first of all) without using the SIM? Good question... In tichy so far I always tried to put an interface over the framework (FSO) DBus API. For the contact there is already a Contacts service in tichy that can deal with simple contacts lists. Things are simple in tichy, cause you expect all plugins to have access to the services without using inter process communications. Once you have the contacts loaded from the sim or any sources, you can expose them as python objects to any other tichy plugin. (see the code of tichy/test/plugins/app/contacts/contacts.py [0]) cheers, Guillaume/Charlie [0] https://projects.openmoko.org/plugins/scmsvn/viewcvs.php/test/plugins/apps/contacts/contacts.py?rev=269&root=tichy&view=markup signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some debian questions
On Sat, 2008-11-01 at 19:29 +0100, Michael 'Mickey' Lauer wrote: > Hi Charlie, > > I have just added a skeleton for org.freesmartphone.Events in the specs > repository, please fill it with some docs when you have a chance. > Thanks Mickey, I started to fill it. Of course the oeventsd API is very small. I also stared the opimd spec documentation. Cheers, Charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some debian questions
> > > On Tue, 2008-10-28 at 14:51 +0100, Benedikt Bär wrote: > Hmm... Indeed a problem. Maybe there could be a function to > activate/deactivate the given rule, and have it parsed if activated. > > Is the rules manager that flexible yet? Maybe you can point me in the > right direction there and I could come up with a patch for that :) > > Let me know your thoughts. I think we need to rethink the policy of the profile / rule interaction. Maybe a rule should have a special attribute that specify the profiles that activate it, or just rely on the rule filter for that and we don't use the rules configuration file at all. An other way : we could make the rule actual DBus object, with a DBus path. So the preferences can still refer to the rules by there name, and a client that create a new rule can refer to it by its DBus path. Cheers, Guillaume/Charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some debian questions
On Wed, 2008-10-29 at 10:29 +0800, Guillaume Chereau wrote: > On Tue, 2008-10-28 at 14:51 +0100, Benedikt Bär wrote: > > Hi all, > > > > I am currently setting up a debian system on my FreeRunner, but I have > > some questions. :) > > > > 1) I'm writing some python programs to interact with the FSO framework. > > I have seen there's now support for a "rules" file, which seems quite a > > nice idea. > > > > Now, I would like to be able to modify these rules via my program. That > > way, for example, I could set a screen blanking / suspend timeout but my > > program wouldn't have to listen to events. It would automatically be > > done by the framework. > > > > Is this possible? If not, any plans to implement something like a D-BUS > > interface for modifying rules? > You can already add new rules using the dbus call : > org.freesmartphone.Events.AddRule(s) > > the string should be in the same format than the rules in the rules > file. > > For the way to modify rules, it is planned. Rules can have name (using > 'name' attribute in the rules file.) > I will take some time today to add a RemoveRule, so that you can add and > remove rules. Ok I added the RemoveRule method to oeventsd, you can check oevents.py in the framework tests directory to see how to add and remove rules. BUT, it makes me realize a problem : the rules manager only activates the rules that are specified in the rules preference file (e.g [0]) So if you add a new rule with a name, the rule won't be activated unless you also specify that the rule is activated in the preference file. that is not very good and we need to solve this problem. cheers, Guillaume [0] : http://git.freesmartphone.org/?p=framework.git;a=blob;f=etc/freesmartphone/opreferences/conf/rules/default.yaml;h=e0066eff76973b5597d879bf81b0e0f490660bdb;hb=HEAD signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some debian questions
On Tue, 2008-10-28 at 14:51 +0100, Benedikt Bär wrote: > Hi all, > > I am currently setting up a debian system on my FreeRunner, but I have > some questions. :) > > 1) I'm writing some python programs to interact with the FSO framework. > I have seen there's now support for a "rules" file, which seems quite a > nice idea. > > Now, I would like to be able to modify these rules via my program. That > way, for example, I could set a screen blanking / suspend timeout but my > program wouldn't have to listen to events. It would automatically be > done by the framework. > > Is this possible? If not, any plans to implement something like a D-BUS > interface for modifying rules? You can already add new rules using the dbus call : org.freesmartphone.Events.AddRule(s) the string should be in the same format than the rules in the rules file. For the way to modify rules, it is planned. Rules can have name (using 'name' attribute in the rules file.) I will take some time today to add a RemoveRule, so that you can add and remove rules. - Guillaume/Charlie signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] upgrading zhone-session error
On Mon, 2008-10-27 at 17:43 +0100, Marcel wrote: > Am Monday 27 October 2008 15:55:02 schrieb Joachim Breitner: > > Maybe I’m a bit off, but last time I looked SHR did not have a readily > > working dialer app. And is tichy more than a proof of concept? Tichy is currently not totally functional, but that is mostly because I didn't update it to follow the framework modifications. I still use it sometime for the dictionary and the chinese learning application. The project is asleep until I have time to work on it by myself or openmoko decides to invest time on it. I still accept patches of course and will fix bugs if people request me to do so. cheers, - Charlie / Guillaume signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: French Community / Communauté Francophone
Good job, the web site is very nice ! Hope I can see you guys when I come to France. Oui oui je suis Français ! Charlie On Tue, 2008-10-21 at 00:49 +0200, swap38 wrote: > (sorry for my poor english, french version below) > > // > Hi, > > As you may have noticed already, a francophone community is rapidly > growing on the *http://openmoko-fr.org* site which has been in existence > for only three months now. > The site now contains a news blog (relayed on the Planet), a forum with > 180 members and over 2000 posts, a wiki with over 60 pages, and an IRC > channel (#openmoko-fr on freenode). > > Our goal is to speak in French about the Openmoko project to a wider > audience (developpers or not) and allow everyone to contribute at own level. > If you are looking for more information and feedback in French, or if > you want to share yours, feel free to participate. You're more than welcome! > > // > Bonjour, > > Comme vous l'avez peut-être déjà remarqué, une communauté francophone > est en train de se fédérer autour du site > > http://openmoko-fr.org > > Ce site existe depuis seulement 3 mois mais contient déjà un blog > d'informations (relayé sur le Planet), un forum (180 membres, plus de > 2000 messages) un wiki (plus de 60 pages) et un canal IRC (#openmoko-fr > sur freenode). > > Notre objectif est de s'adresser à un large public (développeurs ou non) > pour promouvoir le projet Openmoko en français et permettre à chacun de > contribuer à son niveau. > Si vous cherchez des informations et retours d'expériences en français > ou si au contraire vous souhaitez partager les vôtres, n'hésitez pas > participer vous êtes les bienvenus ! > signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the basics: improving user experience
On Thu, 2008-10-16 at 05:00 -0700, dant wrote: > So maybe we could make one big(ger) app > (remember that there is quite big amount of ram there) responsible for > calling, contacts, sms and all that phonny stuff and keep it all the time in > memory with all needed library (static build?) There are a few projects doing this : tichy [0], zhone [1], and future paroli [2] are all single process apps. charlie/guillaume [0] http://wiki.openmoko.org/wiki/Tichy [1] http://wiki.openmoko.org/wiki/Zhone [2] http://code.google.com/p/paroli/ signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO milestone3 my view (ON gta01)
Hello Dale. To answer your question : The equivalent of source in python is execfile(filename). That should work the way you said. charlie/guillaume On Tue, 2008-09-16 at 15:07 +1000, Dale Maggee wrote: > One more (dumb?) question: > > since I'd rather keep my zhone updated, I was thinking I could create > a > file named ~/addressbook.py, which contains: > > self.cbPhonebookReply( [ > (1, u'Kirk', '+023224433'), > (2, u'Spock', '+034433463'), > (3, u'McCoy', '+013244344'), > (4, u'Scott', '+013244344'), > (5, u'Uhura', '+013244344'), > (6, u'Sulu', '+013244344'), > (7, u'Chekov', '+456663443'), > ] ) > > and then do the python equivalent of "source ~/addressbook.py" at > line > 742. This means that I could easily keep my zhone updated and just > make > a one-line change when it gets updated... but is there / what is a > python equivalent of "source"? signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO milestone3 my view (ON gta01)
Hello Tilman. I will just comment on the tichy part of your email, since I am the main author. On Fri, 2008-09-12 at 12:24 +0200, Tilman Baumann wrote: > I like the Tichy concept of having pythons apps running as plugins in > one python runtime. > I always expected it to be something like a app launcher that > executes > python modules rather than calling stand allonw apps. But it is exactly what it does. I think you misunderstood tichy. But still I want to defend my approach (that you seem to recommend so I am confused). Tichy is a python app. I can't afford to start a new python interpreter every time we open an application. I don't want to have too many python interpreters running at the same time either. My solution is to use a cooperative event based system for all the basics applications (dialer, messages, etc) They all run in the same interpreter, and share the same mainloop. That is what i refer to tichy as a "python applets manager". > But tichy as it is is useless. I agree with you in the sense that if tichy would only call stand alone app, it would be useless. > Combining all apps into one screen does > not help, we have window management. Do you mean we should use one X window per applet in tichy ? Well that is possible. In fact I have a backend for gtk+ and etk/evas (still experimental). Both of them use one window per applet. > The GUI design does not strike me as good either. I can unfortunately only agree on this :(. My fault. I am not an expert in GUI design (I have a hard time with it cause things that look good on the desktop don't on a small screen.) When I started tichy I tried to use gtk+, but then gave up and used my own SDL based gui system (we talk about the guy who liked to write video games here :-) ). Then I though about all the possible choices of graphics backend -and how critical this choice could be- and I realize the only way to be sure not to make a bad decision, is not to choose one at all. So here is how it works : When you write an application for tichy, you use as few gui objects as possible. Instead, you define 'Items' with properties and possible actions. Then tichy will request for a plugin that offers the 'Design' service and ask this plugin to create the user interface for the application. the design plugin is free to create any interface, as long as it shows the proper items and provides a way to trigger the proper actions on those items (not unlike edje works) That is why I can create backends for almost any graphic library you can imagine, without changing the code of the applications. > The all in one concept is just wrong in my eyes. Great idea, but done > wrong. The concept is wrong or the idea is great but done wrong ? For me the all in one concept is important, at least for all the basics phone applications. There is just too much communication between them. It is not only a matter of sharing data (the framework is there for this), but also being able to lauch one app from an other, and to share the screen space in a clever way. Also the time to launch an external application is too slow. > I don't want to have my phone work nearly as like tichy works. > > I like to have some native apps like the GTK PIM apps back. > They where really well made, usefull and useable. > > I like to have a home screen on the desktop like the GTK home app. > This was really a great concept. i like to see that come back. > I think this would be a easy job for a desklet... I agree with you. Beside it is very simple to do. > > Especially important would be a dialer app that starts quickly. > (maybe > living in a applet all the time) > The GTK dialer would be a great template. ;-) > > And i would say it is time for some gui guidelines for new world etk, > efl apps. > We have a great looking environment, now let's define how apps should > look. And pleas don't make them look like qtopia, Zhone or tichy. > I have some ideas for that too. But i whink we need some > experimenting > first... > Is there already some movement into finding the new way to interact > with > the UI? Well, what about the idea I talked about : You define a set of minimal necessary information needed to construct the gui for many kinds of applications (most of the time an application is just trying to show some objects and let the user trigger actions on it). Then you use a plugin to actually construct the gui. I guess Raster was a visionary on this idea. In fact he is the one who gave me this idea once on irc, the next week I started implementing it in tichy :P But even the applications we have that do use edge don't do it the perfect optimal way. If your application's code use -let's say- a scrollbox, then you are already deciding that you want to show your items in a scrolled view, so what if the user want to show them in a table, or in a fancy 3d view like we start to see on a few closed source mobile phone ? Then you have to modify the application code. In tichy you would first cr
Re: DOOM OpenMoko Port
Can't wait to play doom on my neo ! This game rocks ! Please don't forget to add a "strafe" key. Doom is not playable without it. Guillaume/Charlie On Sun, 2008-09-07 at 20:11 +, Federico Lorenzi wrote: > You know a platform's looking up when Doom and Duke3d get ported to it :) > > Good work! > > On Sun, Sep 7, 2008 at 7:53 PM, Mikko Niemikorpi <[EMAIL PROTECTED]> wrote: > > Nice job. I'm still waiting my Freerunner but this is now another thing > > to wait for. > > > > SCarlson kirjoitti: > >> I've just witnessed DOOM on my Freerunner. I spent a few hours this > >> evening > >> compiling a SDL port for DOOM, it let me tell you it looks great. I'd like > >> to thank everyone involved for giving me the opportunity to exploit this > >> machine (which is also a phone). > >> > >> I'll be working on a Acc. UI, similar to the Duke3d port. (Thanks to the > >> person who ported Duke3d to inspire me today to do the same with DOOM, this > >> just made my week) > >> > >> -Scott > > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO: settings and profiles
Matt Joyce wrote: > On Fri, Aug 8, 2008 at 8:36 AM, Fredrik Wendt <[EMAIL PROTECTED]> wrote: > >>> And there is a profile switcher planned I hope? >>> >> I just can't let go of the idea of having several profiles activated at >> the same time, so I'll spam you all once more (last time, I promise). >> >> Alright, I will once again explain my current goal for the framework profile implementation. First : I gave up my original idea of having a single activated profile. So don't worry. We DO have several activated profiles. I will implement it this way (thanks to several advices from various people, can't remember the names to give credit) : * There is a list of activated profiles, e.g : [Home, Silent, Default] * When the preferences service try to get a parameter, if the parameter is profile dependent, it will first look for the profile at the top of the list. If the profile doesn't define the value, then we look in the next profile on the list and so on... This way we can have as many activated profiles as we want, and we can deal with conflicts between profiles. * The framework preferences service will have a SetProfile(profile) method, this method creates a new profiles list like the following one : [profile, Default], so it emulate a "single profile" mode * It will also have Append, Push, Pop, Remove, etc methods, so that we have full control over the profile list. * The events service can -among other things- modify the profiles list when specific events occur. e.g : - ON Noisy THEN AppendProfile(Noisy) - ON Quiet THEN RemoveProfile(Noisy) The rules are triggered in the order they appear in the conf file ( for info about the actual format of the file, see [0] ) cheers, - charlie [0] http://git.freesmartphone.org/?p=framework.git;a=blob;f=etc/freesmartphone/oevents/rules.yaml;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO ringtone
Matt Joyce wrote:
> I don't mean to be overly critical, the process you've described is
> trivial enough, and thank you for sharing, but why is is designed like
> this?
>
I agree with you that it is not the way we should do. For me the
decision to start or stop the ringing tone should be left to the
software that reacts to the incoming call signal. Then the configuration
file should depends of the software. Fun thing to try : kill zhone on
FSO, and call the phone, it will still ring.
But, in the framework we want to include a full customizable events
system, that will be useful when you want to programs context rules,
like : when I enter into my house, set profile to Silent, etc...
So the moment we use this mechanism to start and stop the ring tone.
Maybe in the future we will move that out of the framework, but the
events manager system will stay, because it has many other uses.
> Surely if the exact same steps are performed before building the
> software, it will be much easier for many more people.
> It just seem insane to be hardcoding references to sound files for
> functions that people will habitually want to change.
>
Yes, that is why I say, the software should decide of the way it reacts
to an incoming call.
> Ring tone is probably the first item of customisation a new user will
> want to change, and they will expect it to be intuitive.
>
> On another note, the rule.yaml file looks intresting, where can I find
> out more about that ?
>
Well, it is very new, I just added this to the framework a few days ago.
It uses the yaml syntax [0] that I like a lot . If you want to see the
code, download the framework daemon [1], and have a look at the files in
subsystems/oeventsd/ It is all in python and there is enough
documentation to get the idea.
As soon as the framework team accepts this thing, I will create a
tutorial on how to create custom rules in the freesmartphone wiki [1]
[0] http://www.yaml.org/
[1] http://git.freesmartphone.org/?p=framework.git;a=summary
[2] http://www.freesmartphone.org/index.php/Tutorials
Charlie
> Matt
>
>
> On Thu, Aug 7, 2008 at 12:53 PM, Guillaume Chereau <[EMAIL PROTECTED]> wrote:
>
>> Just for your information, with the new events system, it will soon be
>> different. You will have to edit the rule.yaml file. It looks like this
>> now :
>>
>> -
>># This rule will play a ring tone when a call is incoming
>>trigger: CallStatus()
>>filters: HasAttr(status, "incoming")
>>actions:
>>- PlaySound("/usr/share/sounds/Arkanoid_PSID.sid")
>>- StartVibration()
>> -
>># This one will stop the ring tone when the call is in an other state
>>trigger: CallStatus()
>>filters: Not(HasAttr(status, "incoming"))
>>actions:
>>- StopSound("/usr/share/sounds/Arkanoid_PSID.sid")
>>- StopVibration()
>>
>> So you will need to replace the path to the path you want.
>> Still not as good as a real user interface, but better than being
>> hard-coded in the framework code.
>>
>> Charlie
>>
>> On Thu, 2008-08-07 at 01:53 +0200, Francesco Cat wrote:
>>
>>> add this on the wiki :D it seems nice and should be automated in a
>>> really simple way! :)
>>>
>>> 2008/8/7 Angus Ainslie <[EMAIL PROTECTED]>:
>>>
>>>> On Wed, Aug 6, 2008 at 3:40 PM, simarillion <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> On Wednesday 06 August 2008 20:20:29 Angus Ainslie wrote:
>>>>>
>>>>>> Where is the FSO ring tone saved ?
>>>>>>
>>>>>> Angus
>>>>>>
>>>>> I think it's /usr/share/sounds/
>>>>> But I'm not sure.
>>>>>
>>>> Thanks ,
>>>>
>>>> Thats exactly where it is.
>>>>
>>>> /usr/share/sounds/Arkanoid_PSID.sid
>>>>
>>>> Now to change it is a little bit of fun.
>>>>
>>>> first in
>>>>
>>>> /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.py
>>>>
>>>> Change the line that reads:
>>>>
>>>> decoder = gst.element_factory_make( "siddec", "decoder" )
>>>>
>>>> to
>>>>
>>>> decoder = gst.element_factory_make( "mad", "decoder" )
>>>>
>>>>
>>>> and change the line that reads:
>>>>
>>>> filesrc.set_property( "location", "/usr/share/sounds/Arkanoid_PSID.sid" )
>>>>
>>>> to
>>>>
>>>> filesrc.set_property( "location", "/usr/share/sounds/ringtone" )
>>>>
>>>> Then
>>>>
>>>> mv
>>>> /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.pyo
>>>> /home/root
>>>>
>>>> then reboot the phone ( I'm sure there's a better way to regenerate
>>>> receiver.pyo but I don't know it )
>>>>
>>>> Now you can link /usr/share/sounds/ringtone to any mp3 and that will be
>>>> your
>>>> ringtone
>>>>
>>>> Angus
>>>>
>>>>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: FSO ringtone
Just for your information, with the new events system, it will soon be
different. You will have to edit the rule.yaml file. It looks like this
now :
-
# This rule will play a ring tone when a call is incoming
trigger: CallStatus()
filters: HasAttr(status, "incoming")
actions:
- PlaySound("/usr/share/sounds/Arkanoid_PSID.sid")
- StartVibration()
-
# This one will stop the ring tone when the call is in an other state
trigger: CallStatus()
filters: Not(HasAttr(status, "incoming"))
actions:
- StopSound("/usr/share/sounds/Arkanoid_PSID.sid")
- StopVibration()
So you will need to replace the path to the path you want.
Still not as good as a real user interface, but better than being
hard-coded in the framework code.
Charlie
On Thu, 2008-08-07 at 01:53 +0200, Francesco Cat wrote:
> add this on the wiki :D it seems nice and should be automated in a
> really simple way! :)
>
> 2008/8/7 Angus Ainslie <[EMAIL PROTECTED]>:
> > On Wed, Aug 6, 2008 at 3:40 PM, simarillion <[EMAIL PROTECTED]> wrote:
> >>
> >> On Wednesday 06 August 2008 20:20:29 Angus Ainslie wrote:
> >> > Where is the FSO ring tone saved ?
> >> >
> >> > Angus
> >>
> >> I think it's /usr/share/sounds/
> >> But I'm not sure.
> >
> >
> > Thanks ,
> >
> > Thats exactly where it is.
> >
> > /usr/share/sounds/Arkanoid_PSID.sid
> >
> > Now to change it is a little bit of fun.
> >
> > first in
> >
> > /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.py
> >
> > Change the line that reads:
> >
> > decoder = gst.element_factory_make( "siddec", "decoder" )
> >
> > to
> >
> > decoder = gst.element_factory_make( "mad", "decoder" )
> >
> >
> > and change the line that reads:
> >
> > filesrc.set_property( "location", "/usr/share/sounds/Arkanoid_PSID.sid" )
> >
> > to
> >
> > filesrc.set_property( "location", "/usr/share/sounds/ringtone" )
> >
> > Then
> >
> > mv
> > /usr/lib/python2.5/site-packages/framework/subsystems/oeventd/receiver.pyo
> > /home/root
> >
> > then reboot the phone ( I'm sure there's a better way to regenerate
> > receiver.pyo but I don't know it )
> >
> > Now you can link /usr/share/sounds/ringtone to any mp3 and that will be your
> > ringtone
> >
> > Angus
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> >
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
signature.asc
Description: This is a digitally signed message part
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Weekly report
Charlie's weekly report == Tichy == * Many various improvements. * I did a video to present a little bit more the project : http://charlie137-2.blogspot.com/2008/07/tichy-update.html To get more information, see the README file in the project source root directory. == Freesmartphone == * Worked on the ophoned service, we can use it to start voice call channel using different protocols (the possible protocols for the moment are only GSM and Test, VoIP to come). It also provides a nice object oriented approach : every call channel is an object that we can manipulate independently of the other channels. * Started to write test scripts for the framework. Mickey is also writing his own test scripts, but the more we test the better. * Did an other tutorial for people who want to use or contribute to the framework : http://www.freesmartphone.org/index.php/Tutorials/development_env signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
This is one of the thing I am planning to add in the framework (FSO
project), although for the moment we don't focus on it too much.
I agree with Alexey as well, the danger is to create something so
configurable, that at the end your setting become a python script.
My idea for the moment is like this :
You can define a set of condition to specify the profile. For example :
if at my girl friend house, profile = "Paranoid"
Then you the application configurations can depend on the profile. e.g :
If profile is "Paranoid", girl_friend_number_2.block_calls = True
This way, the profile is the link between the conditions set and the
actions set. The number of profiles is not supposed to be too large.
It is more restrictive that Russel idea, because you can't say :
if time = 600, then play alarm.
The only way to do so would be :
if time = 600, then profile = "RunAlarm"
if profile is "RunAlarm", then alarm.run = True
Which is not really useful, you don't want to create one profile for
every events combination you can think of.
I can see several cases where this way of doing is not the best, but I
still think it is the most suitable for most practical cases.
-charlie
On Thu, 2008-07-17 at 17:46 -0700, Russell Sears wrote:
> I agree with most of what Alexey said, but I would love to see some sort
> of easy to use scripting / gui environment. I think the FSO stuff is
> working on some sort of d-bus event notification system. Presumably
> there's a set of python / c libraries that know how to talk to dbus, and
> provide a simple wrapper on top of everything. (I haven't looked at FSO
> or DBUS yet... ;)
>
> I wonder if this is a job for some simple query language like a subset
> of xpath or xquery. It could re-evaluate an expression each time a dbus
> event could change the expression's results. It would also simplify
> writing things like "pause my music when the phone rings", alarm clocks,
> etc:
>
> register_event_handler("/phone/incoming_call = true",
> mute_music_callback)
>
> register_event_handler("/clock/time = 600",
> play_alarm_callback,
> "loud_buzzer.ogg")
>
> and so on...
>
> These event handlers could live in a python script (or, better) inside a
> simple GUI app.
>
> I think most people that own one of these things knows how to program.
> Improving their productivity a bit should be a big win when the consumer
> version of the phone ships...
>
> -Rusty
>
> Alexey Feldgendler wrote:
> > On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce <[EMAIL PROTECTED]>
> > wrote:
> >
> >>If it can be reliably established that my physical location is one of
> >> my favourite restaurants please switch my phone to vibrate, unless my
> >> babysitter calls.
> >>If I miss a call or I receive an SMS from from any of my work
> >> contacts during work hours, and I don't respond, please remind me.
> >>If it's not during work hours, do not take any calls from contacts
> >> exclusively in my work contacts.
> >>If my home wifi is available and my battery is not too low, don't use
> >> GPRS for data.
> >>If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and
> >> start getting email and rss.
> >>At 21:00 on weekdays, switch to standby.
> >>If my battery is low and I'm at home, remind me to charge.
> >>If I'm at home disable my auto-lock.
> >
> > The problem with this is that one needs to think like a programmer to
> > describe your “ideal phone” as a set of rules like these. Not only does
> > one have to think analytically and dissect their concept into orthogonal,
> > machine-checkable rules, but from your examples it's also clear that for
> > such a wide range of possibilities a whole *language* with *expressions*
> > (at least boolean) is necessary.
> >
> > Moreover, if one *is* a programmer, and has learned the rule expression
> > language, there will be bugs in the rulesets, like overlooked priorities
> > or excessively permissive conditions, and you'll spend some time debugging
> > it, probably missing a few important calls and alarms now and then in the
> > process. Next step would be debugging tools for rulesets, allowing to
> > simulate times of day, different conditions and incoming events to test
> > the rules. Next, backup and revision control for rulesets. This is where
> > madness lies: you have to modify and debug a program in a declarative
> > logic language when you start dating someone because it breaks all your
> > carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you
> > by any chance reading this?
> >
> > I understand that you must be thinking, “This phone is fully programmable,
> > so I can make it do whatever I want”. True. Now, by defining sets of
> > possible conditions and actions and letting the user make rules out of
> > these, you're basically saying: “Here is a computer. You can program it to
> > d
Re: Meta Toolchain Release (2008 May)
On Tue, 2008-05-13 at 09:25 -0700, Pranav Desai wrote: > > > On Mon, May 12, 2008 at 7:37 PM, Guillaume Chereau > <[EMAIL PROTECTED]> wrote: > > > On Mon, 2008-05-12 at 16:19 -0700, Pranav Desai wrote: > > > > > > On Sun, May 11, 2008 at 2:53 PM, Julian > <[EMAIL PROTECTED]> > > wrote: > > Hi all, > > > > After fix some problems, I had put the newest meta > toolchain > > to > > downloads.openmoko.org. > > > > If you are developing a single application, you can > use > > meta-toolchain > > to build your onw application. > > > > I tried using this toolchain, but it fails with the > following error on > > om-conf. The sample program works fine with the old > toolchain. This is > > happening with the 32bit and 64bit versions of the new > toolchain. Am I > > missing something here ? > > > > om-conf openmoko-sample2 > > > > configure: WARNING: In the future, Autoconf will not detect > > cross-tools > > whose name does not start with the host triplet. If you > think this > > configuration is useful to you, please write to > [EMAIL PROTECTED] > > checking pkg-config is at least version 0.9.0... yes > > checking for DEPENDENCIES... configure: error: Package > requirements > > (libmokoui2 gconf-2.0) were not met: > > > > No package 'libmokoui2' found > > No package 'gconf-2.0' found > > > > Consider adjusting the PKG_CONFIG_PATH environment variable > if you > > installed software in a non-standard prefix. > > > > Alternatively, you may set the environment variables > > DEPENDENCIES_CFLAGS > > and DEPENDENCIES_LIBS to avoid the need to call pkg-config. > > See the pkg-config man page for more details. > > > > FATAL: oe_runconf failed > > > > Let me know if you need more information. > > > > -- Pranav > > > > > > > > please take a look of this Page. > > > > http://wiki.openmoko.org/wiki/Toolchain > > > > Best Regards, > > > > -Julian > > > > I had the same problem. I finally made it work by using the > script : /usr/local/openmoko/arm/environment-setup > instead of /usr/local/openmoko/arm/scripts/script-env > > Thanks! ... now it does configure, but does your make succeeds ? > > my make still fails with the following errors, so it seems like its > still using the system files ... this is just the start of make error, > but I think u get an idea. > > In file included from /usr/include/glib-2.0/glib/galloca.h:30, > from /usr/include/glib-2.0/glib.h:30, > from /usr/include/gtk-2.0/gdk/gdktypes.h:32, > from /usr/include/gtk-2.0/gdk/gdkcolor.h:31, > from /usr/include/gtk-2.0/gdk/gdkcairo.h:23, > from /usr/include/gtk-2.0/gdk/gdk.h:30, > from /usr/include/gtk-2.0/gtk/gtk.h:31, > from sample-main.c:19: > /usr/include/glib-2.0/glib/gtypes.h:30:24: error: glibconfig.h: No > such file or directory > In file included from /usr/include/glib-2.0/glib/galloca.h:30, > from /usr/include/glib-2.0/glib.h:30, > > -- Pranav > It worked on my computer, but I check again now and you are right : it uses the host header files. It just appends to work on my computer because I have all the header files in my host computer already (for example in your case I think you need to install the package libglib2.0-dev) Maybe there is a problem with the toolchain pkg-config ? - Gui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Meta Toolchain Release (2008 May)
On Mon, 2008-05-12 at 16:19 -0700, Pranav Desai wrote: > > > On Sun, May 11, 2008 at 2:53 PM, Julian <[EMAIL PROTECTED]> > wrote: > Hi all, > > After fix some problems, I had put the newest meta toolchain > to > downloads.openmoko.org. > > If you are developing a single application, you can use > meta-toolchain > to build your onw application. > > I tried using this toolchain, but it fails with the following error on > om-conf. The sample program works fine with the old toolchain. This is > happening with the 32bit and 64bit versions of the new toolchain. Am I > missing something here ? > > om-conf openmoko-sample2 > > configure: WARNING: In the future, Autoconf will not detect > cross-tools > whose name does not start with the host triplet. If you think this > configuration is useful to you, please write to [EMAIL PROTECTED] > checking pkg-config is at least version 0.9.0... yes > checking for DEPENDENCIES... configure: error: Package requirements > (libmokoui2 gconf-2.0) were not met: > > No package 'libmokoui2' found > No package 'gconf-2.0' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Alternatively, you may set the environment variables > DEPENDENCIES_CFLAGS > and DEPENDENCIES_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > > FATAL: oe_runconf failed > > Let me know if you need more information. > > -- Pranav > > > > please take a look of this Page. > > http://wiki.openmoko.org/wiki/Toolchain > > Best Regards, > > -Julian > I had the same problem. I finally made it work by using the script : /usr/local/openmoko/arm/environment-setup instead of /usr/local/openmoko/arm/scripts/script-env - Gui signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
