Re: GSoC 2008: Call for ideas
As I am not an owner of a Neo myself, I do not if this has already been done. What about making it possible to listen music, and as a call comes in(and you answer it), make the music pause. I know this is a small thing, though I don't know how easy it is to implement, but I think it would be quite neat! Best Regards, Jens __ 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
I was thinking to a port of AirStrike (http://icculus.org/airstrike/) but there is the need of SDL-image port I am waiting for FreeRunner :) ___ 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: GSoC 2008: Call for ideas
Sqlite port would be nice thing to have. (With C/C++/Python bindings, of course) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
already there, thanks to openembedded: http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/ipk/armv4t/sqlite3_3.5.6-r0_armv4t.ipk On Tue, 2008-03-11 at 22:52 +0200, Ilja O. wrote: Sqlite port would be nice thing to have. (With C/C++/Python bindings, of course) ___ 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: GSoC 2008: Call for ideas
Hello. In my opinion, there are some highly usable project proposals in wish list, that could be done by student (like me, heh-heh-heh...) during summer. First things first: platform should provide more than one GUI binding solutions. In my opinion binding framework porting priority is (decreasing): 1) qt 2) wx 3) sdl (Since Maemo/Cocoa bindins are not widely used in current world, I think that these bindings are in would-be-nice-to-have[when-we'll-have-free-time] class) In my opinion, GUI bindings are great projects for GSoc, since they are useful and easy to create (at least it looks so, since Openmoko has standard GTK base, that by these frameworks already can use on the PC). Also, C++ bindings are must-have (but I have no clue about how mush work it will be to implement them) Python binding is good-to-have thing, since Python language is great for prototyping (but I don't think that it would be great idea to write real application on Openmoko due to embedded platform limitations). Also, platform *must* include high-level bindings for standard phone functionality, like sending SMS to the given number (with given text, of course), making a call, cancelling call, getting GPS coordinates, sending visit card using bluetooth, bt device pairing, connecting to bt device... it's quite easy to build such list. But some has to implement it all. (IMHO, all tese API functions should be accessible via dbus). As my device driver programming experience shows, it is quite possible to accomplish such thing during summer (not all at once, of course. Someone should be playing with bt, someone with gsm module... But I assume that you are much more aware of all these organization issues than me. Btw, please, please, release freerunner! In March! Can't hold... much longer ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GSoC 2008: Call for ideas
Hi folks, OpenMoko Inc. will apply for Google SoC 2008. For a successfull application, we need to have a comprehensive list of ideas. A first scratch at that is @ http://wiki.openmoko.org/wiki/Summer_of_Code_2008 -- please help us adding to that. Some rough guidelines: * Please add only ideas that can be realized within the time constraints of google SoC. * Please add only ideas that end up in a software deliverable, e.g. an application or a library. * As OM lacks in middleware, please prefer middleware projects before application level projects. However, as every part of middleware should be application driven, the middleware deliverables should always include a demo application. I want to compile the mentoring application on Tuesday, 11th -- please make sure all your great ideas are in by then. Cheers, Mickey. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
For middleware, it looks like all that's really needed is an OM version of Cocoa's NSNotificationCenter. IMHO I think it's a great place to start -- just a filtered event channel with a C-callable API for publishing/listening for events. I'd prefer a design that's simple reliable for small data packets over one that's overdesigned for the 1% of the time when you want to transfer bulk data. If I may suggest a starting point, something readable like XML would be preferable over some binary representation of data. That way, later it could be extended to interact with web services. Also a *lot* easier to debug, and plenty of small/simple and large/complex libraries available to parse it. With that said, the application API should have two layers: an XML-based I/O layer that does all the low-level work, and a string-based convenience library that does most jobs an app would want, without having to make them muck around with the XML format unless they had to get fancy. It'll also help standardize the formats of the events easier -- as most would just use the facilities of the higher-level API. Also, remember to standardize common event names with #defines in some header files. It'd be nice to avoid spelling-related bugs. The highest-level api would be something this simple: event_listen ( POWER_MANAGER, POWER_LOW, handle_power_low ); event_listen would call two APIs: Document *req = build_standard_request (POWER_MANAGER, POWER_LOW); listen_event ( req, handle_power_low ) (Where Document is just a simple DOM tree) If someone wanted to put together a more complex event than build_standard_request does, they could build it themselves and send it over. Or, event_listen could just be equivalent to these APIs, but really just do an sprintf() and send the result over the wire itself. As long as both options are available to the developer, I'm happy. The interface is what matters to me -- the implementation is a lot easier to change once apps are built atop of it. It looks like another convenience API to emit a signal when an event occurs would also be useful. The simplest method for doing so would be to pass a signal-emitting function into event_listen. As for a test app, a pair of programs that talk through the middleware would be useful. Especially if they used different message types and handled them differently, so that the client-side API is given a fair shake. Also, one as a daemon, and one as a graphical app. Should get the APIs pretty well vetted. On Sun, Mar 9, 2008 at 7:00 AM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Hi folks, OpenMoko Inc. will apply for Google SoC 2008. For a successfull application, we need to have a comprehensive list of ideas. A first scratch at that is @ http://wiki.openmoko.org/wiki/Summer_of_Code_2008 -- please help us adding to that. Some rough guidelines: * Please add only ideas that can be realized within the time constraints of google SoC. * Please add only ideas that end up in a software deliverable, e.g. an application or a library. * As OM lacks in middleware, please prefer middleware projects before application level projects. However, as every part of middleware should be application driven, the middleware deliverables should always include a demo application. I want to compile the mentoring application on Tuesday, 11th -- please make sure all your great ideas are in by then. Cheers, Mickey. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
Lally Singh wrote: For middleware, it looks like all that's really needed is an OM version of Cocoa's NSNotificationCenter. IMHO I think it's a great place to start -- just a filtered event channel with a C-callable API for publishing/listening for events. I'd prefer a design that's simple reliable for small data packets over one that's overdesigned for the 1% of the time when you want to transfer bulk data. thats there already. its called d-bus and used by lots of gtk/gnome/glib apps already please take a look at http://www.freedesktop.org/wiki/Software/dbus thanks for your suggestion anyways kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008: Call for ideas
Cool, can we use it directly or need a port? On Sun, Mar 9, 2008 at 4:03 PM, Joachim Steiger [EMAIL PROTECTED] wrote: Lally Singh wrote: For middleware, it looks like all that's really needed is an OM version of Cocoa's NSNotificationCenter. IMHO I think it's a great place to start -- just a filtered event channel with a C-callable API for publishing/listening for events. I'd prefer a design that's simple reliable for small data packets over one that's overdesigned for the 1% of the time when you want to transfer bulk data. thats there already. its called d-bus and used by lots of gtk/gnome/glib apps already please take a look at http://www.freedesktop.org/wiki/Software/dbus thanks for your suggestion anyways kind regards -- Joachim Steiger developer relations/support -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
