gui options for a1200 w/ mkezx

[rpconnect]

i thought i'd start this thread to discuss gui options for the a1200 that are:

a) alternative to the native ezx/qt libs (that are Mot. proprietary, meaning we don't need an SDK from Mot) and

b) part of the mkezx package that is open source, not dependant on the mot libs and provides a very well-organized clean method of building apps and packages for the phone

(yes, of course i'd love to have an SDK for the ezx/qt libs, but that is a separate issue...)

Gtk-based GUI:

Currently the only working gui materials for the a1200 w/in mkezx is the directfb stuff (bragon please correct me if i'm wrong) with support for cairo-directfb, pango-directfb and gtk-directfb. Based on the gtk-directfb libs w/in mkezx i have found that it is relatively easy to use glade on a linux desktop to generate an app, then build it in the mkezx environment so that it runs on the phone.

the only drawbacks to this option is that the touchscreen drivers for the directfb stuff seem a bit buggy (not all screen taps seem to be recognized) and there is no "built-in" pop-up keyboard as part of the standard gtk widgets so we will have to figure out a way to cleanly handle this so that all of us can work with it.


Standard Qt-embedded:

qt embedded (2.3.10) is included as part of mkezx, and i think it should work for the e680/i/a780 (although i haven't tried it yet), but it does not (currently) include support for the 18bpp that the a1200 requires. I am looking into this now to see how difficult it would be to patch 2.3.10 to for the 18bpp support.

if we can get the 18bpp support handled, then opie for the a1200 shouldn't be far behind.... (assuming anyone is interested of course)



Working with native EZX still running:

whatever alternative gui option we consider, if it is not based on the ezx stuff then we need to have a way for the alt-gui apps to not conflict w/ the native ezx apps (or more likely, vice-versa). i think this can be handled by starting a dummy ZApp with a blank full-screen widget that does nothing. this way screen taps are not inadvertantly passed though to the native EZX (e.g. app manager) as well as keeping native ezx screen updates (e.g. battery level or time updates) from unwantedly popping up.


@bragon
right now my "glade-test" consists of taking the .c source that is generated from glade, then copying into the package for gtk-directfb-test and renaming main.c to ui.c (with a couple of other mods); then i basically use mkezx to rebuild the gtk-test package with the modified source and extract the binary from the .deb package and re-name it (pretty hacky, i know, but until i get more familairy w/ mkezx it'll work for me...)

i would love to learn how to formally contribute to mkezx, not only this app but i also have gnuplot and vim working w/in a mkezx cramfs file that might be of interest. i think it would be interesting to develop a gtk "desktop" project under glad and mkezx such that we can configure glade to write directly into the package source that gets used by mkezx; then open it up so that others can easily modify this "helloworld" desktop for their own app.

right now though i have too many qt apps that i don't want to give up on so i'm spending my free time looking into the 18bpp support

@indianseason
i am away from my dev environment right now, but when i have a chance i'll tar up the a1200 blanking app, the glade_test app, etc and post in this thread. Do you know if your mkezx package has the gtk-directfb support? (search through /ezxlocal/mmc/lib for libgtk-directfb)

[rpconnect]

@indianseason
attached is my "glade-test" package containing the glade_test (gtk) app, the blanking app (running against the "native" ezx libs) and the source code both as it came from glade, and what was used to generate the app w/ mkezx.

Note: you must have mkezx installed w/ the gtk-directfb libs included to use this; for details, go here first: http://www.mkezx.org/ (if you haven't already)

To Use:
-------

copy the file .directfbrc to your home directory (/ezxlocal/home/.).

copy blank_a1200, blank_test.sh and glade_test to /mmc/mmca1

run the blanking test script first:

  /mmc/mmca1/blank_test.sh

then run the test app:

  /mmc/mmca1/glade_test

when you are done be sure to kill the blank_a1200 app so that the native ezx stuff resumes control. see the README file for more details. have fun

and of course a huge "thank you" to the developers of, and contributors to mkezx!!!

[blackhawk]

@rpconnect
How about GPE on A1200?

[rpconnect]

@blackhawk
oooo, i forgot about that one, thanks for the suggestion . i will try to post the suggestion to the mkezx mailing list; those folks are a lot better at this kind of thing than i...

update: it looks like GPE is dependant on X and i'm not sure how this will work w/ the directfb stuff, but if we plant the seed in the right place who knows....

[indianseason]

@rpconnect
I dont have the directfb stuff on my mkezx. I will do a build image full and then try your app. It might be a little difficult this week as work is keeping me very busy.
I too am very keen on working with Qt apps rather than Gtk (long time KDE user). But until the 18 bpp issue is resolved, I guess we can live with gtk!

[indianseason]

I found the following site by googling around:
http://www.holddreams.com/~kai/
In a blog article (http://www.holddreams.com/~kai/wordpress/?p=23), Kai mentions successfully patching qtembedded to 18bpp and got opie running under it. I could not find the patched sources on the download area though.
Perhaps this will help.

[rpconnect]

@indianseason
i found the exact same blog entry today and have sent an e-mail to see if any details can be shared - still waiting to hear back...

[swifty]

you can find files there:
http://www.holddreams.com/~kai/files/

[indianseason]

@swifty
I can see several files released in the directory you have indicated. But none of them seem to correspond to the QT/e patch for 18bpp. Did you mean any specific file?

[swifty]

no. i found that the donwload-link for the patch is incorrect. and then searched for an alternative. if this file in not there, the e-mail from rpconnect will help more.