Re: Plea to developers: Make data for all applications available to scripting languages
Giles Jones wrote: On 15 Sep 2007, at 22:53, J F wrote: What I would like to see is ALL programs having a way of getting at their data from a scripting language. I don't know if it makes sense to have some guidelines for developers to make it easier for this information to be got at. This would be for someone more competent than me to suggest. Quite simply, if long term storage utilises and embedded database then so long as the scripting language can access it then it will be fine. Only if the database supports concurrent access by multiple processes, which most don't. You'd be better off supporting a single standard API to obtain the obvious data such as contacts/calendar/todos (EDS being the one that I believe that the developers have settled on). Which leads to a question: is there some way to extend the information held for each EDS entity so that calendar entries contacts and the like can have additional (arbitrary) fields? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Plea to developers: Make data for all applications available to scripting languages
On 16 Sep 2007, at 10:04, Jim McDonald wrote: Only if the database supports concurrent access by multiple processes, which most don't. You'd be better off supporting a single standard API to obtain the obvious data such as contacts/ calendar/todos (EDS being the one that I believe that the developers have settled on). Which leads to a question: is there some way to extend the information held for each EDS entity so that calendar entries contacts and the like can have additional (arbitrary) fields? Some databases have a locking mechanism, you can lock the table while you update it, the other process would get queued. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Plea to developers: Make data for all applications available to scripting languages
What I would like to see is ALL programs having a way of getting at their data from a scripting language. I don't know if it makes sense to have some guidelines for developers to make it easier for this information to be got at. This would be for someone more competent than me to suggest. Quite simply, if long term storage utilises and embedded database then so long as the scripting language can access it then it will be fine. Only if the database supports concurrent access by multiple processes, which most don't. You'd be better off supporting a single standard API to obtain the obvious data such as contacts/calendar/todos (EDS being the one that I believe that the developers have settled on). Which leads to a question: is there some way to extend the information held for each EDS entity so that calendar entries contacts and the like can have additional (arbitrary) fields? Underneath eds, there's VCARD, rfc 2426, http://www.ietf.org/rfc/rfc2426.txt It's an ancient-looking format that everybody is using. As messy as it it, I have little doubt that OpenMoko will keep using it. In various places, the TYPE can handle only a few values. So for instance, a person can have a Delivery Address for home, work, but none other. a non-delivery address does not exist, as far as I can see (so I bet ADR, the delivery address, gets abused a lot). A limit of two addresses for a contacts is... so low, I have a feeling I must be missing something. Evolution has an 'other' address, for instance, but I can not find that in the RFC. You can specify X-OPENMOKO-SOMETHING lines, which I guess would work, i.e. we can have our local openmoko app show the values, but will be ignored by Evolution (i.e. not shown, yet retained) if you transfer your data. I am tempted to dump my own data in lines like that, until I find a better solution. There's a whole series of X-EVOLUTION-* lines in vcards exported by evolution, too. The related calender format is iCal, rfc 2445. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debug board
Paul Jimenez wrote: On Saturday, Sep 15, 2007, Michael 'Mickey' Lauer writes: [EMAIL PROTECTED] wrote: does anyone happen to know if the debug board of the advanced Neo kit will be compatible with future versions of the Neo (or other FIC OpenMok o phones, at that)? It will definitely be compatible w/ GTA02. As for the successor models, we can't make a definitive answer yet (there is not even schematics nor silicon for those anyways ;), but of course we'll try to make it compatible... Does this means there're no plans on the drawing board for GTA03? Read my mail again. Plans don't start with schematics and silicon... -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: webkit do_compile failed
On Sat, 2007-09-15 at 20:15 -0500, Tom Z wrote: I seemed to hit a problem just before the do_compile in the same build process for webkit, all the solutions posted here so far don't seem to apply, as there seems to have no build/tmp/staging/arm-angstrom-linux-gnueabi/lib/libWebKitGdk.* file yet in my build directory. Below is the log from my rebuild attempt, after I did the clean-package-webkit-gtk. Any idea would be greatly appreciated. Tom Hello, Changing SRCREV_pn-webkit-gtk to 25582 in /openembedded/conf/distro/include/sane-srcrevs.inc seems to solve the problem. Regards Sudharshan S blog: http://www.sudharsh.wordpress.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
libidn build fails in the current svn head
Hello everyone, I man having problems building libidn and would like to know if any one has this problem and/or gotten around the same. One thing from the logs i noticed was the fact that the build system is trying to install it before the do_compile stage..I guess this is weird or am i mistaken. Here are the logs, NOTE: package libidn-0.5.19: started NOTE: package libidn-0.5.19-r0: task do_install: started ERROR: function do_install failed ERROR: log data follows (/home/sudharsh/Projects/openmoko/build/tmp/work/armv4t-angstrom-linux-gnueabi/libidn-0.5.19-r0/temp/log.do_install.31536) | NOTE: make DESTDIR=/home/sudharsh/Projects/openmoko/build/tmp/work/armv4t-angstrom-linux-gnueabi/libidn-0.5.19-r0/image install | make[1]: Entering directory `/home/sudharsh/Projects/openmoko/build/tmp/work/armv4t-angstrom-linux-gnueabi/libidn-0.5.19-r0/libidn-0.5.19' | make[1]: *** No rule to make target `install'. Stop. | make[1]: Leaving directory `/home/sudharsh/Projects/openmoko/build/tmp/work/armv4t-angstrom-linux-gnueabi/libidn-0.5.19-r0/libidn-0.5.19' | FATAL: oe_runmake failed NOTE: Task failed: /home/sudharsh/Projects/openmoko/build/tmp/work/armv4t-angstrom-linux-gnueabi/libidn-0.5.19-r0/temp/log.do_install.31536 NOTE: package libidn-0.5.19-r0: task do_install: failed ERROR: TaskFailed event exception, aborting NOTE: package libidn-0.5.19: failed ERROR: Build of /home/sudharsh/Projects/openmoko/openembedded/packages/gpephone/libidn_0.5.19.bb do_install failed ERROR: Task 2854 (/home/sudharsh/Projects/openmoko/openembedded/packages/gpephone/libidn_0.5.19.bb, do_install) failed NOTE: Tasks Summary: Attempted 1555 tasks of which 1543 didn't need to be rerun and 1 failed. ERROR: '/home/sudharsh/Projects/openmoko/openembedded/packages/gpephone/libidn_0.5.19.bb' failed make: *** [openmoko-devel-image] Error 1 Regards Sudharshan S - blog: http://www.sudharsh.wordpress.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
Hello some months ago I discovered openmoko, this is a great project. I definately will buy one of these phones. What do users expect from a phone? At the moment, there are some hype-phones, like - nokia N95 (with 5 Mega Pixel Camera) - iphone (with a big Mp3 storage) - some phones experimenting with watching TV on the phone - Wlan is impemented - and a lot of providers offer now data flat rates to be always on.. for chatting, Instant Messenger and Mail check. Hope, with openmoke we as well can make pictures with 5 MP, listeing to music and maybe FM radio, to watch TV and Chat with our friends in the internet. I want to suggest to support these innovative standard for wathing TV and contacting friends. a) Watching TV There is a big competition of DMB and DVB-H, while DVB-H has a back-channel, it allows more data logging of users behaviours. We do not want that, users must be able to watch TV anoymous, without any logging, which channel they watch. Though, this would be offered with DMB, but here as wel it is possible to have Payed-TV. In general, we needs a Phone-TV, which is free and has not to be payed. This offers only DVB-T (and there is as well DVB-T2 (HD) on the roads). And: there is worldwide only one phone, which supports DVB-T. this is unfortunately on windiws mobile. Hope, that Openmoko can support as well the free, unpaids DVB-T on linux: GSmart t600 http://www.gigabytecm.com/eng/gbc_product.feature.aspx?pid=40tid=tabIndex=2Num= http://www.gigabytecm.com/eng/gbc_supportdetail.aspx?sid=69 http://www.gigabytecm.com/eng/gbc_supportdetail.aspx?sid=80 So my question is, is there any initiative, to support DVB-T Television in Openmoko? b) More and more Data-Flatrates are offered from Phone-Providers. This is uses only for surfing the web, emailing and most of all: instant messaging (the Gsart T 600 has MSN buddylist) Because users use then their mobile phones to keep in touch of their fiends, which should be free communication as well, we need a buddylist for openmoko. Here an open standard yould be used, and I suggest to use the latest one, without servers: http://sourceforge.net/forum/forum.php?forum_id=618174 This buddylist is baed on a DHT, so the IP of the friend is found again in any online session. Furthermore it does not require any server. Third all communication is encrypted. maybe later on as well VOIP is possible over this security layer. Fourth, the client application suppoerts as well an email client, so all in one and I guess this is perfect for openmoko-users. IF you want secure VOIP calles, then now the basis should be done with the implementation of this buddylist. Currently the gui is a QT gui. And a wxwidget gui si planned to implement it into imule application from i2p.net. Dunno, which gui is better for a openmoko application. So I have the question, if openmoko applicartions should have better a wxwidget gui or a QT gui? Maybe a coder is interested to start with this messenger? c) there is a new way out for phoning without any phohe provider: Mesh-Networks. http://www.terranet.se/ http://www.heise.de/newsticker/meldung/print/95960 is offering a mesh network, which allows to hop from phone to phone until there is an out-proxy to the internet or phone provider. Therefor the openmoko needs Wlan. So my question is, does Openmoko suppoert Wlan? There is a new protokol out for that, OLSR and B.A.T.M.A.N. (Better Approach to mobil adhoc Networks) https://www.open-mesh.net/batman http://en.wikipedia.org/wiki/OLSR http://en.wikipedia.org/wiki/B.A.T.M.A.N. So my question is, would it be of interest, to cooperate with the batman group to implement a hopping network into openmoko? and the question, if there is a WLan Interface? Maybe some of you can contact the three suggested sub-projects and implement a startup of the existing code into openmoko? Thanks and kind regards. Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Debug board
Yeah, I think the core team and a great deal of the rest of the community would prefer OpenMoko to get the OS stable and core features working before they start working on the third device. Don't get ahead of yourself. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, September 16, 2007 5:15 AM To: List for OpenMoko community discussion Subject: Re: Debug board Paul Jimenez wrote: On Saturday, Sep 15, 2007, Michael 'Mickey' Lauer writes: [EMAIL PROTECTED] wrote: does anyone happen to know if the debug board of the advanced Neo kit will be compatible with future versions of the Neo (or other FIC OpenMok o phones, at that)? It will definitely be compatible w/ GTA02. As for the successor models, we can't make a definitive answer yet (there is not even schematics nor silicon for those anyways ;), but of course we'll try to make it compatible... Does this means there're no plans on the drawing board for GTA03? Read my mail again. Plans don't start with schematics and silicon... -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ 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: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
On 9/16/07, Michael Schmidt [EMAIL PROTECTED] wrote: Currently the gui is a QT gui. And a wxwidget gui si planned to implement it into imule application from i2p.net. Dunno, which gui is better for a openmoko application. So I have the question, if openmoko applicartions should have better a wxwidget gui or a QT gui? Maybe a coder is interested to start with this messenger? Openmoko uses GTK+-2.x for GUI which is under LGPL. There is a lot of im clients available, and there has been a discussion about it in the list. Try to search up old posts. To focus on tv support before movie playback support would be strange. Right now it is important to get the software fast and stable, and add basic support for sms, phone calls, etc. This is only my opinion. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
On 16 Sep 2007, at 19:51, Flemming Richter Mikkelsen wrote: To focus on tv support before movie playback support would be strange. Right now it is important to get the software fast and stable, and add basic support for sms, phone calls, etc. This is only my opinion. Indeed and I've had a phone with TV and it was totally rubbish. It's hard enough getting a decent phone signal on the move sometimes never mind TV? You also run into issues of licencing, the TV phone I used required a licence fee each month, there's no way they would allow such a thing to be open source compatible as people would be able to hack it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
On 9/16/07, Flemming Richter Mikkelsen [EMAIL PROTECTED] Giles Jones [EMAIL PROTECTED] wrote# Openmoko uses GTK+-2.x for GUI which is under LGPL. There is a lot of im clients available, and there has been a discussion about it in the list. Try to search up old posts. to be open this means the IM is only jabber or Rs, the serverless IM. I would suggest the serverless. GTk.. does this mean, every app needs that too or could a QT gui be used as well? As RS IM is a c++ library, maybe someone is interested to make a GTK gui? A FLTK gui is already there as well. You also run into issues of licencing, the TV phone I used required a licence fee each month, there's no way they would allow such a thing to be open source compatible as people would be able to hack it. DVB-T does not need any licence agreement, it is just terrestrial recieving on a phone. Therefore the display should be bigger... So this requires not a media player, but as well some hardware adjusting, a DVB-T Reciever chip and a bigger display. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
On 16 Sep 2007, at 22:16, Michael Schmidt wrote: DVB-T does not need any licence agreement, it is just terrestrial recieving on a phone. Therefore the display should be bigger... So this requires not a media player, but as well some hardware adjusting, a DVB-T Reciever chip and a bigger display. It's DVB-H not DVB-T on a handheld. We've yet to see how each country handles the system. DVB-T has conditional access for some channels in the UK. Not sure about DVB-H. There are higher priorities at this time. It needs hardware adding to the phone which joins a large list of other things people are asking for. Some people want media, some want messaging, others want compactness, others wants gaming, others want GPS etc... To add all results in a swiss army knife type phone, bulky. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
On 9/16/07, Michael Schmidt [EMAIL PROTECTED] wrote: On 9/16/07, Flemming Richter Mikkelsen [EMAIL PROTECTED] Giles Jones [EMAIL PROTECTED] wrote# Openmoko uses GTK+-2.x for GUI which is under LGPL. There is a lot of im clients available, and there has been a discussion about it in the list. Try to search up old posts. to be open this means the IM is only jabber or Rs, the serverless IM. I would suggest the serverless. GTk.. does this mean, every app needs that too or could a QT gui be used as well? As RS IM is a c++ library, maybe someone is interested to make a GTK gui? A FLTK gui is already there as well. You can install Qt if you like, but you cannot assume that all users will do that. Qt takes a lot of space ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
It's DVB-H not DVB-T on a handheld. We've yet to see how each country handles the system. DVB-T has conditional access for some channels in the UK. Not sure about DVB-H. you missunderstood me, this is exactly my point, use DVB-T and not DVB-H. There is the Gsmart T600 phone in my first mail linked, which has DVB-T. It works, It works only not, i if you drive in a car with fast speed. Only DVB-T allows an anonymous usage. DVB-.H has a back.channel and is tracking users. As well DVB-T2 Standard for high density Television is on its way... so just DVB-T is needs for a start.. Some people want media, some want messaging, others want compactness, others wants gaming, others want GPS etc... To add all results in a swiss army knife type phone, bulky. Right.. but this is the approach to a modern IPhone: Phone, mp3, 5MP-Photo, and Television. Data flatrates offer Instant Messaging, and for Afrika we get a Mesh network, which could be B.a.t.m.a.n... so we need three subteams to do some research in these fields.. as I see, that even the DVB-T Request has not been understood.. all users want free TV and watch PPLive sports and not encrypted TV... with DVB-T this phone would be ahead of all... Why paying, if all the country has terrestrial TV for Free? So the request is indeed to make right from the beginning the display a little bit wider to the ends and not rounded ends, but cutted edges at the phone, so that a bigger display is possible... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3 requests/questions for Openmoko: DVB-T / Buddylist / Batman-Mesh
Michael Schmidt writes: On 9/16/07, Flemming Richter Mikkelsen [EMAIL PROTECTED] wrote: You can install Qt if you like, but you cannot assume that all users will do that. Qt takes a lot of space Qt is the future, would it be possible to pre-install the open libraries? Or aren t the needed classes and widgets of QT then in the gui of each app, so that the whole QT library need not ot be installed? just the app? It's a future, not necessarily the' future. I'm a very happy GTK user. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: application idea
On 9/13/07, Tilman Baumann [EMAIL PROTECTED] wrote: The biggest challenge would be a mapping from gps coordinates to regions/postcodes or such. I believe Yahoo maps among others provides this geocoding data, but as I think of it, this could blow out into something larger: Imagine a defined standard for location based data, similar to the way RSS works. as a start, we define a URL scheme, such as domain.tld/channel?lat=latitudelon=longitudetype=UTM|NAD87|insert coordinate system here the schema for the return document should include a 4 dimensional map for when/where the data is good (I.E. we give forecasts for the next 30 mins or so, inside of your zipcode) as well as a way to specify rich content(weather, photos, loose women living nearby whatever people so choose). The user should be able to override the server's data (you decide you only want weather updates every hour for instance) there should also be a way to send up login information for services which need user data, and if you're worried, you would have the option of using ghost locations... I.E. transmitting fake locations so that you can't be tracked, with the results discarded... for those worried about that kind of thing. Maybe using TOR for the anonymous sites would work too. I'm also thinking that this could be used to store your location... and show other nearby users(I probably wouldn't use it, but the potential is there) From there, we build a reader application (this is why I'm likening it to RSS feeds). This wouldn't be limited to just the openmoko, but other GPS enabled devices anyways, I'm sure I'll get about 3 emails about ways this is already being done, but what do people think? -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
dialer suggestion
kinda tongue-in-cheek, but... so kinetic scrolling works now and all the 'dialer' does is capture numbers to send to the GSM chip. what about an old-school dialer? OK, maybe 'retro' is a better name at this point. ROTARY baby! kitsch. flare. nobodyelsehasit. (maybe there is a reason for that last one) I dunno - crazy idea, but it could look really cool - what the H are you doing? - I'm dialing my cell phone, jeez I have no photoshop skillz, so all I can tell you is: find an old rotary dial phone - make it look like that. - like a virtual of these: http://www.makezine.com/blog/archive/2005/06/portable_rotary.html (just the dialer) priority (1 is high): 99 or 999 it's at least as important as TV. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Short guide how to run gllin with chroot
Hello. Shawn Rutledge pisze: Thanks, it's a convenient package. But I'm getting an error from gllin: test_cmd_receive_count = 22 gllin: early exit(3) in halInit()/674 gllin: -periodic[9] 1 gllin: ../../../src/hal_linux_tt.c:1043: glcb_ExceptionAssert: Assertion `0' failed. I've updated my article. What happens with gllin I can't excuse but gllin is still working. Just invoke tail -f /home/root/gps.txt and you'll see new data incoming. This is the proof that gllin still works. If you don't see new data there's a problem. First of all update you Openmoko to latest release (especially to 2007.2 if you still have 2007.1). Check if it helps. Best regards, -- *Bartlomiej Zdanowski* Programmer Product Research Development Department AutoGuard S.A. Place of registration: Regional Court for the Capital City of Warsaw Registration no.: 287629 Share capital: 1 059 000 PLN Polish VAT and tax ID no.: PL1132219747 Omulewska 27 street 04-128 Warsaw Poland phone +48 22 611 69 23 www.autoguard.pl http://www.autoguard.pl ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
