Mono runtime port
As anyone tried to run mono on OpenMoko ? I'm really interested in this, and im already doing some work to see how much i can reduce it's footprint, but i don't want to reinvent the wheel and waste valuable time. So as anyone worked on this ? Regards, Daniel___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
The problem with evas as i see it, is the available developer pool. GTK as of now is more mature and has many more knowledged developers available. One other problem is that i don't see many language bindings for EFL ( at least mature ) other than Ruby, that could hinder a bit future development/support for more languages. Another option, i just thought it abiut it now, is to loose GTK and EFL altogether and use Cairo to render all the widgets, its has many backends already available including X, DirectFB and OpenGL so that wouldn't be an issue, it also has bindings for MANY languages so that isn't an issue either. It would require some initial work to program all the widgets, but i believe in the long run it would pay off. Regards, Daniel - Original Message - From: Pedro Aguilar [EMAIL PROTECTED] To: ThomasGstädtner [EMAIL PROTECTED] Cc: community@lists.openmoko.org; Florent THIERY [EMAIL PROTECTED] Sent: Friday, June 08, 2007 1:56 PM Subject: Re: UI ideas/questions or can we animate things as smooth as iPhone? Hi, We should try different options, do some serious benchmarks and based on the results we could choose the best solution. Some options would be: - X11/GTK - X11/EFL - DirectFB/GTK - DirectFB/EFL Both, GTK and EFL, have backends for X11 and DirectFB, so running demos and apps shouldn't be a problem. Running DirectFB/GTK works fine in embedded systems, I used it in a PNX8550 processor, but the Neo's processor doesn't have that processing power... According to the ELF doc, the Evas library with DirectFB backend is designed with embedded systems in mind, but I haven't tested it. At least in the i386 platform works great. One real problem I see is that for making some benchmarking we need the real hardware, an emulator wouldn't be reliable. Regards, -- Pedro Aguilar Imho the EFL are the best choise for a device like the Neo. I'm really looking forward to have a EFL-based gui as alternative to the GTK-gui. 2007/6/8, Florent THIERY [EMAIL PROTECTED]: Related tutorial : http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB_for_Embedded_Systems The choice should be driven by benchmarks results. EFLs are on the row too... Cheers Florent ___ 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fw: UI ideas/questions or can we animate things as smooth as iPhone?
OK resending this since i accidentally sent it directly to Mr John Seghers Regards, Daniel - Original Message - From: Silva, Daniel [EMAIL PROTECTED] To: John Seghers [EMAIL PROTECTED] Sent: Thursday, June 07, 2007 6:40 PM Subject: Re: UI ideas/questions or can we animate things as smooth as iPhone? - Original Message - From: John Seghers [EMAIL PROTECTED] To: 'OpenMoko' community@lists.openmoko.org Sent: Thursday, June 07, 2007 5:05 PM Subject: RE: UI ideas/questions or can we animate things as smooth as iPhone? I've been lurking, but this is something that I do have a bit of experience with--and definitely some opinions. Michael 'Mickey' Lauer wrote Tomasz Zielinski wrote: framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. I feel your pain. Trust me, it hurts me as well... The GameBoy Advance is an ARM7TDMI running at 32MHz. However, its screen size was only 240 x 160 (1/8 VGA) and it had a hardware-based sprite system as well as both bitmapped and character mapped graphics capabilities with hardware fine scrolling and multiple planes. IIRC, the GTA01 has a 266MHz processor--only a little more than 8x the GBA--and fully 8x the screen area with 16x the memory required for a bitmap. I'm 100% sure nobody will cry after pure-X11 applications we loose this way. Almost every GTK application would require rewriting/porting to fit OpenMoko capabilities, so it's not great loss too. Not to mention font and other DPI-aware issues. Interesting. Can I hear more supportive or counter arguments? What do the others think? I've been writing games since 1981, on Atari 5200, 8-bit NES, SFX, Genesis, Windows, and too many cell phones to keep track of. Please, please, please give us direct access to the frame buffer and a low level API to the Blitter in the GTA02. I don't know if you have to throw away X11 support to do so, but I do agree that you won't lose much if you do so. No you don't have to sack X11 to have access to the underlying hardware, you can interface with it through DRI ( Direct Rendering Infrastructure ), but that would kill the point of having X11, why having X11 if you access the hardware directly? And besides you would have to write a DRI driver to interface with OpenMoko hardware, since there's only a handfull of drivers available. I agree that loosing X11 per se wouldn't do much harm, but going the vanilla framebuffer way we would be loosing a lot. It would require ALOT of work to rebuild what has been done until now ( if they're really using X11+GTK ) just to go in that direction, when i believe the problem is not there. I believe people are missing few things, although i really didn't checked the code yet, i bet the code is still very umpolished and could and will be optimized. From what i've seen in the wiki, OpenMoko is still using KDrive ( trimmed down XServe implementation ) and a full glibc. Change that for something like DirectFB and uClib ( or diet libc ) and you already would start to see things shape up. Then there's loading times, for a solution like OpenMoko i wouldn't rely on dynamic linking and would go for static linking, remeber this is not a desktop system. http://www.directfb.org/docs/GTK_Embedded/summary.html If you/they must use dynamic linking i would recomment using something along the lines of prelink. A lot of statements have been made here about people flocking to the Neo *because* they can modify it. But remember that the geeks who will buy it because they can run their favorite X application, or bring up a Linux shell are the vast minority if you're looking at hundreds of thousands or millions of devices being sold. The vast majority of the purchasers are going to be people who buy it because it functions smoothly, makes great calls, and has lots of nifty eye candy. And, oh by the way, the can customize it to their heart's desire. But those customizations aren't going to be done at the Linux developer level. Those are going to be seamless plug-ins or self-installing apps that give them something they want on the phone. This also points to the need for a slick graphical app catalog/installer. Synaptic, apt-get, rpm...not going to cut it for the normal end user. There are loads and loads of cheap and really great functioning cell phones, OpenMoko/neo1973 could be the greatest phone in the world and still noe even make a small dent on the market. Sure there are people who will look for the best bang for the buck, but mus of them will just buy what's more trendy and/or has the most 'cool' factor. Just look the iPod and the more recent iPhone fenomena, neither one are the best on the class, but they have hype. neo1973/OpenMoko needs to have something that sets it apart, an for now, more than the hardware its OpenMoko and its 'promise' to be a great platform to develop
Re: UI ideas/questions or can we animate things as smooth as iPhone?
What I see is a situation very similar to the WinG (Windows Game) libraries in the Windows 95 timeframe. These allowed a Windows app to take over the entire screen and bypass GDI--even to the point of changing screen res and refresh rates. Then, when you Alt-Tab'd away, or some other reason required you to go back to other windows, you'd revert back to the normal modes. If we can have a method by which an app can take over the screen from X, and then give it back (or have it taken back if necessary) then the apps (e.g. games) that need bare-metal access can do it, and those that can perform fine within X can do that. I'm certainly not trying to say that all apps need bare-metal access, or that frameworks are a bad thing. But they become bad if they prevent you from bypassing them at need. I'm not an X expert--I've dealt with Linux as little as possible in my career--so I don't have ready access to the knowledge about what is possible, what is easy, and what just plain won't work with these systems. If we can keep X and GTK and provide a way to get maximum performance for those apps that need it...great! - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community And i agree with you, thats why in my opinion something along the lines of DirectFB should be used. This library allows developers to bypass the X and allows applications to talk directly to video hardware with a thin simple API, no need to switch anything. The better part is that DirectFB already has GTK+ support so less refactoring would be necessary, but thats the problem, some code would have to be rewritten but with projects like XDirectFB, wich alows unmodified code targeted to X to run unmodified, this could be made gradually. I believe there are many potential solutions for this 'problem' without having to hinder programming simplicity. Regards, Daniel ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
