Re: [shr-unstable] packages for canola media player
On Mon, Jun 15, 2009 at 10:15 AM, Michael Zanetti wrote: > On Monday 15 June 2009 15:04:59 Gustavo Sverzut Barbieri wrote: > >> yes, it was done for 800x480 (Maemo N800/N810), but as I said if we >> find out a designer to do the graphics I can try to allocate one of my >> resources to do the OpenMoko work. > > I'm just wondering... What would like to redesign? IMHO it would be enough to > scale down the current track information and the position slider a little bit. > The menus etc are looking nice in landscape mode and I don't see any reason > why not use canola in landscape mode as it is a full-screen application > anyways. You can make a custom look & feel that follows SHR's, and also improve sizes to be better with FR form factor (bigger icons, specially for side actions like play/pause/next/previous). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] packages for canola media player
On Sun, Jun 14, 2009 at 3:17 PM, Yorick Moko wrote: > It looks really nice > it does take a while (understatement) to load yes, that's on our long todo list to optimize. The problem is that we changed the way main screen works and instead of loading 3-4 simple plugins as we did before, we're not loading more and heavier plugins. Probably we'll revert the main screen to contain category->apps instead of presenting apps directly. > it isn't optimised for normal screen orientation, but it works and landscape > is quite nice > overall: I like it :) yes, it was done for 800x480 (Maemo N800/N810), but as I said if we find out a designer to do the graphics I can try to allocate one of my resources to do the OpenMoko work. Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] packages for canola media player
On Sat, Jun 13, 2009 at 5:01 PM, Hermann Lacheiner wrote: > Hi Gustavo, > > thanks for your support! Without your prior help I wouldn't have been > able to package canola ;) You're welcome! > 2009/6/12 Gustavo Sverzut Barbieri : >> On Thu, Jun 11, 2009 at 9:02 AM, Hermann >> Lacheiner wrote: >>> Currently there are a few glitches: >>> * canola package depends on glibc-gconv-iso8859-15 otherwise >>> lightmediascanner does not work >> >> You can just disable ISO8859-1 conversion for unknown original media >> format (ie: ID3v1 or other formats that do not specify an encoding in >> the tag or standard). You can change it using cnl-prefs-set or >> terra-prefs-set -c /etc/canola.conf, or patch >> canolad/src/canolad/prefs.py to not include that. For per-user >> changes: >> >> cnl-set-prefs canolad charsets '[]' >> >> will replace the old list that contains ISO-8859-1 with nothing and no >> fallback will be used. > > I have tried it and it works, but there is one problem: It would be > nice to set the charset automatically after package was installed in > postinst, but canola creates the user settings not until first start, > so the settings set in postinst are going to be overwritten. > > So is there actually a way to automatically set the charset in > postinst when there are no user settings at that moment? This should be an external file with "default data", but since it's not (at least yet) you'll have to patch that src/canolad/prefs.py file. No big deal, it should not change often, if it do probably will be to include a "defaults" file. That is: patch that file :-) >> If we do a simple theme optimization it can be bit faster. I'm doing >> this for a ProFUSION demo we're about to release videos, but we cannot >> release the images or the theme itself. If there are manpower >> interested in creating so, let me know... I can even help with code >> (.edc), just don't have the time/skills to produce neat graphics. >> Also, it would be amazing to have a canola themed to match SHR. >> >> Again, this is of my interest and I can allocate my time or an >> employee to help with such task to optimize, but we need a designer to >> produce the images. > > It would be really great if you could adapt the UI to fit the > resolution of FR and optimize it in speed. I think canola is a really > great application and has a cool plug-in architecture with a huge > potential. But do you know someone to do the graphics? Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] packages for canola media player
On Thu, Jun 11, 2009 at 9:02 AM, Hermann Lacheiner wrote: > Hi! > > I have created packages for the canola media player (see > http://openbossa.indt.org/canola/ for screenshots). canola was > originally developed for the maemo platform and was open sourced > recently. It is based on the e17 libraries, so it is destined for the > shr distribution ;) > > Sources for the packages are from http://local.profusion.mobi:8081/ > based on the branches from Gustavo. > > canola has some dependencies so I created a testing feed. You can find > the packages at http://schagaga.de/canolafeed/ > The bitbake recipes are mirrored at http://schagaga.de/myoverlay/ > > "opkg install canola" installs canola and all its dependencies on the FR. Excellent, thanks for your work! :-) HUGE FAT NOTE: while Canola2 is a media application, it's built on the excellent Python-Terra, this is what makes Canola possible, you can even augment Canola with plugins like Remember The Milk (RTM, Todo), Picasa or Pidgin as our GSoC students are doing, or create whole new applications as Carman (http://openbossa.indt.org/carman/). You can use it to create launchers, dialers and all. And it is fast and easy to use! (Canola take a while because it imports tons of plugins and checks DB and wakes some worker daemons...) > Currently there are a few glitches: > * canola package depends on glibc-gconv-iso8859-15 otherwise > lightmediascanner does not work You can just disable ISO8859-1 conversion for unknown original media format (ie: ID3v1 or other formats that do not specify an encoding in the tag or standard). You can change it using cnl-prefs-set or terra-prefs-set -c /etc/canola.conf, or patch canolad/src/canolad/prefs.py to not include that. For per-user changes: cnl-set-prefs canolad charsets '[]' will replace the old list that contains ISO-8859-1 with nothing and no fallback will be used. > * player UI does not fit exactly the lower resolution on the FR > (canola is optimised for the resolution on the Nokia N8x0 800x480) but > it's usable. User experience is better when rotating screen in > landscape mode. EcoreEvas can rotate the screen itself, so if you wish I can add an option to start canola rotated. Maybe it's slower than Xrandr rotation, maybe it's not, worth to try: ee.rotation = 90 right before ee.show() > As backend mplayer is used for playback. > > Generally the UI is a little bit sluggish on the FR than on the Nokia > N8x0 but I think it's really usable. If we do a simple theme optimization it can be bit faster. I'm doing this for a ProFUSION demo we're about to release videos, but we cannot release the images or the theme itself. If there are manpower interested in creating so, let me know... I can even help with code (.edc), just don't have the time/skills to produce neat graphics. Also, it would be amazing to have a canola themed to match SHR. Again, this is of my interest and I can allocate my time or an employee to help with such task to optimize, but we need a designer to produce the images. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, Feb 23, 2008 at 10:43 PM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > Gustavo Sverzut Barbieri ha scritto: > > > On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" > > <[EMAIL PROTECTED]> wrote: > >> I'm really excited waiting for the Freerunner to be available to the > >> public, so I'm looking around searching the resources I'll need more. > >> > >> I think that one of the most important thing when it comes to the daily > >> phone use, is the virtual input device that imho it should be completely > >> usable with *fingers* (the stilus isn't portable!) giving the users the > >> same confort that the key-based devices give. > >> > >> To get the best usability and speed while writing I do think that is > >> needed a QWERTY style keyboard (If you've ever tried a blackberry you'd > >> know what I mean). > >> Actually there are two alternatives: the QTopia predictive keyboard [1] > >> that works quite well if used with a good dictionary (also if it should > >> be improved for writing new words), and the iphone-like virtual keyboard > >> [2] that is already available for N800 and that should be easily > >> portable to Openmoko too. > >> > >> Any other? If there are some others I don't know them, but the solutions > >> I've tried using the Openmoko GUI with qemu aren't so good imho. > >> I think that some virtual qwerty keyboards should be developed also > >> considering that Openmoko supports the landscape view (not using > >> accelerometers yet, but it does it!) and that mode could/should be used > >> for writing, so we could use more space to put keys in! > > > > Hi Marco, > > Hi Gustavo! > > > > I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using > > iPhone for about 2 months and I wrote the one you cited, so I think I > > have some knowledge about it :-) > > > > Reasons: > > - iPhone vkbd is not so great, even on iPhone hardware. The > > landscape version is almost usable, but the vertical is bad - but > > acceptable, see below. > > Well, I've tried the iPhone virtual keybard (not only on the iPhone but > also in the iPod touch, that it's the same) and it's not so bad imho... > Of course the vertical view is really better than the landscape one but > considering how I use the T9 based phones, I'm really a much faster I guess you mean the other way around, using keyboard in landscape mode (like iPhone browser) > writer using this kind of keyboard, also if sometimes I do mistakes. > That's why I think that the pressure should be compared char-by-char > with a dictionary! > > > - iPhone has no sunken screen, with borders that make you loose many > > physical space. This happens on Maemo devices as N800 and it's painful > > in Canola and that vkbd mockup I wrote. I do not have a OpenMoko > > hardware yet, but I suspect it will be even worse, as the screen is > > more high dpi and smaller in physical size. > > Yes, that's could be true, but in landscape view I think it could be > usable in Freerunner too... I dare to say it's not even without trying. Our experience with Canola is that you waste more than 30px in each edge due the border, in OpenMoko it should be even more. Given that each click area must be around 100x100 to have good hit rate, then you guess you'd not have much space to fit around 10 keys on 1 row. > > - iPhone has a capacitive (not pressure based), VERY sensitive touch > screen. > > - Running my prototype on N800 was not so bad because the screen is > > huge and you have plenty of space, but you often miss some clicks due > > the pressure based touch screen. > > I don't know how it is in Freerunner, but there's no software control on it? it's a physical limitation: the screen need pressure to emit hardware signals, while the capacitive just needs contact, you barely need to touch in order to produce hardware signals. > > That's why I think it's not a good option. We better keep with some > > kind variation of T9. I already talked to rasterman about that and he > > have a great idea of a key matrix (3x3 or 4x3) that would behave like > > number keypad, but the labels would weight the key with greatest > > probability of being used (based on dicts, T9 like). > > As I've said, I don't love T9 neither 9x9 keyboards as they're commonly > meant (the ones used for
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > I'm really excited waiting for the Freerunner to be available to the > public, so I'm looking around searching the resources I'll need more. > > I think that one of the most important thing when it comes to the daily > phone use, is the virtual input device that imho it should be completely > usable with *fingers* (the stilus isn't portable!) giving the users the > same confort that the key-based devices give. > > To get the best usability and speed while writing I do think that is > needed a QWERTY style keyboard (If you've ever tried a blackberry you'd > know what I mean). > Actually there are two alternatives: the QTopia predictive keyboard [1] > that works quite well if used with a good dictionary (also if it should > be improved for writing new words), and the iphone-like virtual keyboard > [2] that is already available for N800 and that should be easily > portable to Openmoko too. > > Any other? If there are some others I don't know them, but the solutions > I've tried using the Openmoko GUI with qemu aren't so good imho. > I think that some virtual qwerty keyboards should be developed also > considering that Openmoko supports the landscape view (not using > accelerometers yet, but it does it!) and that mode could/should be used > for writing, so we could use more space to put keys in! Hi Marco, I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using iPhone for about 2 months and I wrote the one you cited, so I think I have some knowledge about it :-) Reasons: - iPhone vkbd is not so great, even on iPhone hardware. The landscape version is almost usable, but the vertical is bad - but acceptable, see below. - iPhone has no sunken screen, with borders that make you loose many physical space. This happens on Maemo devices as N800 and it's painful in Canola and that vkbd mockup I wrote. I do not have a OpenMoko hardware yet, but I suspect it will be even worse, as the screen is more high dpi and smaller in physical size. - iPhone has a capacitive (not pressure based), VERY sensitive touch screen. - Running my prototype on N800 was not so bad because the screen is huge and you have plenty of space, but you often miss some clicks due the pressure based touch screen. That's why I think it's not a good option. We better keep with some kind variation of T9. I already talked to rasterman about that and he have a great idea of a key matrix (3x3 or 4x3) that would behave like number keypad, but the labels would weight the key with greatest probability of being used (based on dicts, T9 like). The major problem with T9 is it takes time to train and have it behave fine for you. One option would be to provide a service (pc, web or on the device itself) to feed with personal texts (mails, docs, ... text you wrote) so it will optimize for it. Other improvements could be abbreviations and maybe mode selection to use even more optimized dicts (language based and terms based, like "polite", "3733t speech", "development"...). What we need to do is implement something fast, with good feedback and users will get used... people already got used to write "graffiti", T9, ... and even QWERTY... they will learn yet another, just make the behavior predictable and help the user whenever possible. -- Gustavo Sverzut Barbieri http://profusion.mobi - Embedded and Mobile Software Development -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [UI/Graphics] Ever heard of graff ?
On 8/1/07, Florent THIERY <[EMAIL PROTECTED]> wrote: > > BTW, evas have a cairo backend, so you can mix both if required. > > Does it mean you can render evas in clutter then (i'm not thinking > running clutter on the neo, it's a general purpose question)? If cairo can render to clutter, yes, but it would be pointless as Evas already have OpenGL backend with its primitives mapped directly. But you could render to it and user clutter itself to move the rendered UI (like render to one window and move it 3d space, evas is just 2d, remember that). > > Other > > backends, like xrender, opengl, fb and directfb are supported as well. > > Regarding opengl, is the backend opengl es compliant, or does it rely > on opengl features that don't count in the opengl es subset ? I never checked it, but i fear its not, however primitives are simple enough to translate to /ES standard. -- 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/Graphics] Ever heard of graff ?
On 7/31/07, Jay Vaughan <[EMAIL PROTECTED]> wrote: > > it's not about the conversion itself, but the data. > > > > libcairo + librsvg == data galore. sure, evas can use svg import too, but it just rasterize once at load time. > > As for counting cairo out, sure not. But use it for specific scope. > > > > Indeed, its a standard in my GUI toolkit at this point .. soon as I > get a neo in my hands, I'll have a go at getting it rendering a small > SVG suite as soon as I can .. don't expect too much. > >However, even UIs being scalable, they're basically described by > > pixmaps. It's insane to calculate a gradient on real time just to get > > a smooth blend: using a gradient pixmap and maybe using (even smooth) > > scaling would look as good, but use less CPU. Same for rounded > > corners, you can have a path to describe it, but a smart blit > > algorithm would be as fast. > > > > Its nicer to render vectors to your destination buffer/pix format > than do pixel processing from a bitmap file format, imho. define "nicer". Is that better graphics? Faster? > The extra > boot-up time (to render SVG as needed) is a matter of taste, of > course, but I never count out the idea of a display-list render loop > until I've tried running it on targetted hardware .. most libs/apps render SVG to bitmaps and then use it, having to keep the cache to save render time. In other words: it won't change that much during runtime, but will add boot up as you said, but I disagree it's a matter of taste. > > BTW, evas have a cairo backend, so you can mix both if required. Other > > backends, like xrender, opengl, fb and directfb are supported as well. > > Be nice to do the SDL dance too, because there are some fantastic SDL > apps in the world .. SDL is also supported as a backend, but I really see not much point there, as SDL is a great abstraction layer atop of framebuffers (x, fb, directfb, gdi, ...), not that fast since Evas already do that (one step less). -- 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/Graphics] Ever heard of graff ?
On 7/30/07, Jay Vaughan <[EMAIL PROTECTED]> wrote: > >> > > Cairo, as suggested, will not be an option in near future, since it > > does 32bpp graphics and the conversion will kill our hardware. > > > > > fwiw, its quite feasible to do nice assembly-based BPP conversion on > ARM and involves a decidedly negligible hit on performance .. don't > count cairo out of the libpack just yet .. it's not about the conversion itself, but the data. 16bpp versus 32bpp: - opaque images: 2 bytes versus 3 bytes (alignment!) - alpha images: 3 bytes (alpha in separate plane) versus 4 bytes - rgb * a: 1 arithmetic operation versus 3. This is due the fact that you can downscale a to 5 bits and then operate rgb (16bits) on a 32bit word, just move 6 bits of G from the pack to the other half-word and then you can fit the overflow. Also, in order to look barely good you need to apply dither mask to images, otherwise you get weird gradients, they become blocky. With 32bpp->16 you need to convert always, while with 16bpp you do at load time. For sure quality is not as good, since you lost many bits, but it's the price of performance... you can try to improve things (like this dither thing), but not much room is left. As for counting cairo out, sure not. But use it for specific scope. EFL does no vector graphics (just line, rectangle and polygon, I'd not count it as vector graphics lib) and if you have to draw charts, complex paths, etc... it's the best option. However, even UIs being scalable, they're basically described by pixmaps. It's insane to calculate a gradient on real time just to get a smooth blend: using a gradient pixmap and maybe using (even smooth) scaling would look as good, but use less CPU. Same for rounded corners, you can have a path to describe it, but a smart blit algorithm would be as fast. BTW, evas have a cairo backend, so you can mix both if required. Other backends, like xrender, opengl, fb and directfb are supported as well. -- 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/Graphics] Ever heard of graff ?
On 7/27/07, Florent THIERY <[EMAIL PROTECTED]> wrote:
> I never heard about it, but it looks interesting (following the
> physics-inspired/verlet integration ramble some months ago on this
> very list)
> http://www.mdk.org.pl/articles/2007/04/23/chapter-1-in-which-we-meet-graff
>
> Be sure to check out this one (scrolling list with inertia scrolling)
> http://files.mdk.am/demos/graff-demo-3.avi
>
> No mention of OpenGL ES, but software rendering seems to be sufficient
> on Nokia 770/800. Let's wait for more news of graff (any additional
> data would be appreciated), and code. But it looks definetly promising
> !
>
> A python app, tracker backend, using graff (clutter/evas) as frontend,
> with gtk offscreen rendering and builtin mutimedia support (gstreamer
> or whatever lighter) ... Makes you want to have a GTA02 already :)
>
> Speaking of which
> * jnpatel's arena will be a clutter tracker frontend with direct
> webservices integration (ex: flickr).
> http://njpatel.blogspot.com/2007/03/im-not-even-supposed-to-be-here-today.html
> * some nice clutter toys news:
> http://njpatel.blogspot.com/2007/07/clutter-foo.html
>
> Any benchmarking news ?
Sorry being late to reply, but I was out for few days.
I've not seen any code for Graff and that demo for sure don't run on
N800, but flash, we do some prototype here using it too.
Cairo, as suggested, will not be an option in near future, since it
does 32bpp graphics and the conversion will kill our hardware.
I'm working on Evas for embedded systems and have it working for
Maemo/Nokia N800 using software_16 (which I wrote with help of
rasterman), python bindings and even some examples (with source
available):
http://blog.gustavobarbieri.com.br/2007/07/24/iphone-like-virtual-keyboard-for-n800/
you may also search for EFL on my blog history and see expedite
(benchmark) demo running.
all the code ({evas,ecore_evas,etk,ewl}/software_16, python-efl,
demos) is being done in e17 CVS, so code is already integrated and is
available under BSD license for those who care.
I work for INdT, thus our focus is Maemo/Nokia products. We have at
least 3 guys working with EFL, fixing bugs and writing tests and
prototype for our next version of Canola. But I know of Koen, Mickey
and Rasterman working with openmoko hw and they may report status on
this hardware (which I still don't have).
--
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
please test Evas 16bpp on OpenMoko
Hi, I've finished the basics of software_16 (and software_16_x11) engine for Evas! It's working well on Nokia N800, so I'd like to get feedback of it running on OpenMoko hardware, which I don't have so far. You can base your compile (./configure options and others) on my scripts at: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/scripts/?root=maemo-efl Don't forget to configure evas and ecore to use this engine! Expedite (e17/apps/expedite), Python-EFL (e17/proto/python-efl) and ETK[1] (e17/libs/etk) all work with this engine. Report your results by of expedite with x11 versus x11-16. [1] patch already submitted to enlightenment-devel mail list, maybe it take some time to get applied. -- 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?
On 6/8/07, Silva, Daniel <[EMAIL PROTECTED]> 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. If you mean developer with real knowledge of the platform, even GTK doesn't have much, and those that do know will easily change back and forth ETK, for example, since API and design is similar, ETK can even load Glade files using Enhance. BUT, unlike GTK, you can just mix form-oriented ETK parts inside your beauty custom UI, just check etk_test or ewl_test and embedded components. You can have something like "canola" (http://openbossa.indt.org/canola/) and then the password form could fade in or slide from some component (thats why we, the canola team, are working on EFL). To do that with GTK, you'd need to mess with ARGB windows, Composite extension and window manager. MUCH more work for something that may not even look as cool as what you get with EFL :-( 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. I wrote python bindings for Evas, Ecore, Edje and Emotion in about 1 week, it's not 100% but good enough. I plan to take on ETK as soon as I need it. ETK also have bindings in Perl. 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. Do you really know what Cairo, GTK or EFL are? Maybe some misunderstandings here. While Cairo is almost like Evas, in the sense it renders the scene, EFL also have Edje, a theme system and atop of these ETK a toolkit system (like GTK). So, you have Evas engine to use Cairo (not updated), that will enable you to use ETK on top of Cairo... but then, what's the point of using Cairo? Remember that vector operations are bit expensive on our devices and on bitmap images, Evas is really efficient and optimized. It would require some initial work to program all the widgets, but i believe in the long run it would pay off. I don't.. I just don't get what people have against Evas. I'm not a old-time Evas user/developer, but I like to know alternatives so I always check Qt, Gtk, Efl... and so far the best graphics engine is Qt4, followed by EFL and then GTK. With Qt being huge and people against its licensing schemes (which is GPL, so I really don't get this too), we're left with EFL and GTK, that can even work together and coexist... so why don't use EFL instead of inventing yet-another-lib? PS: so far, the major "problem" integrating EFL and GTK is that EFL uses Ecore as its main loop, while GTK use Glib, these main-loop use same concepts, but have different primitives, possible one can be implemented on top of the other, but by using a GUI thread is enough. -- 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?
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: Handsfree in/out for bluetooth and Linux
On 2/26/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: Hi Gustavo, > I'm trying to find how to get Linux interoperate with bluetooth > phones, both to connect to headsets (useful for openmoko) and > telephones connect to linux and use it as headset (maybe useful for > openmoko). > > The first case, connecting to headsets, can be done using btsco, not > that easy, not yet integrated into kernel/bluez tree. > > No ideas on how to proceed with the last case. > > Are you openmoko guys working with these cases? since the Neo1973 has the PCM of the Bluetooth chip directly wired to a codec, there is no need to do any actual SCO packet handling. It is the same as for the Nokia N800. The BlueZ CVS contains a headset code that targets only this specific case and in general it should be possible to use the same code for the Neo1973 and for the N800. http://garage.maemo.org/projects/selfone Ok, almost good... we just lack this code to choose SCO data routing... at least N800 doesn't send it to speakers, neither to my app... Someone with openmoko hw could test it? -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Handsfree in/out for bluetooth and Linux
On 2/24/07, Brad Midgley <[EMAIL PROTECTED]> wrote: Gustavo There is an asterisk plugin so you can use your computer with the phone to place and receive voice calls. I think this is too much, I don't want to setup asterisk for that. Something in the line of: - http://wall4.soft.uni-linz.ac.at/_wiki/tiki-index.php?page=ProjectBluezHandsfree - http://www.holtmann.org/linux/bluetooth/audio.html (Section 4 - Emulating a headphone) Would be more interesting. While the second link just mention that part of stack/profile is not implemented, the first say it should work, but it doesn't work, message is: connect: Connection refused Error: Can't connect SCO audio channel @ 00:12:62:F9:A9:3C I can receive call indication, accept, hang... but I cannot talk/listen from Linux. This become really interesting with mobile linux systems with microphone and speakers going mainstream, like zaurus, maemo/770/n800, OpenMoko... btsco won't ever be integrated into the kernel. There is not a good reason to do this stuff in kernel space. I meant the driver you mentioned below. We have a libalsa plugin (see "plugz") that doesn't require a kernel driver and represents some progress in the right direction. We may have to finish some of the goals in our list of future work in order to have something that works cleanly on openmoko... see http://wiki.bluez.org/wiki/Audio Yep, I know your effort in this area. I'll also attend your talk at Bossa Conference :-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Handsfree in/out for bluetooth and Linux
Guys, I'm trying to find how to get Linux interoperate with bluetooth phones, both to connect to headsets (useful for openmoko) and telephones connect to linux and use it as headset (maybe useful for openmoko). The first case, connecting to headsets, can be done using btsco, not that easy, not yet integrated into kernel/bluez tree. No ideas on how to proceed with the last case. Are you openmoko guys working with these cases? -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
X bit depth, Evas toolkit
Hi Guys, I'm from the Canola team (multimedia app for Maemo) and I'm interested in OpenMoko (that's my personal opinion, etc etc etc). I would like to confirm if HW/X11 is 16bpp. And I would like to invite you to join us to port/optimize Evas toolkit to operate on 16bpp internally (it does on 24bpp + 8 alpha). We're using SDL atm, but Evas has many advantages, like a great text layout system (like Pango), toolkit (like Gtk), scripting support and easy theme capabilities. Can you do it with GDK? Yes... if you want to do a lot of work. Do I want to replace GDK/GTK with it? No way! Just different scope. If you want to do something like Canola, then it's easier to use Evas. If you want to do PIM (and your underlying system is GTK), it's easier to do in GTK. Interested people can mail me or hang on #e @ freenode. We should develop it on enlightenment repo (if they give us commit access :-P). -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
