Re: UI ideas/questions or can we animate things as smooth as iPhone?
On 6/8/07, Pedro Aguilar [EMAIL PROTECTED] wrote: Hi, Sorry being that late to reply. 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. I'd not go with DirectFB, because X11 is not that slow, you can use Shm extension and it will be fast, you also get some things for free, like remote sessions to control or be controlled by a bigger machine. Also, many apps will run out-of-the box with X11, which is not true with DirectFB. 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. I'm working on Evas for embedded systems, mainly focused on Maemo, where I do the real hw tests, rasterman is helping me with most issues. We're developing software_16 and software_16_x11, with some optimizations going into core system, like my optimizations to speed up region operations (avoid overlap, merge neighbor rectangles), things that are fast on desktop but on slower cpu with smaller data caches become an issue. Still many things are missing, no scale or text so far, but I hope to add those until the end of June. One real problem I see is that for making some benchmarking we need the real hardware, an emulator wouldn't be reliable. yes, probably I'll try to get one so I can do my tests... but you can get my code straight from e17 cvs (remember to choose it at ./configure), so far no ecore_evas support, so you need to init your engine by hand, just use expedite (benchmark tool) and check improvements. PS: my personal think is that we're already full of desktop apps and they just don't fit or are usable in embedded systems, Maemo/Nokia products can show how many GTK/Gnome apps are ported and used or useful, it doesn't pay, except by complex apps like Gnumeric, Abiword, but these can be embedded somehow... but following these lines, we should go with Qt and get the whole Koffice and Kontact.In other words, we need to write custom UI for these devices, with different guidelines. For this purpose, EFL fits better than GTK, you can write your beautiful main UI using Edje and when forms are required, you place ETK or EWL there... the inverse of we have now with GTK where we try to make widgets fit or dirty hacks to get the visual we want... in Edje it's just simple, you can place things using relative positioning, via script, UI is totally scriptable. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ 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?
Following the there's much more than GFX effects in a usable UI, here's an interesting blog post: http://www.codinghorror.com/blog/archives/000883.html It's not about embedded devices GUI, rather about desktop apps vs. web apps. However, mutatis mutandis, it drives another nail in the same coffin: application UIs thought in terms of classic desktop widgets lag way behind in terms of usability. Moreover, I believe there are ways to leverage the search-based API which makes google apps so ergonomic into embedded devices, provided that we can find a proper input method. Of course this input method wouldn't be Win32/OSX/GTK/KDE-like widgets, nor some clunky keyboard replacement. ___ 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?
Hi, On Fri, 2007-06-08 at 15:04 +0100, Silva, Daniel wrote: 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. Yes, I agree, but the interesting part of Evas is the concepts it uses for drawing things, it is transparent for the developer the way the widget are redrawn. I just think that I could be nice to try it. 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. If we have to program all the widgets with Cairo, we could come back to GTK+ that already uses Cairo and save the widgets programming effort :) It would require some initial work to program all the widgets, but i believe in the long run it would pay off. Regards, Daniel Regards, -- Pedro Aguilar - 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
Re: UI ideas/questions or can we animate things as smooth as iPhone?
Imho the EFL are the best choise for a device like the Neo. But, which backend for evas ? Framebuffer ? X ? OpenGL (i don't think there's an evas Opengl ES implementation..) ? ___ 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?
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
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
Re: UI ideas/questions or can we animate things as smooth as iPhone?
Openmoko has 2 goals, right? One is to make a FOSS stack for mobile phones, and two is to make 'your parents' want it. For that last bit, you might need to have a consistent, but also clear and fluid (direct reaction to touch actions for example, click delay is really confusing for people). The devices used are no full-blown computers. So why use software made for computers? I agree we need something that works rapidly in mobile devices. If GTK/Matchbox can do that, then it's fine with me. If it isn't, then more then just cross-compilation will be necessary to get something running on Openmoko, which is fine too, because it's still open-source. It might take a little longer to get something to work, but it'll work properly. The graphics should be quick on slow devices. Not necessarily fluid (like the iPhone) but responsive (like PalmOS). but that's just my 2 cents. -- Luit On 6/7/07, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Tomasz Zielinski wrote: If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other 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... 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? Regards, -- - 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: UI ideas/questions or can we animate things as smooth as iPhone?
On 6/7/07, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Tomasz Zielinski wrote: If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other 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... 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'm only interested in graphic effects if they improve the ease and speed of my interactions with the phone. Most of graphic effects don't fit in that category on computers, and my gut feeling is that the smaller the screen, the worse it gets. I want something: - fast. Don't wan't to wait 1 second everytime I open a menu in order to get it half transparent (and therefore less legible BTW). Maybe I don't want a menu-based UI at all, actually. - easily and deeply configurable: because even *I* can't tell what's the perfect UI for myself without a lot of experimenting. Empowering the users is not only about giving them the sources, it's also about making them as easy to change as possible, so the rapid prototyping abilities of the whole framework are extremely important. And actually, I might want it bad enough to implement it. I'd bet on some tiny, X11-less GUI for responsiveness, plus a layer of Lua bindings for the rapid prototyping aspects. Anyway, AFAIK the widgets implemented in the common, big open-source toolkits have been designed for big screen + mouse, so it's more important to easily write new widgets than having loads of unadapted, XVGA-oriented ones. Note that this approach is not incompatible with the heavier, GTK-based one: once an interesting user experience is found on a lightweight and easy to tweak UI, it can be transposed on the heavy one(s). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
R: UI ideas/questions or can we animate things as smooth as iPhone?
I agree that target #2 are my parents, but at this stage iPhone-like fluidity should't be at the top of the priority list. The first prerequisite is responsiveness. The device must react quickly, say: - 15s device startup - 1s startup of commonly used application (dialer, contacts, agenda) - 1s switching between applications - 0.5s interaction within the application - ~5s startup of other (bulkier) applications Sample figures, some can be higher or lower but we should fix reasonable targets. Then we must choose a system software library architecture that is able to guarantee the above, at least for GTA-02 (CPU is going to be only 50% faster than 01...). I'm also fine with GTK, but it seems that the device currently shipped can't get even near to those figures. Note that the current sw architecture is deeply layered, which is great for developing and mantaining applications, but on the other hand apps tend to run slower. It's a trade. Then, if we got here and we still have some spare CPU ticks, we can use them for bells, whistles smoothing things as the iPhone does. Maybe the newer GPU in -02 will help. Br Michele -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Luit van Drongelen Inviato: giovedì 7 giugno 2007 9.54 A: OpenMoko Oggetto: Re: UI ideas/questions or can we animate things as smooth as iPhone? Openmoko has 2 goals, right? One is to make a FOSS stack for mobile phones, and two is to make 'your parents' want it. For that last bit, you might need to have a consistent, but also clear and fluid (direct reaction to touch actions for example, click delay is really confusing for people). The devices used are no full-blown computers. So why use software made for computers? I agree we need something that works rapidly in mobile devices. If GTK/Matchbox can do that, then it's fine with me. If it isn't, then more then just cross-compilation will be necessary to get something running on Openmoko, which is fine too, because it's still open-source. It might take a little longer to get something to work, but it'll work properly. The graphics should be quick on slow devices. Not necessarily fluid (like the iPhone) but responsive (like PalmOS). but that's just my 2 cents. -- Luit On 6/7/07, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Tomasz Zielinski wrote: If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other 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... 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? Regards, -- - 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 ___ 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?
On Thu, 2007-06-07 at 11:29 +0200, Fabien wrote: On 6/7/07, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Tomasz Zielinski wrote: If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other 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... 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'm only interested in graphic effects if they improve the ease and speed of my interactions with the phone. Most of graphic effects don't fit in that category on computers, and my gut feeling is that the smaller the screen, the worse it gets. I want something: - fast. Don't wan't to wait 1 second everytime I open a menu in order to get it half transparent (and therefore less legible BTW). Maybe I don't want a menu-based UI at all, actually. - easily and deeply configurable: because even *I* can't tell what's the perfect UI for myself without a lot of experimenting. Empowering the users is not only about giving them the sources, it's also about making them as easy to change as possible, so the rapid prototyping abilities of the whole framework are extremely important. And actually, I might want it bad enough to implement it. I'd bet on some tiny, X11-less GUI for responsiveness, plus a layer of Lua bindings for the rapid prototyping aspects. Anyway, AFAIK the widgets implemented in the common, big open-source toolkits have been designed for big screen + mouse, so it's more important to easily write new widgets than having loads of unadapted, XVGA-oriented ones. Note that this approach is not incompatible with the heavier, GTK-based one: once an interesting user experience is found on a lightweight and easy to tweak UI, it can be transposed on the heavy one(s). On this topic: How detached is the underlying processes/functions and GUI from each other? How difficult will it be to just pull a different GUI layer on top of the phone functions? ie, have commercial Mokos with different frontends - one for my dad who wants to sync appointments with PC and make calls, thats it - and one for me with buttons on rotating cubes while watching a movie streamed via wifi :) (I havent had time to take a look at die software layers yet, I know GTK is in there, is X also in? that seems wasteful) E-Mail disclaimer: http://www.sunspace.co.za/emaildisclaimer.htm ___ 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?
I would say, considering the fact that the apps ecosystem hasn't flourished yet, is it really too late to switch? In the rest of this mail, please assume it is not. How detached is the underlying processes/functions and GUI from each other? How difficult will it be to just pull a different GUI layer on top of the phone functions? The openmoko team can choose among technos that separate the two layers. If you choose to develop (local) web applications for instance, then only the backend of the web rendering engine is the criteria. Switching from gdk to qt libs (which have had lots of embedded-oriented optimizations) will require only changing the rendering engine (webkit-gdk or webkit-qt), the backend isn't a concern. Yet, for traditional applications... If you choose to develop your applications using a general purpose scripting language (python/ruby/whatever), using GUI bindings that support multiple backends (such as [1] [2] ) could let time for the final decision... The clutter toolkit seems more and more interesting, because it supports: * GTK+ embedding * Language bindings for Perl and Python * Provides a fixed-point API [4] But it would also mean: * no apps before P2 model * no clutter-based openmoko devices on non-OpenGL-capable devices [1] http://wiki.python.org/moin/AnyGui [2] http://wiki.python.org/moin/Ocean [3] http://cairographics.org/backends/ [4]http://www.clutter-project.org/docs/clutter-clutter-fixed.html Any thoughts? Florent ___ 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?
On to, 2007-06-07 at 01:23 +0200, Michael 'Mickey' Lauer wrote: Tomasz Zielinski wrote: 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 would be a bit disappointed of the loss of flexibility and ease of portability, what with the reuse of desktop technologies and all. My concern would be alleviated by the fact that in the end one could run core apps and Mokoized apps directly on the frame buffer and still have an X server available for stuff that is not-so-thoroughly Mokoized (would have to have some extra integration wrt. window management...) All and all, I'd not be overly distressed, and it wouldn't really affect any buying decision or recommendation. I just have to wonder where the performance issues actually are; I'd _think_ that one should be able to manage a reasonably responsive GTK/X gui on it, given *cough* other similar devices... Plus, more work, more delays for switching from X over to Something Else. But I'm no expert on hardware of this grade and relevant software, so I'm just spewing intuition here. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ 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?
I think you should... fork. One group for GTK and other for something else. :) 2007/6/7, Florent THIERY [EMAIL PROTECTED]: I would say, considering the fact that the apps ecosystem hasn't flourished yet, is it really too late to switch? In the rest of this mail, please assume it is not. How detached is the underlying processes/functions and GUI from each other? How difficult will it be to just pull a different GUI layer on top of the phone functions? The openmoko team can choose among technos that separate the two layers. If you choose to develop (local) web applications for instance, then only the backend of the web rendering engine is the criteria. Switching from gdk to qt libs (which have had lots of embedded-oriented optimizations) will require only changing the rendering engine (webkit-gdk or webkit-qt), the backend isn't a concern. Yet, for traditional applications... If you choose to develop your applications using a general purpose scripting language (python/ruby/whatever), using GUI bindings that support multiple backends (such as [1] [2] ) could let time for the final decision... The clutter toolkit seems more and more interesting, because it supports: * GTK+ embedding * Language bindings for Perl and Python * Provides a fixed-point API [4] But it would also mean: * no apps before P2 model * no clutter-based openmoko devices on non-OpenGL-capable devices [1] http://wiki.python.org/moin/AnyGui [2] http://wiki.python.org/moin/Ocean [3] http://cairographics.org/backends/ [4]http://www.clutter-project.org/docs/clutter-clutter-fixed.html Any thoughts? Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Denis Kot denis?jabber.org.by ICQ: 13680126 Mobil: +375 29 6-1234-78 ___ 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?
You *could* do what many existing linux apps do... write the functional part of the app as a console program, and then use many simple GUIs as options to interface with it. Think about cdrecord and K3b as an example. For the handful of us out there that intend to use the Neo as a remote administration device, being able to boot the thing into a GUI-less console mode (using bluetooth HID for input) would be a killer app as far as I can see. I use a full blown GUI desktop for most of my day-to-day stuff (KDE), but when I really want to get a bunch of remote-admin or compiling done, I just boot into run level 3, since I'd be in a terminal window anyway. Why waste the CPU cycles, especially on such a constricted CPU. If someone really wanted to keep things lightweight, you could even do a curses based interface as an option. 31337 HaXoRs and their console based phones. ~Bradley Florent THIERY wrote: I would say, considering the fact that the apps ecosystem hasn't flourished yet, is it really too late to switch? In the rest of this mail, please assume it is not. How detached is the underlying processes/functions and GUI from each other? How difficult will it be to just pull a different GUI layer on top of the phone functions? The openmoko team can choose among technos that separate the two layers. If you choose to develop (local) web applications for instance, then only the backend of the web rendering engine is the criteria. Switching from gdk to qt libs (which have had lots of embedded-oriented optimizations) will require only changing the rendering engine (webkit-gdk or webkit-qt), the backend isn't a concern. Yet, for traditional applications... If you choose to develop your applications using a general purpose scripting language (python/ruby/whatever), using GUI bindings that support multiple backends (such as [1] [2] ) could let time for the final decision... The clutter toolkit seems more and more interesting, because it supports: * GTK+ embedding * Language bindings for Perl and Python * Provides a fixed-point API [4] But it would also mean: * no apps before P2 model * no clutter-based openmoko devices on non-OpenGL-capable devices [1] http://wiki.python.org/moin/AnyGui [2] http://wiki.python.org/moin/Ocean [3] http://cairographics.org/backends/ [4]http://www.clutter-project.org/docs/clutter-clutter-fixed.html Any thoughts? 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
RE: UI ideas/questions or can we animate things as smooth as iPhone?
On Thu, 2007-06-07 at 08:19 -0700, David Schlesinger wrote: If someone really wanted to keep things lightweight, you could even do a curses based interface as an option. 31337 HaXoRs and their console based phones. Keen. I bet you could sell _dozens_ of those. My dad will buy one E-Mail disclaimer: http://www.sunspace.co.za/emaildisclaimer.htm ___ 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?
to, 2007-06-07 kello 09:05 -0700, John Seghers kirjoitti: 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. Shouldn't be a requirement for framebuffer access. Presumably you could have another VC available, or even just be very naughty and map the framebuffer while X still has it as well. I'm not sure if these approaches would be workable as such right away, but shouldn't take much of a tweak to make it so. (Oh yeah, and there is the DGA2 extension, which I don't know if the server supports, and which is apparently hoped to die a good death.) Access to any acceleration features possibly in GTA-02 would be a whole different can of worms, then, and would probably require duplication of effort. Come to think of it, eg. the current OpenGL acceleration framework is X.org-integrated, would probably require some effort to hack OpenGL ME acceleration without it. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ 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?
On Thu, 2007-06-07 at 01:23 +0200, Michael 'Mickey' Lauer wrote: ... GameBoy provided nice full-screen animations in 1989, eighteen years ago. This is nothing like the GameBoy, or the C64, or the Amiga. The GB was a single-tasking system that would always only be doing one thing at a time. The C64 was as well. The Amiga had no memory protection so one errant program could bring down the whole OS. No one would go for that now. A Neo or any OpenMoKo phone will have to coordinate a lot of programs and several windows at a time; programs that may have come from repos that aren't as tight on the QA as others, so the OS (and the windowing system) has to be able to protect itself. 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. And you'd be 100% wrong in at least a few occasions. X11 applications aren't just for running desktop apps on the Moko. They can also be for running Moko apps on the desktop. I mean, personally, if I'm home and I want to look up a phone number while I'm sitting at my computer, I don't necessarily want to drag the phone out of my pocket, unlock the screen, then bring up the contacts screen and search for my target when I can just: ssh -CY mymoko mymoko contacts And it comes up on my 22 LCD, where I can cut and paste from an e-mail or whatever and have it instantly on my phone. No file copying or data replication required. Yes, I know I could just sync that stuff across, but for anything that doesn't have syncing built in, it would be really nice for me to be able to just bring up the app and interact with it without dragging the phone out of my pocket or my coat in another room. There were so many times my Zaurus was on the charger, with the CF Wifi card in it and I would have loved to bring up one of the Z apps but couldn't. Now, I realize I'm in the minority of this minority, but I run X11 apps across the network ALL THE TIME. I even installed X11 on my Mac so I could do it there too. As for porting, there are lots of programs I would like to see on the Moko and most of them are GTK-based already (For one, I'd like to see Gobby on a Moko for collaborative note taking during meetings). It would also be interesting to be able to run apps from one MoKo and control them on another MoKo across a Bluetooth or Wifi network (With appropriate security precautions, of course). Interesting. Can I hear more supportive or counter arguments? What do the others think? First, I get a sad little chill when people think that dropping X11 will solve all their speed problems, with absolutely no knowledge of X11's origins and progress over the last several decades. Yeah it's another layer of indirection, but over the years X.org (formerly XFree86) has implemented various methods for speeding up the rendering path that require no changes in the application code. DRI is one of them, MIT-SHM is another. It's gotten to the point where running a pure-X11 application is waiting on me, not the other way around. And this is on old hardware (Pentium 3 450) across the Internet. Dropping X11 means that we need to find something to replace it, and that something (DirectFB or whatever) will need to implement enough functionality that we're not stuck when some buggy app goes out and locks up the GUI because it's holding a token (or equivalent) and everything else is deadlocked (Which I saw entirely too often on my Zaurus). In addition, this lightweight replacement needs to be faster as well as at least as robust and documented. What I'm curious about is if the GUI has received any love or even attention at this point. The Core Team has repeatedly stated that they're working at the lower levels of the OS (Kernel, modules, drivers, daemons, etc), which makes me think the GUI stack hasn't been run through any profiling or debugging. Hell, it could still have all debugging symbols turned on, which won't be the case in the finished product. Also, the fact that the GTA_01 doesn't have any graphical acceleration will also make the GUI run slowly compared to what people are used to. Even the most bargain basement PC has a 2D accelerator in it. In fact, I haven't seen any that don't have a 3D accelerator in them anymore. For a PDA with a 320x240 screen, pushing pixels is 1/4 as hard as on a real VGA screen. Yeah, we pay a price for the glorious screen on the Neo, but from what we've all been hearing about the GTA_02, that will hopefully not be a problem. Yeah, I like X11 and I like GTK. I like their functionality, their maturity, and their licenses. -KW ___ 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?
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 snip 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. They are utterly irrelevant, after the thing hits the mass market stage. The question is - when will it hit mass market. (I am not a FIC representative) FICs whole strategy for this device is a low-cost route to selling phones to users. They employ a few dozen people on the project, and in return get an OS they can use to sell hardware to people. The whole idea is that they are going to be relying on the 'geeks' to code large portions of the OS that will be deployed in the final version. At this stage in the project, making it interesting, easy, and fun to code is almost the priority over polishing it as much as possible before it goes out. You want as few barriers to a moderately skilled coder who knows how to do X applications - for example - getting their 'hello world' program up and running on the device. Performance can be fixed later, and glitter added. Yes, the Neo has a relatively underpowered CPU at the moment, compared to desktops. But P1 is unimportant to end users. Going from 266-400Mhz will provide a significant boost before P2 launches to the public - some of that revenue can then hopefully be put into streamlining and adding glitter. ___ 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?
to, 2007-06-07 kello 12:19 -0600, Knight Walker kirjoitti: And you'd be 100% wrong in at least a few occasions. X11 applications aren't just for running desktop apps on the Moko. They can also be for running Moko apps on the desktop. Well put there, hadn't even considered that. I'm not quite the heavy user of remote X as you appear to be, but it does often have value. I can immediately see it here now that you pointed it out. First, I get a sad little chill when people think that dropping X11 will solve all their speed problems, with absolutely no knowledge of X11's origins and progress over the last several decades. Indeed eliminating X is often quoted as a silver bullet for getting speed without really justifying it much at all. Also good points about it seeming unlikely that the core GUI stuff is really profiled much, and having a reliable, widely used and documented graphics platform etc. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ 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 to.
RE: UI ideas/questions or can we animate things as smooth as iPhone?
Daniel sent his response directly instead of to the list by accident. I confirmed that with him so I'm leaving his entire reply and adding my points at the end... -Original Message- From: Silva, Daniel [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 10:40 AM To: John Seghers 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
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
Re: UI ideas/questions or can we animate things as smooth as iPhone?
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
UI ideas/questions or can we animate things as smooth as iPhone?
2007/6/6, Fabien [EMAIL PROTECTED]: And I think openmoko can lead to real improvements in this domain, if: [...] - some people with the right social skills make the UI improvement effort run smoothly. iPhone is fascinating because it's GUI is so responsive and so smooth. Unfortunately, current OpenMoko GUI running on GTA01 is exactly opposite - every icon tap causes lag, busy indicator isn't too reliable and user experience is hit by overall slowness. As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Question to FIC Team an/or other embedded developers: is it possible to speed up OpenMoko GUI responsiveness by a factor of 10 or the guilty is too-multi-tiered architecture of Xorg/GTK/Matchbox set? If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. 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. If OpenMoko will be judged as poor's man iPhone look and feel, it won't be attractive ever. To attract public attention we need at least one demo application which can animate elegant GUI with colorful widgets (e.g. album covers) as nice and smooth as we saw at iPhone commercials. If it cannot be done, it will be hard to advertise Neo, because youtube screencasts is today primary way people become acquainted with new device's user interfaces. -- Tomek Z. [EMAIL PROTECTED] ___ 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?
Hello, I am not sure if it is a graphical framework problem after seeing how smooth Canola[1] is in a Nokia 770 device: http://www.youtube.com/watch?v=nV-HtJcIW-I best regards, [1] http://openbossa.indt.org.br/canola/ 2007/6/6, Tomasz Zielinski [EMAIL PROTECTED]: 2007/6/6, Fabien [EMAIL PROTECTED]: And I think openmoko can lead to real improvements in this domain, if: [...] - some people with the right social skills make the UI improvement effort run smoothly. iPhone is fascinating because it's GUI is so responsive and so smooth. Unfortunately, current OpenMoko GUI running on GTA01 is exactly opposite - every icon tap causes lag, busy indicator isn't too reliable and user experience is hit by overall slowness. As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Question to FIC Team an/or other embedded developers: is it possible to speed up OpenMoko GUI responsiveness by a factor of 10 or the guilty is too-multi-tiered architecture of Xorg/GTK/Matchbox set? If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. 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. If OpenMoko will be judged as poor's man iPhone look and feel, it won't be attractive ever. To attract public attention we need at least one demo application which can animate elegant GUI with colorful widgets (e.g. album covers) as nice and smooth as we saw at iPhone commercials. If it cannot be done, it will be hard to advertise Neo, because youtube screencasts is today primary way people become acquainted with new device's user interfaces. -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- J. Manrique López de la Fuente http://www.jsmanrique.net msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ 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?
Hi, An alternative could be DirectFB, it was designed specifically for embedded systems, there is no overhead with any protocol or other things. GDK has a DirectFB backend, so there is no problem running GTK+ apps over it. It isn't easy to say how much the perfomance could improve, but it could be a real alternative. Regards, -- Pedro Aguilar 2007/6/6, Fabien [EMAIL PROTECTED]: And I think openmoko can lead to real improvements in this domain, if: [...] - some people with the right social skills make the UI improvement effort run smoothly. iPhone is fascinating because it's GUI is so responsive and so smooth. Unfortunately, current OpenMoko GUI running on GTA01 is exactly opposite - every icon tap causes lag, busy indicator isn't too reliable and user experience is hit by overall slowness. As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Question to FIC Team an/or other embedded developers: is it possible to speed up OpenMoko GUI responsiveness by a factor of 10 or the guilty is too-multi-tiered architecture of Xorg/GTK/Matchbox set? If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. 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. If OpenMoko will be judged as poor's man iPhone look and feel, it won't be attractive ever. To attract public attention we need at least one demo application which can animate elegant GUI with colorful widgets (e.g. album covers) as nice and smooth as we saw at iPhone commercials. If it cannot be done, it will be hard to advertise Neo, because youtube screencasts is today primary way people become acquainted with new device's user interfaces. -- Tomek Z. [EMAIL PROTECTED] ___ 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: UI ideas/questions or can we animate things as smooth as iPhone?
On ke, 2007-06-06 at 14:52 +0200, Tomasz Zielinski wrote: As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Incidentally, have people with the hardware tried to run it with select essential programs and libraries loaded onto a tmpfs at bootup, where they'd AFAIK be executed in-place? Don't know, but seems that it might be a feasible way to speed app-launching and switching for select core stuff, bypassing jffs2 overhead. Of course, that would reserve some otherwise reclaimable RAM and if the kernel and jffs2 are smart about caching in these kinds of circumstances, may not make much of a difference. Just an idle thought. If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK Yes it is, by the way. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ 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?
As I understand it the new GTK mobile initiative will really be focusing on performance on mobiles. I don't think the software is there yet, or the all of the hard ware. Personally I'm not too concerned with the speed of the GUI... yet. That and it sounds like the next hardware revision will be using a GPU to render the gui. On 6/6/07, Tomasz Zielinski [EMAIL PROTECTED] wrote: 2007/6/6, Fabien [EMAIL PROTECTED]: And I think openmoko can lead to real improvements in this domain, if: [...] - some people with the right social skills make the UI improvement effort run smoothly. iPhone is fascinating because it's GUI is so responsive and so smooth. Unfortunately, current OpenMoko GUI running on GTA01 is exactly opposite - every icon tap causes lag, busy indicator isn't too reliable and user experience is hit by overall slowness. As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Question to FIC Team an/or other embedded developers: is it possible to speed up OpenMoko GUI responsiveness by a factor of 10 or the guilty is too-multi-tiered architecture of Xorg/GTK/Matchbox set? If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK and choose other framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. 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. If OpenMoko will be judged as poor's man iPhone look and feel, it won't be attractive ever. To attract public attention we need at least one demo application which can animate elegant GUI with colorful widgets (e.g. album covers) as nice and smooth as we saw at iPhone commercials. If it cannot be done, it will be hard to advertise Neo, because youtube screencasts is today primary way people become acquainted with new device's user interfaces. -- Tomek Z. [EMAIL PROTECTED] ___ 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: UI ideas/questions or can we animate things as smooth as iPhone?
Interesting. Can I hear more supportive or counter arguments? What do the others think? Depends on the technical bottleneck, which i am in no position to determine. Is GDK inherently unsufficient too ? I am very curious about the potential of the webkit gdk qt ports, i hope to benchmark them whenever i get a device. Maybe a local web interface is doable and reactive enough for launching apps. Regards Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
