Enlightement E17 on EZX?

[ethernode]

Just giving feedback from raster's mails:

Q: what did you port to ARM arch exactly? The efl libs in fact, right?
A: i didn't need to PORT anything - it was a straight recompile. the code is already fully portable. i simply re-compiled evas, edje, ecore and eet for ARM. thats it. then i compiled eem for ARM too.

Q:Is the program derived from E17 itself (the loading anim, the menu...)?
A: eem has nothnig to do with e17 beyond using the above libs.

Q: if i wanted to do an Opie with EFLs, it means i have to write frontends to all underlying programms, right? Do you think it is possible?
A: opie isn't really practical. only evas has a qtopia rendering back end. there is no abstraction for events or the windowing system in general.

Q: Would it then be possible to run an EFL-based programm (like eem) on top of Qt? (that would mean, as an OPIE programm)?
A: if you added ecore abstractions to qtopia - yes (qtopia/opie is the same thing really).

[intoxicated]

i just compiled eem with all the required libraries (eet, evas, ecore, embryo, edje)
gives me the error of cannot create canvas...


eem # ./eem -x11
Error. Cannot create canvas. Abort.

[ethernode]

What does the -x11 switch do? There's no X on EZX... I'm asking raster if there's a "-directfb" or something like that switch.

[intoxicated]

oh, yea there is the fb switch,
basicly i tried all the parameters, but none of them works

[ethernode]

what did cyph modify in it's custom OPIE libs?

http://motorolafans.com/index.php?na...ht=framebuffer

"All OPIE applications will open the framebuffer as usual. Since the opieproxy opens a fullscreen window, EZX applications will not paint on the framebuffer. However, when an EZX application grabs the focus (e.g. A call is coming in), opieproxy will lose focus and send a command to OPIE's modified QT to cease drawing on the screen.
Switching between EZX and OPIE is handled by another EZX program, opieproxycommand (opie/bin/opc). This uses a QCopChannel to talk to opieproxy to either go fullscreen or hide itself.
This package automatically mounts a cramfs image on the SD/MMC using loopback. It also sets up a 64MB swap file, because running EZX and OPIE together causes both to crawl (trust me)."

We've got to find how the fb is different...

[swifty]

Actually eem is only a demo - it's nothing more than that and it does not use Java or Qt. It's in C like the libraries it depends on. It uses: Ecore, Evas, Edje, Eet. That's it. The one on the ipaq you see is running in the frameubffer thus requires no windowing system - but if you used directfb or x on the platform that would work too. Eem also will run on your desktop in X in a window - all the same stuff s the back-end is abstracted.

The dependencies (in this minimal case) are only: libc/libm, zlib, libpng, libjpeg and freetype2. that's it. It's just a bunch of mechanical work to cross-compile any unmet dependencies for the platform (and install them) then EFL and then eem using whatever your favorite cross-compile setup may be (or even native compile).

It's perfectly doable - and the ipaq demo was just a proof that a small cpu can still do nice effects if the rendering code is efficient. The effort to port will not buy you any more than that demo as I have no plans (or time) on doing anything more with eem than it being a demo as-stands.

Congratulations on your new job!