Re: [SVHMPC] 0K Re: OpenMoko light web server
I'm still on the widget driven GUI concept. Having a single common rendering approach using HTML/Widgets would provide some interesting advantages. Not only on the graphical coherence, but also on the novel mixed/hybrid uses that will be feasible (semi web/local). Why not considering a phone's GUI as a mosaïc of widgets? Little apps for little devices... Nokia took the opposite position : www.widsets.com It needs java, and is specific. Don't you believe that native OSX/netvibes/googlehomepage widget support will be a killer app for openmoko? I may be quite stupid, but i sometimes wonder if choosing a technology should be driven by an already existing and flourishing content ecosystem. There are more than 1000 OSX widgets, 700 netvibes... All having a particular purpose. For non-believers, there's jackfield that already offers limited OS widget support: http://www.kryogenix.org/code/jackfield/ About the web/javascript core engine, everybody seems to go webkit (iphone, nokia S60, OSX dashboard...). Let's wish success to the webkit google code project! You wouln't often want to go online on mobility situations (i mean, real webbrowsing), but checking your news or searching places you already know can be very useful. And that's exactly what web widgets do... http://developers.netvibes.com/files/UWA-Widget.wdgt.zip This file is an OSX Dashboard-compatible widget, allowing to embedd any netvibes ecosystem's element; which contains (as of today): 743 modules, 84000 rss. All in a handeld form factor compatibility already. http://eco.netvibes.com/modules/ The same type of architecture (web widget in a widget) could save lots of time: no need to develop a dedicated rss reader, or small handy modules (weather, games, finance, wikipedia). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
Bryan Larsen wrote: [...] A scripting language should be chosen as the default. Yes, it'll be a hard choice, but there's also no 'wrong choice' (except for none). I've put a lot of work into http://wiki.openmoko.org/wiki/Wishlist:BuiltInScriptingLanguage. Please comment here or on the discussion page. Yes this page is very good. One thing you might want to note also is that there is a nice C++ binding for Python in boost www.boost.org. Please don't infer from this that I am a big Python fan, most of my scripting to date has been with Perl, however I do see Python as being a language that could be more generally useful as a default. Harold, Sean and the rest of the OpenMoko team: please, please make a decision, and make it soon. There are several of us that are delaying development of OpenMoko applications in the hope that a scripting language will be chosen soon. Certainly this would be nice to know. Jamie Apologies for quoting so liberally from list e-mails, but I feel it was the right thing to do. thank you, Bryan ___ 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: built-in scripting languages.
Jamie Allsop пишет: Yes this page is very good. One thing you might want to note also is that there is a nice C++ binding for Python in boost www.boost.org. Please don't infer from this that I am a big Python fan, most of my scripting to date has been with Perl, however I do see Python as being a language that could be more generally useful as a default. Once upon a time there was a nice idea to make Scheme the default scripting language for the GNU project. (And it even worked in Gimp :) Today I suddenly realized I had been wasting my time by not porting some Common Lisp implementation to OpenMoko. :) I was waiting for the hardware, but I could use an emulator! Am I correct? Will a working clisp or say, gambit scheme influence the choice of default scripting language? :) Sincerely yours, Dmitri ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
Is there a way to add a poll feature to the wiki? This would give a quantitative about the community's opinion... Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
What about: http://meta.wikimedia.org/wiki/Poll Seems strange not to have this extension in the wiki... Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
On Apr 18, 2007, at 1:44 AM, Dmitri Hrapof wrote: Jamie Allsop пишет: Yes this page is very good. One thing you might want to note also is that there is a nice C++ binding for Python in boost www.boost.org. Please don't infer from this that I am a big Python fan, most of my scripting to date has been with Perl, however I do see Python as being a language that could be more generally useful as a default. Once upon a time there was a nice idea to make Scheme the default scripting language for the GNU project. (And it even worked in Gimp :) Yes, unfortunately it was still Scheme. Today I suddenly realized I had been wasting my time by not porting some Common Lisp implementation to OpenMoko. :) Yes, you are. Get to work! :-) I was waiting for the hardware, but I could use an emulator! Am I correct? quite Will a working clisp or say, gambit scheme influence the choice of default scripting language? :) Unlikely, but I would use it. You don't want a scripting language, you want a language that makes it possible to build domain-specific languages. Jim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
PyGTK looks like the most likely contender to me -- not just because I wrote a book about it and I'm the author of almost everything Python-related in OE, but also because PyGTK is pretty mature and easy to extend (you probably have seen Zecke's work in wrapping the Moko classes did you?). The thing that worries me is the performance. The Neo1973 has a really slow CPU. I didn't test on a device yet, but I'm afraid running 'import gtk' alone will take roughly 30 seconds, if not more. We will probably have to jump through hoops to make _any_ scripting language to perform reasonably on the Neo1973 (first incarnation). Cheers, -- - 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: built-in scripting languages.
On Apr 18, 2007, at 2:41 AM, Michael 'Mickey' Lauer wrote: PyGTK looks like the most likely contender to me -- not just because I wrote a book about it and I'm the author of almost everything Python-related in OE, but also because PyGTK is pretty mature and easy to extend (you probably have seen Zecke's work in wrapping the Moko classes did you?). The thing that worries me is the performance. The Neo1973 has a really slow CPU. I didn't test on a device yet, but I'm afraid running 'import gtk' alone will take roughly 30 seconds, if not more. We will probably have to jump through hoops to make _any_ scripting language to perform reasonably on the Neo1973 (first incarnation). Well, python is known to be slow. There is plenty of CPU on the OpenMoko for something like Lua.. or lisp, or scheme might look into Chicken Scheme: http://www.call-with-current- continuation.org/index.html It runs on the Nokia 770: http://chicken.wiki.br/chicken%20on% 20handhelds, and the Zaurus, both of which have less CPU than the Neo1973. Chicken Scheme compiles to 'C'. Its fast, way faster than Python. http://curiousprogrammer.wordpress.com/2006/09/25/switching-scheme- implementations/ One of the more recent additions to Chicken is the 'Easy Foreign Function Interface'. This enables you to embed C or C++ code inside your Scheme code and it gets converted to Scheme automatically. The example given in the manual http://chicken.wiki.br/easyffi or http://www.call-with-current-continuation.org/chicken.pdf uses Chicken Scheme to write a Qt application. The Qt classes get automatic wrappers generated using the object system (TinyClos). So the actual Scheme code looks like: (define a (apply make QApplication (receive (argc+argv (define hello (make QPushButton hello world! #f)) (resize hello 100 30) (setMainWidget a hello) (show hello) (exec a) (destroy hello) (destroy a) There is a GTK SWIG for Chicken: http://wiki.freaks-unidos.net/ chicken-gtk Someone should also look into putting Einstein http:// www.kallisys.com/newton/einstein/ the NewtonOS port on the Neo1973. It already runs on the Nokia 770 and the Zaurus. Jim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages.
I think maybe we need a new version of Godwin's law... any discussion about scripting languages should stop as soon as someone mentions Lisp (or Smalltalk.) But seriously... speed probably shouldn't be THE deciding factor in a built-in scripting language. It's the ability to get things done simply. I think that's why javascript / livewire made it's way into Navigator and Spyglass. They were just enough to get done what needed doing. I've never been the worlds biggest fan of AppleScript, but I like that Apple says it's there to stitch apps together. At PalmSource, some of the Ex-Be guys worked on a tool called the Binder (now known as OpenBinder (as in http://openbinder.org/)). I come from a CORBA background, so I was slightly less than impressed that the only language bindings it supported out of the box was C++. But, for a while there, PalmSource was pushing the idea of opening up all application objects to a regular interface and adding other language bindings. So... whatever the default scripting language, let's just make sure it has a way to get at the objects exposed by applications. That being said... I vote for Smalltalk. -Cheers -Matt H. On Apr 18, 2007, at 6:47 AM, Jim Thompson wrote: On Apr 18, 2007, at 2:41 AM, Michael 'Mickey' Lauer wrote: PyGTK looks like the most likely contender to me -- not just because I wrote a book about it and I'm the author of almost everything Python-related in OE, but also because PyGTK is pretty mature and easy to extend (you probably have seen Zecke's work in wrapping the Moko classes did you?). The thing that worries me is the performance. The Neo1973 has a really slow CPU. I didn't test on a device yet, but I'm afraid running 'import gtk' alone will take roughly 30 seconds, if not more. We will probably have to jump through hoops to make _any_ scripting language to perform reasonably on the Neo1973 (first incarnation). Well, python is known to be slow. There is plenty of CPU on the OpenMoko for something like Lua.. or lisp, or scheme might look into Chicken Scheme: http://www.call-with-current- continuation.org/index.html It runs on the Nokia 770: http://chicken.wiki.br/chicken%20on% 20handhelds, and the Zaurus, both of which have less CPU than the Neo1973. Chicken Scheme compiles to 'C'. Its fast, way faster than Python. http://curiousprogrammer.wordpress.com/2006/09/25/switching-scheme- implementations/ One of the more recent additions to Chicken is the 'Easy Foreign Function Interface'. This enables you to embed C or C++ code inside your Scheme code and it gets converted to Scheme automatically. The example given in the manual http://chicken.wiki.br/easyffi or http://www.call-with-current-continuation.org/chicken.pdf uses Chicken Scheme to write a Qt application. The Qt classes get automatic wrappers generated using the object system (TinyClos). So the actual Scheme code looks like: (define a (apply make QApplication (receive (argc+argv (define hello (make QPushButton hello world! #f)) (resize hello 100 30) (setMainWidget a hello) (show hello) (exec a) (destroy hello) (destroy a) There is a GTK SWIG for Chicken: http://wiki.freaks-unidos.net/ chicken-gtk Someone should also look into putting Einstein http:// www.kallisys.com/newton/einstein/ the NewtonOS port on the Neo1973. It already runs on the Nokia 770 and the Zaurus. Jim ___ 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: built-in scripting languages.
Am 18.04.2007 um 19:02 schrieb Matthew S. Hamrick: I think maybe we need a new version of Godwin's law... any discussion about scripting languages should stop as soon as someone mentions Lisp (or Smalltalk.) Well, as a Mac addict, I propose to consider AppleScript, Automator and F-Script :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Status update on the phones?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I was wondering (along, I'm sure, with many others here on this list) what the current status is of the P1 phones. Is there 'light at the end of the tunnel' yet, for you guys? :) A few weeks ago, Sean mentioned some problems that might be quickly fixed, or might need another hardware spin. I'm curious what it eventually was/is. :) Also, can translators already start doing some work on (some of) the apps (aside from the Wiki that is), or are these apps still too much in flux? If we can start translating, is there somewhere a way to be able to grab the sources, and update the translation files? I tried the rsync instructions on this page: http://wiki.openmoko.org/wiki/OpenMoko#Developer_Workstations But that didn't work out for me. (my coding skills are rusty, and I don't have much experience working with rsync or with svn.) Or do I need to use the Openmoko makefile to grab these files? sincerely, Marcel de Jong -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGJpZslO32TmuZymsRAib0AJ0WPLu00EryEeMDUufcRhbxfSW2wQCdE7/s VJk/7Liyi57/ysu47Gqz6Sw= =c04U -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
picture viewer
Hay, Browsing the wiki, I found that the picture viewer was to be a stylus application. Viewing photos is something you do together, making it very unpractical to do with a stylus. I think it should be a combination of both stylus and finger. Managing and looking for a specific dir should be done with a stylus. Here the approach should be like with the RSS-reader. At the top a list of photos in your current directory, at the bottom a preview. Then you should be able to switch to either slide show or full screen-mode. Both are the same, with the exception of course that the slide show switches the photo's automatically (and will rotate them so that the most amount of screen space is used) In full screen or slide show mode, if you then press the screen, 5 controls will appear: - scroll-wheel - Either for zooming or switching between the photos - button to switch to either zoom or next-prev-picture mode - button to rotate the picture 90 dec clockwise - button to remove the on screen controls again. (so that you will only see the picture, until you press the screen again) - a button to go back to stylus mode here are two mock ups, note that the left most button will change from zoom - switch mode. http://i172.photobucket.com/albums/w29/baldr_OM/photo_viewer_zoom_mode.png http://i172.photobucket.com/albums/w29/baldr_OM/photo_viewer_slideshow_mode.png Kind regards, Frank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community