Re: Paroli project
On Tue, Nov 4, 2008 at 11:37 AM, Mirko Lindner <[EMAIL PROTECTED]> wrote: > Collaboration and joint efforts sounds like a good idea. > However, I had a look at the project description and it seemed to me > that SHR focuses on development with C and gtk, which is not quite what > we are aiming for, but as I said it was a short look. Could you explain > how EFL fits into the picture? SHR has nothing to do with only C and GTK. We aim to deliver a stable and working community driven distribution. We first thought to port the old 2007.2 GTK applications to frameworkd, as by that time, 2008.9 wasn't out yet and 2007.2 wasn't stable enough. We ended up building an architecture allowing the user to install different libraries related to frameworkd functionnalities, and allowing him to change the library used for this or that part in a configuration file. In the end, quickdev (a SHR developer) managed to develop quite fast a working dialer, messages and contacts software based on EFL, in a library implementing the logic built in SHR (libframeworkd-phonegui-efl). This logic is described here : http://shr.bearstech.com/trac/wiki/SHR_Architecture What he did is to implement the specifications written in libframeworkd-phonegui, using libframeworkd-glib to abstract the dbus connection. In the future, I'd like to settle the mainloop problems with libframeworkd-glib, allowing the user to choose which kind of dbus library libframeworkd-glib should use at runtime (i.e. attaching itself to the mainloop of the user/developer choice, hence avoiding the management of threads). I also would like to see how our logic can interact with things such as tichy (as discussed with Guillaume), or other languages than C. In any case, if you manage to build a share object with method hooks usable in C, you're free to use the language of your choice. Hence, it would worth it if we shared our efforts, we're just a few people working out here, and several of us could build something even better :-) -- Julien Cassignol http://www.ainulindale.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Julien, > Just so you know, SHR already chose this path, and we successfully > built our dialer based on EFL (and currently moving to elementary), > using frameworkd, and libframeworkd-glib which is used as a tool > allowing the developer to forget about dbus management. > Collaboration and joint efforts sounds like a good idea. However, I had a look at the project description and it seemed to me that SHR focuses on development with C and gtk, which is not quite what we are aiming for, but as I said it was a short look. Could you explain how EFL fits into the picture? Regards, /mirko -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkQJdYACgkQlgX1BiMLFSgNdwCfZD/DQkP3fTCUsreCLEyB6KIf ls0AoJM8CZ8Xlp9ZidnbcAQrJGjwqkP7 =T1E6 -END PGP SIGNATURE- ___ 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: Paroli project
It sounds like a great project. My goal this year at CES is to highlight the work our community has done, let me know if you have something I can demo to the Press in January. This goes for every community project out there Steve Mirko Lindner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > FSO and EFL are ready for deployment, tichy is waiting for plugins and > Openmoko is steady on course. > So now it is time to take the next step. > > Meet paroli. It will combine the technologies mentioned above in order > to provide a unique user experience on smartphones. The first priorities > for paroli will be the dialer, contacts, sms as well as the call history > functions. Later on we will start adding other nifty features and expand > project. > > Due to the flexibility of all the technologies used we will be able to > build paroli as a collection of plugins and modules allowing every user > to use exactly the interface she/he wants. Splitting functionality from > design also allows us to skin paroli heavily without the need to rewrite > the applications code, so not only will the user get the exactly the > functions wanted but also styled in a way that feels most comfortable. > > Up to now I have been working my way through the efl, python, the fso > and how all those tie into one another. I had to discover that writing > paroli as a stand-alone application is very resource demanding we will > change the focus now and implement paroli as a tichy plug-in to make use > of the build-in python scheduler. The current source code in the svn > will be moved to a "old" or "pre-tichy" folder as soon as its > replacement is available. > > Very briefly about myself: > My name is Mirko, I am 23, originally from Berlin and now live in > Gothenburg, Sweden. My technical background is mainly web-development > and design implementation, however I also have scripting experiences in > perl, php and python as well as XML/XSL. > > I am very excited about Openmoko, the idea and the possibilities this > presents. Although there are still some problems in the software I think > the time is right for paroli as the tools needed such as the fso, the > efl and tichy have reached a stage where they can be applied easily, > provide all the functionality needed and are a reliable partner in > creating new applications. > > Paroli is meant to be a community project and as such needs your > support, codewise as well as your ideas and input on various subjects. > > I hope we can make paroli into more than an application and create a > space where we can meet, discuss and develop together. So no matter if > you are a code, a designer or simply an interested user that could help > test the application, log on to: http://code.google.com/p/paroli/ and > join the team. > > I hope you see this for what it is, an open invitation to explore, > comment and help to make paroli a success. > > More info and the source can be found on paroli's website and svn at: > http://code.google.com/p/paroli/ > > A last note, if you want to commit yourself to paroli development and > join the developers-team contact me for svn-commit rights. > > Looking forward to being creative with you, > > /mirko > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkPBtwACgkQlgX1BiMLFShq2QCfcpEwhBbh86X8/CCkTZH+/MXz > LR8An1IkURZUELdywg67BJNep/+i5KS6 > =xYb9 > -END PGP SIGNATURE- > > ___ > 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: Paroli project
Am Monday 03 November 2008 15:56:18 schrieb Marco Trevisan (Treviño): > Mirko Lindner wrote: > > > Meet paroli. It will combine the technologies mentioned above in order > > to provide a unique user experience on smartphones. The first priorities > > for paroli will be the dialer, contacts, sms as well as the call history > > functions. Later on we will start adding other nifty features and expand > > project. > > 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? > > Due to my old SIM card (small space), I never use it for saving > informations, so I need a good stack to save my contacts (using more as > more informations per person as I can provide) and messages. Qtopia imho > provides a good way to manage the contacts (from an user point of view), > Is it planned something of similar? Yes, something more flexible than plain SIM memory would be nice. > > Up to now I have been working my way through the efl, python, the fso > > and how all those tie into one another. I had to discover that writing > > paroli as a stand-alone application is very resource demanding we will > > change the focus now and implement paroli as a tichy plug-in to make use > > of the build-in python scheduler. The current source code in the svn > > will be moved to a "old" or "pre-tichy" folder as soon as its > > replacement is available. > > 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? > > Paroli is meant to be a community project and as such needs your > > support, codewise as well as your ideas and input on various subjects. > > I already tried to run it on my device some weeks ago, but it never ran > here :| Ran here, but it seemed not to be that usable yet. :) -Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marco, > > 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? > For now paroli only supports the SIM card, but as I said we are just at the beginning and this is one of the first issues we have to solve. > 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. The point is not really merging those two projects, but rather having paroli inside of tichy as plugins/applications which allows paroli to make use of tichy's scheduler. What that will look like exactly we will have to determine and see what is best for paroli and the user. > I already tried to run it on my device some weeks ago, but it never ran > here :| I just did a reinstall on my FreeRunner, was very simple and without huzzle. The details can be found here: http://code.google.com/p/paroli/wiki/RunParoli Regards, /mirko -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkPMtIACgkQlgX1BiMLFSj1yQCeJ8cZQp9Sk2nzw7HUfab+RU+e ClUAniqFrbLRebI2Sle637MNhmQ001IO =KR5Y -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
On Mon, Nov 3, 2008 at 3:12 PM, Mirko Lindner <[EMAIL PROTECTED]> wrote: > More info and the source can be found on paroli's website and svn at: > http://code.google.com/p/paroli/ > > A last note, if you want to commit yourself to paroli development and > join the developers-team contact me for svn-commit rights. Just so you know, SHR already chose this path, and we successfully built our dialer based on EFL (and currently moving to elementary), using frameworkd, and libframeworkd-glib which is used as a tool allowing the developer to forget about dbus management. Currently, there's only one UI lib, though anyone can implement a new one quite easily (in C, or whatever exposing C method hooks, a GTK one based on the old 2007.2 UI is a work in progress). Libraries - hence UIs - associated to this or that widget, dialer, messages, etc, are already configurable through, well, a configuration file :-). You can find (a short) documentation about that on our trac wiki : http://shr.bearstech.com/trac/ Maybe we should join forces ? :-) -- Julien Cassignol http://www.ainulindale.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Paroli project
Mirko Lindner wrote: > Hi all, > > FSO and EFL are ready for deployment, tichy is waiting for plugins and > Openmoko is steady on course. > So now it is time to take the next step. Nice to read this, finally! :) > Meet paroli. It will combine the technologies mentioned above in order > to provide a unique user experience on smartphones. The first priorities > for paroli will be the dialer, contacts, sms as well as the call history > functions. Later on we will start adding other nifty features and expand > project. 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? Due to my old SIM card (small space), I never use it for saving informations, so I need a good stack to save my contacts (using more as more informations per person as I can provide) and messages. Qtopia imho provides a good way to manage the contacts (from an user point of view), Is it planned something of similar? > Up to now I have been working my way through the efl, python, the fso > and how all those tie into one another. I had to discover that writing > paroli as a stand-alone application is very resource demanding we will > change the focus now and implement paroli as a tichy plug-in to make use > of the build-in python scheduler. The current source code in the svn > will be moved to a "old" or "pre-tichy" folder as soon as its > replacement is available. 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. > Paroli is meant to be a community project and as such needs your > support, codewise as well as your ideas and input on various subjects. I already tried to run it on my device some weeks ago, but it never ran here :| bye -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Paroli project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, FSO and EFL are ready for deployment, tichy is waiting for plugins and Openmoko is steady on course. So now it is time to take the next step. Meet paroli. It will combine the technologies mentioned above in order to provide a unique user experience on smartphones. The first priorities for paroli will be the dialer, contacts, sms as well as the call history functions. Later on we will start adding other nifty features and expand project. Due to the flexibility of all the technologies used we will be able to build paroli as a collection of plugins and modules allowing every user to use exactly the interface she/he wants. Splitting functionality from design also allows us to skin paroli heavily without the need to rewrite the applications code, so not only will the user get the exactly the functions wanted but also styled in a way that feels most comfortable. Up to now I have been working my way through the efl, python, the fso and how all those tie into one another. I had to discover that writing paroli as a stand-alone application is very resource demanding we will change the focus now and implement paroli as a tichy plug-in to make use of the build-in python scheduler. The current source code in the svn will be moved to a "old" or "pre-tichy" folder as soon as its replacement is available. Very briefly about myself: My name is Mirko, I am 23, originally from Berlin and now live in Gothenburg, Sweden. My technical background is mainly web-development and design implementation, however I also have scripting experiences in perl, php and python as well as XML/XSL. I am very excited about Openmoko, the idea and the possibilities this presents. Although there are still some problems in the software I think the time is right for paroli as the tools needed such as the fso, the efl and tichy have reached a stage where they can be applied easily, provide all the functionality needed and are a reliable partner in creating new applications. Paroli is meant to be a community project and as such needs your support, codewise as well as your ideas and input on various subjects. I hope we can make paroli into more than an application and create a space where we can meet, discuss and develop together. So no matter if you are a code, a designer or simply an interested user that could help test the application, log on to: http://code.google.com/p/paroli/ and join the team. I hope you see this for what it is, an open invitation to explore, comment and help to make paroli a success. More info and the source can be found on paroli's website and svn at: http://code.google.com/p/paroli/ A last note, if you want to commit yourself to paroli development and join the developers-team contact me for svn-commit rights. Looking forward to being creative with you, /mirko -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkPBtwACgkQlgX1BiMLFShq2QCfcpEwhBbh86X8/CCkTZH+/MXz LR8An1IkURZUELdywg67BJNep/+i5KS6 =xYb9 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
