Re: om2009/paroli status

2009-08-03 Thread Guillaume Chereau
On Mon, Aug 3, 2009 at 7:27 PM, Laszlo
KREKACSlaszlo.krekacs.l...@gmail.com 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

2009-08-02 Thread Guillaume Chereau
On Mon, Aug 3, 2009 at 6:42 AM, Laszlo
KREKACSlaszlo.krekacs.l...@gmail.com 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


Tichy version 1.1.0 released

2009-05-31 Thread Guillaume Chereau
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..

2009-05-05 Thread Guillaume Chereau
On Tue, May 5, 2009 at 4:09 PM, Rui Miguel Silva Seabra r...@1407.org 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 ri...@kurppa.fi 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

2009-04-08 Thread Guillaume Chereau
On Thu, Apr 9, 2009 at 12:00 AM, Leonti Bielski prishe...@gmail.com 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


Tichy now hosted on google code + release 1.0.0

2009-04-06 Thread Guillaume Chereau
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: auimd-0.2, a user interface for mobile devices (and especially the FreeRunner !)

2009-04-06 Thread Guillaume Chereau
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 pier...@pierrox.net:
 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


Re: Tichy now hosted on google code + release 1.0.0

2009-04-06 Thread Guillaume Chereau
On Tue, Apr 7, 2009 at 7:16 AM, Leonti Bielski prishe...@gmail.com 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: Fso Python binding

2009-02-16 Thread Guillaume Chereau
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

2009-02-15 Thread Guillaume Chereau
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: First release of Enscribi - handwriting recognition input method

2009-02-15 Thread Guillaume Chereau
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: First release of Enscribi - handwriting recognition input method

2009-02-15 Thread Guillaume Chereau
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
 char...@openmoko.org 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: Fso Python binding

2009-02-15 Thread Guillaume Chereau
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: [FSO M5] Paroli-Apps crash with 'Screen' object has no attribute 'etk_obj

2009-02-10 Thread Guillaume Chereau
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

2009-02-10 Thread Guillaume Chereau
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

2009-02-09 Thread Guillaume Chereau
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 module
 import tichy
   File ../paroli-core/tichy/__init__.py, line 42, in module
 import gui_paroli as gui
   File ../paroli-core/tichy/gui_paroli/__init__.py, line 20, in module
 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

2009-02-02 Thread Guillaume Chereau
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 module
 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 ?

2009-01-21 Thread Guillaume Chereau
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)

2008-11-27 Thread Guillaume Chereau
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

2008-11-18 Thread Guillaume Chereau
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] Update #3

2008-11-18 Thread Guillaume Chereau
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 project

2008-11-04 Thread Guillaume Chereau
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: Some debian questions

2008-11-03 Thread Guillaume Chereau

   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

2008-11-03 Thread Guillaume Chereau
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: Paroli project

2008-11-03 Thread Guillaume Chereau
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=269root=tichyview=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

2008-10-28 Thread Guillaume Chereau
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: Some debian questions

2008-10-28 Thread Guillaume Chereau
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: [debian] upgrading zhone-session error

2008-10-27 Thread Guillaume Chereau
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

2008-10-20 Thread Guillaume Chereau
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

2008-10-16 Thread Guillaume Chereau
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)

2008-09-16 Thread Guillaume Chereau
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)

2008-09-12 Thread Guillaume Chereau
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 create a list of items, and then ask 

Re: DOOM OpenMoko Port

2008-09-07 Thread Guillaume Chereau
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 ringtone

2008-08-07 Thread Guillaume Chereau
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: settings and profiles

2008-08-07 Thread Guillaume Chereau
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

2008-08-06 Thread Guillaume Chereau
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

2008-07-21 Thread Guillaume Chereau
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

2008-07-17 Thread Guillaume Chereau
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  
  do whatever you want”. While this might be usable for someone who is a  
  programmer (and who's willing to be a programmer when they deal with 

Re: Meta Toolchain Release (2008 May)

2008-05-13 Thread Guillaume Chereau
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)

2008-05-12 Thread Guillaume Chereau

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