On Fri, Mar 18, 2011 at 06:26:09PM +0800, Shuxiang Lim wrote: > Hi, > I have to say I cannot solve the glib bugs on Android 'cause it's too > arcane and too huge for me now. e.g such a statement will cause a segfault: > gobject/gtype.c : > return static_fundamental_type_nodes[utype >> > G_TYPE_FUNDAMENTAL_SHIFT]; > when utype==0; for why, I never know and can get no help.. > So I shall face the decision again, return to C++? No! STL and class > hierarchies etc. is even more horrible! I have only one choice: remove the > glib from the spice-gtk now. > Anybody can give some suggestions on this? > Good weekend.
Can I recreate this in qemu-arm? can you give instructions? Regarding converting to no glib, I don't know how hard it would be. > On Fri, Mar 18, 2011 at 5:15 PM, Alon Levy <[email protected]> wrote: > > > On Fri, Mar 18, 2011 at 02:09:38PM +0800, Shuxiang Lim wrote: > > > Ok,my prediction is right, this segfault is solved by disabling NLS (the > > use > > > of gettext(). etc..)in glib. > > > Yet then Bus Error comes: I know,it's mainly caused by the typecast for > > ARM > > > has no same alignment style as x86.The question is: is there a way to fix > > > this in the arm-gcc option other than rewrite the typecast statements > > into > > > memcpy()?(There are huge amount of such statements in glib.). The -O0 > > option > > > doesnot work. > > > Rgrds. > > > > This is strange, as I know glib is used by maemo, running on n900, which is > > an arm. > > > > No idea, sorry. > > > > > On Fri, Mar 18, 2011 at 11:52 AM, Shuxiang Lim <[email protected] > > >wrote: > > > > > > > Hi,all,caution of the radioactive rays! > > > > I feel rather frustrated though...Now I have ported libglib2.0 and > > its > > > > deps(libintl,libiconv...) onto android as well as libspicec-glib.so and > > > > snappy. > > > > But when run,the snappy got only SEGFAULT and killed. > > > > *#LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o > > > > ahoo.ppm* > > > > *[1] + Stopped (signal) LD_LIBRARY_PATH=/data/local/lib ./snappy > > -h > > > > 192.168.1.31 -p 5900 -o ahoo.ppm > > > > [1] Segmentation fault LD_LIBRARY_PATH=/data/local/lib ./snappy > > -h > > > > 192.168.1.31 -p 5900 -o ahoo.ppm* > > > > > > > > Tracing the process,I found the SEGFAULT came from the > > > > glib:g_object_new()!: > > > > gtk/spice-session.c: > > > > addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "hostname", s->host, > > "port", > > > > port, NULL); > > > > -->libgobject:gobject/gtype.c > > > > g_object_new()-->g_type_class_ref()-->type_class_init_Wm() > > > > -->libgio:gio/gnetworkaddress.c > > > > g_network_address_class_init()-->CRASSSSHHHH. > > > > > > > > Now I'm still tracing the bug... It may come from the i18n string ops, > > but > > > > if other bug occurs in glib,the future is dim... For I really has no > > time > > > > and energy to hack the arcane and exotic glib(or it's caused by the > > > > incorrect use of glib method in spicec?).(forgive such adjectives,to > > me,it's > > > > true) > > > > I really yearn for the spicec in PURE C and Modularized: > > > > 1.Offer the switch to disable (do not POSIX-likedly depend on) locale, > > > > libiconv, libintl, sys/shm.h, pwd.h, pthread,i18n, > > wchar_t,regex,gettext,... > > > > for none of them can be found in android! > > > > 2. Be as far away as we can from the other libs like the > > > > glib/gtk,pulseaudio/alsalib... > > > > 3. Completely modularize spicec into libspicec and spicec (this is > > what I > > > > am working for) > > > > as the data layer and the UI layer to ease the porting. > > > > > > > > Is there any plan about these now? Can anybody help to do the step 1 > > or > > > > step 2 above? > > > > Or, the simplest: the way to safely turn off locale and i18n in glib? > > > > Pardon my whining and wish me Goodluck! > > > > And again I shall desperately curse Android and bless Meego! > > > > Regards. > > > > > > > > > > > > On Thu, Mar 10, 2011 at 9:07 AM, Shuxiang Lim <[email protected] > > >wrote: > > > > > > > >> > > > >> That's true. But the audio output as well as the image output is > > unexposed > > > >> or disabled for C/C++ apps in Android.So I plan to dwindle the work to > > > >> implement the image first,if success, the audio work will be easy to > > follow. > > > >> > > > >> Regards. > > > >> > > > >> On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd < > > [email protected]>wrote: > > > >> > > > >>> Could you maybe give access to other devs to aid the development? > > > >>> > > > >>> Rgrds, > > > >>> > > > >>> Attila > > > >>> > > > >>> > > > >>> On Wed, Mar 9, 2011 at 11:18 AM, Shuxiang Lim <[email protected] > > >wrote: > > > >>> > > > >>>> Yep, I walked around this but to face more chored and nasty troubles > > in > > > >>>> porting Pulseaudio lib, time limited, so I decided to DISABLE the > > > >>>> audio(playback/record) channels first. Thus the porting of > > libspicec_glib.so > > > >>>> is finished(along with all its dependences) and > > androidVNCViewer(whose UI > > > >>>> will be peeled to become spicec's) proj. has been built: > > > >>>> *#file libspicec_glib.so * > > > >>>> libspicec_glib.so: ELF 32-bit LSB shared object, ARM, version 1 > > (SYSV), > > > >>>> dynamically linked, not stripped > > > >>>> *#arm-eabi-readelf -d libspicec_glib.so * > > > >>>> Dynamic section at offset 0x774a4 contains 27 entries: > > > >>>> Tag Type Name/Value > > > >>>> 0x00000001 (NEEDED) Shared library: [libc.so] > > > >>>> 0x00000001 (NEEDED) Shared library: [libm.so] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libpixman-1.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libssl.so.1.0.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libcrypto.so.1.0.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > [libjpeg.so.62] > > > >>>> 0x00000001 (NEEDED) Shared library: [libz.so] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libglib-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgio-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgobject-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgmodule-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgthread-2.0.so.0] > > > >>>> 0x00000010 (SYMBOLIC) 0x0 > > > >>>> .... > > > >>>> Now comes the last adventure of Native interfaces exposing and UI > > > >>>> building! > > > >>>> Regards. > > > >>>> > > > >>>> > > > >>>> On Wed, Mar 9, 2011 at 3:57 PM, Shuxiang Lim <[email protected] > > >wrote: > > > >>>> > > > >>>>> Well, I think I may try the "--with-coroutine=gthread" in spice-gtk > > > >>>>> configuring to walk around that... > > > >>>>> > > > >>>>> > > > >>>>> On Wed, Mar 9, 2011 at 11:10 AM, Shuxiang Lim < > > [email protected]>wrote: > > > >>>>> > > > >>>>>> Hi,I need help! > > > >>>>>> Now I've managed to divided spicec-gtk into two parts > > > >>>>>> libspicec.so(based on libpixman.so,libglib-2.0.so...No relation to > > X11 at > > > >>>>>> all) and spicec(based on libspicec.so and libgtk.so...). And the > > glib2.0 > > > >>>>>> porting to Android is also completed. But I'm blocked in compiling > > libspicec > > > >>>>>> onto Android at the begining for the continuation.c uses the > > functions in > > > >>>>>> <ucontext.h> :setcontext(),getcontext()..., which are some > > thread-related > > > >>>>>> funcs as I know,and, definitely unsuprisingly, Android libc > > doesn't have > > > >>>>>> them! Is there a way to drop or replace the use of such funcs? Or > > should I > > > >>>>>> manually write setcontext from scratch? > > > >>>>>> RGRDs. > > > >>>>>> > > > >>>>>> > > > >>>>>> On Mon, Mar 7, 2011 at 5:14 PM, Alon Levy <[email protected]> > > wrote: > > > >>>>>> > > > >>>>>>> On Mon, Mar 07, 2011 at 09:08:28AM +0800, Shuxiang Lim wrote: > > > >>>>>>> > Option 1: use spice-gtk with a gtk android backend > > > >>>>>>> > a) compiling gtk for it would be possible. > > > >>>>>>> > b) write a partial gtk backend, good enough for spice-gtk. > > > >>>>>>> > c) no changes to spice-gtk. > > > >>>>>>> > Yep,that's really a good hope,but it's another project(too > > huge > > > >>>>>>> and far > > > >>>>>>> > away for me now): > > > >>>>>>> > Project:"GTK for Android.". So now I can use only the Android > > SDK > > > >>>>>>> to finish > > > >>>>>>> > the UI(the new native UI APIs in NDK is not reliable in > > versions). > > > >>>>>>> > > > >>>>>>> Yeah, I think you're right, I can't find anyone already working > > on > > > >>>>>>> this by > > > >>>>>>> simple web search. Maybe spice-gtk's non ui objects are dependent > > > >>>>>>> only on > > > >>>>>>> gobject / stuff that is easy to just drop in (ugly, but still > > more > > > >>>>>>> maintainable > > > >>>>>>> then basing your work on spicec, long term). > > > >>>>>>> > > > >>>>>>> > And also you've referred that "spicec is already platform > > > >>>>>>> independent", > > > >>>>>>> > that's true to Linux and Windows,but not to Android,for such > > > >>>>>>> independence is > > > >>>>>>> > based on the C++ independence over the os which cannot stand > > > >>>>>>> through the > > > >>>>>>> > JAVA UIed android.So there is no way to just add a subdir > > ./android > > > >>>>>>> under > > > >>>>>>> > spice/client along with ./x11 and ./windows. It should be a > > > >>>>>>> combined proj. > > > >>>>>>> > of C/C++ and Java. (That's why I hate Android and yearn for > > > >>>>>>> Maemo/Meego.) > > > >>>>>>> > > > >>>>>>> Definitely easier to port to Maemo :) > > > >>>>>>> > > > >>>>>>> > Regards. > > > >>>>>>> > > > > >>>>>>> > On Fri, Mar 4, 2011 at 7:04 PM, Alon Levy <[email protected]> > > > >>>>>>> wrote: > > > >>>>>>> > > > > >>>>>>> > > On Fri, Mar 04, 2011 at 06:21:19PM +0800, Shuxiang Lim wrote: > > > >>>>>>> > > > Hi, friends, > > > >>>>>>> > > > Thanks for your replies. It's definitely right till now > > > >>>>>>> I've been > > > >>>>>>> > > > working a tougher way compared to spice-gtk.And actually > > I've > > > >>>>>>> considered > > > >>>>>>> > > to > > > >>>>>>> > > > steer my way to the latter in fear of the troublesome and > > > >>>>>>> crippled C++ > > > >>>>>>> > > > support in Android NDK:C is more "simple and safe" in > > Android > > > >>>>>>> than C++. > > > >>>>>>> > > > But,AFAIK,there is no gtk port for Android yet. And the > > biggest > > > >>>>>>> obstacle > > > >>>>>>> > > is > > > >>>>>>> > > > the framework of Android:in its design,all UI should be > > done in > > > >>>>>>> JAVA > > > >>>>>>> > > powered > > > >>>>>>> > > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be > > > >>>>>>> choked by the > > > >>>>>>> > > > I/O level because Android don't completely expose them at > > > >>>>>>> all!(I once > > > >>>>>>> > > > managed to port Xfbdev onto it,but that's not commercially > > > >>>>>>> practical at > > > >>>>>>> > > all, > > > >>>>>>> > > > it's just a geeky trick maybe,an app in Android SHOULD NOT > > do > > > >>>>>>> this.) Only > > > >>>>>>> > > > the algorithm/data computing-related C/C++ libs are > > welcomed to > > > >>>>>>> be the > > > >>>>>>> > > JNI > > > >>>>>>> > > > servants to JAVA UI apps in Android. > > > >>>>>>> > > > You see, in such aspect, there is not too much diff > > between > > > >>>>>>> the C++ > > > >>>>>>> > > way > > > >>>>>>> > > > and gtk way in the porting of UI part. > > > >>>>>>> > > > > > >>>>>>> > > I'm going to try to prove that wrong by grepping hoping it > > makes > > > >>>>>>> sense, I > > > >>>>>>> > > never > > > >>>>>>> > > actually coded in gtk: > > > >>>>>>> > > > > > >>>>>>> > > $ git grep GObjectClass > > > >>>>>>> > > gtk/channel-cursor.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/channel-display.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/channel-inputs.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/channel-main.c: GObjectClass *gobject_class = > > > >>>>>>> G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/channel-playback.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/channel-record.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/spice-audio.h: GObjectClass parent_class; > > > >>>>>>> > > gtk/spice-channel.c: GObjectClass *gobject_class = > > > >>>>>>> G_OBJECT_CLASS > > > >>>>>>> > > (klass); > > > >>>>>>> > > gtk/spice-channel.h: GObjectClass parent_class; > > > >>>>>>> > > gtk/spice-gstaudio.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/spice-pulse.c: GObjectClass *gobject_class = > > > >>>>>>> G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/spice-session.c: GObjectClass *gobject_class = > > > >>>>>>> > > G_OBJECT_CLASS(klass); > > > >>>>>>> > > gtk/spice-session.h: GObjectClass parent_class; > > > >>>>>>> > > gtk/spice-widget.c: GObjectClass *gobject_class = > > > >>>>>>> G_OBJECT_CLASS(klass); > > > >>>>>>> > > > > > >>>>>>> > > otoh: > > > >>>>>>> > > U playa:spice-gtk alon (master)$ git grep --name-only > > GdkWindow > > > >>>>>>> > > gtk/spice-widget-cairo.c > > > >>>>>>> > > gtk/spice-widget.c > > > >>>>>>> > > > > > >>>>>>> > > (if you grep Window you get false negatives because of the > > > >>>>>>> compression > > > >>>>>>> > > window). > > > >>>>>>> > > > > > >>>>>>> > > Anyway, this is a lame attempt to prove the gtk stuff that > > does > > > >>>>>>> ui (read: > > > >>>>>>> > > uses X) > > > >>>>>>> > > is separated in the code/architecture level :) > > > >>>>>>> > > > > > >>>>>>> > > > So for me the shining light of spicec-gtk is not in > > "GTK" > > > >>>>>>> but in "C". > > > >>>>>>> > > I > > > >>>>>>> > > > dare not to say I'm clear about every nook in spicec at > > all. My > > > >>>>>>> best hope > > > >>>>>>> > > is > > > >>>>>>> > > > that the IO in spicec shall be straight and succinct ,the > > inner > > > >>>>>>> > > > graphic/sound computing(decompress,etc) shall have NO > > relation > > > >>>>>>> with upper > > > >>>>>>> > > UI > > > >>>>>>> > > > libs at all, so I can pipe the Finished image flow into UI > > > >>>>>>> through JNI > > > >>>>>>> > > > interfaces and direct the user input backward. (That's why > > I > > > >>>>>>> can borrow > > > >>>>>>> > > the > > > >>>>>>> > > > UI from AndroidVNCViewer) > > > >>>>>>> > > > > > >>>>>>> > > Yeah, I think it is generally so, but again, it's so in > > spice-gtk > > > >>>>>>> too, and > > > >>>>>>> > > that's > > > >>>>>>> > > our only future supported client (*). > > > >>>>>>> > > > > > >>>>>>> > > (*) plans do change. > > > >>>>>>> > > > > > > >>>>>>> > > > libspicec.so(do most jobs) > > > >>>>>>> > > > <==finishedimages/audio>>===<<inputs==>spicec.java.ui(only > > UI) > > > >>>>>>> > > > > > > >>>>>>> > > > Am I right? Is there any design that will frustrate this in > > > >>>>>>> spicec or > > > >>>>>>> > > > spice-gtk? > > > >>>>>>> > > > > > >>>>>>> > > spicec is already separated at the platform level, since it > > uses > > > >>>>>>> low level > > > >>>>>>> > > libraries directly, unlike spice-gtk (X and GDI). So you > > would > > > >>>>>>> basically > > > >>>>>>> > > be adding a platform/android. > > > >>>>>>> > > > > > >>>>>>> > > In gtk I really haven't done android development, ever, at > > least > > > >>>>>>> not in the > > > >>>>>>> > > C level, but I was hoping: > > > >>>>>>> > > Option 1: use spice-gtk with a gtk android backend > > > >>>>>>> > > a) compiling gtk for it would be possible. > > > >>>>>>> > > b) write a partial gtk backend, good enough for spice-gtk. > > > >>>>>>> > > c) no changes to spice-gtk. > > > >>>>>>> > > > > > >>>>>>> > > Option 2 is of course to make spice-gtk also have platform > > > >>>>>>> separation, > > > >>>>>>> > > while > > > >>>>>>> > > still using gtk/gobject for all stuff that would Just Work > > when > > > >>>>>>> doing 1.a > > > >>>>>>> > > (the > > > >>>>>>> > > data structures, the signals, the macros, the > > introspection?). > > > >>>>>>> > > > > > >>>>>>> > > > Regards. > > > >>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>> > > > On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy < > > [email protected]> > > > >>>>>>> wrote: > > > >>>>>>> > > > > > > >>>>>>> > > > > On Fri, Mar 04, 2011 at 03:38:51PM +0800, Shuxiang Lim > > wrote: > > > >>>>>>> > > > > > Hi all, > > > >>>>>>> > > > > > I'm trying these days to port spicec into > > Android.But > > > >>>>>>> it's a > > > >>>>>>> > > rather > > > >>>>>>> > > > > TOUGH > > > >>>>>>> > > > > > way to go because the structure of spicec and android > > are > > > >>>>>>> desperately > > > >>>>>>> > > > > > inappropriate:the linux version of spicec is based on > > the > > > >>>>>>> X11,which > > > >>>>>>> > > is > > > >>>>>>> > > > > not > > > >>>>>>> > > > > > available in Android,thus the UI of spicec should be > > > >>>>>>> rewritten from > > > >>>>>>> > > > > > scratch...More troublesome is that the UI part and data > > > >>>>>>> part in > > > >>>>>>> > > current > > > >>>>>>> > > > > > > > >>>>>>> > > > > Haven't looked at your proposal below yet, but did you > > check > > > >>>>>>> the > > > >>>>>>> > > spice-gtk > > > >>>>>>> > > > > work? maybe it is easier to start from that? are gtk > > > >>>>>>> libraries > > > >>>>>>> > > available on > > > >>>>>>> > > > > android? not talking about X. spice-gtk has objects for > > > >>>>>>> connection and > > > >>>>>>> > > > > channels > > > >>>>>>> > > > > that afaik don't do any output, that's separate from the > > > >>>>>>> actual widget > > > >>>>>>> > > that > > > >>>>>>> > > > > uses X. Also, gtk 3 has backends - did anyone do a > > backend > > > >>>>>>> for android? > > > >>>>>>> > > > > > > > >>>>>>> > > > > Since going forward we plan to ditch the spicec client, > > that > > > >>>>>>> would be > > > >>>>>>> > > > > really > > > >>>>>>> > > > > preffered. Now that I see what you have planned it sounds > > > >>>>>>> good, but > > > >>>>>>> > > better > > > >>>>>>> > > > > to use spice-gtk. > > > >>>>>>> > > > > > > > >>>>>>> > > > > of course that's not to say we won't love to see this > > working > > > >>>>>>> anyway :) > > > >>>>>>> > > > > > > > >>>>>>> > > > > > spicec is entangled in the hierarchical system in C++! > > So > > > >>>>>>> my plan is > > > >>>>>>> > > > > this: > > > >>>>>>> > > > > > first split the spicec into two parts,data and > > UI,transform > > > >>>>>>> the data > > > >>>>>>> > > part > > > >>>>>>> > > > > > into libspicec.so;then rewrite the UI part in JAVA. > > > >>>>>>> Besides, I should > > > >>>>>>> > > > > also > > > >>>>>>> > > > > > tinker some problems caused by the Crippled NDK C++ > > support > > > >>>>>>> and the > > > >>>>>>> > > Lamed > > > >>>>>>> > > > > > bionic c lib in android . > > > >>>>>>> > > > > > And now the first step is roughly done,hence the > > change > > > >>>>>>> of the > > > >>>>>>> > > spicec > > > >>>>>>> > > > > > structure: > > > >>>>>>> > > > > > From > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->playback > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->cursor > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > spicec:spicec process（application process）-->main > > > >>>>>>> thread->|-->*record > > > >>>>>>> > > > > thread > > > >>>>>>> > > > > > * > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->inputs > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->display > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > To: > > > >>>>>>> > > > > > ===========================> > > > >>>>>>> > > > > > |-->libspicec.so:application > > > >>>>>>> thread-->main > > > >>>>>>> > > > > > thread------>| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | |<--display > > > >>>>>>> thread<--| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | |--->|<--cursor > > > >>>>>>> > > > > > thread<---|<------------------| > > > >>>>>>> > > > > > | | |<--inputs > > > >>>>>>> thread<---| > > > >>>>>>> > > > > > spicec:spicec process--->| | |<--playback > > > >>>>>>> thread<-| > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > <---------------------------------------------| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > |-->spicec:platform > > > >>>>>>> > > > > > thread------------------------------>| > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > The hierarchical relationship has been unleashed with > > one > > > >>>>>>> > > thread(record > > > >>>>>>> > > > > > channel) deleted and two new threads (app and platform) > > > >>>>>>> created. The > > > >>>>>>> > > > > first > > > >>>>>>> > > > > > as the "data thread",the other as the "work thread" > > which > > > >>>>>>> is driven > > > >>>>>>> > > by > > > >>>>>>> > > > > the > > > >>>>>>> > > > > > signals from the first thread as well as its sub > > threads > > > >>>>>>> and > > > >>>>>>> > > requested to > > > >>>>>>> > > > > do > > > >>>>>>> > > > > > the UI-related work: > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > platform thread：------------>blocked and waiting:-->job > > > >>>>>>> > > > > > request-<--------------| > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > ^ | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > > > |<----------|-<-| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > platform thread over<----------if(job==die)<--| > > > >>>>>>> send req. > > > >>>>>>> > > blocked > > > >>>>>>> > > > > > and waiting > > > >>>>>>> > > > > > | > > ^ > > > >>>>>>> | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > ^ > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > _________|_________ > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > | app/plbk/cusor > > > >>>>>>> > > > > > thd > > > >>>>>>> > > > > > |<---job done----dojob()<--else--| > > | > > > >>>>>>> |->go > > > >>>>>>> > > on->| > > > >>>>>>> > > > > > __________________ > > > >>>>>>> > > > > > | > > | > > > >>>>>>> > > > > > |------------------------------->feed > > back-->| > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > So the next work is to expose the native JNI interface > > in > > > >>>>>>> platform > > > >>>>>>> > > thread > > > >>>>>>> > > > > to > > > >>>>>>> > > > > > the UI written in Android SDK. I try to use the UI > > > >>>>>>> > > > > > frame of AndroidVNCViewer in > > > >>>>>>> > > > > > code.google.com/p/*android*-*vnc*-viewer/,then the > > work of > > > >>>>>>> platform > > > >>>>>>> > > > > > thread will be replaced by UI but the msg > > > >>>>>>> > > > > > communication to libspicec will be remained. That's the > > > >>>>>>> easiest way I > > > >>>>>>> > > can > > > >>>>>>> > > > > > envisage except rewriting all parts in spicec from > > scratch. > > > >>>>>>> > > > > > It's tough too, for I have poor experiance in Java... > > > >>>>>>> > > > > > Anyway, is there any other guy working on this? Is > > my > > > >>>>>>> way > > > >>>>>>> > > > > feasible??Any > > > >>>>>>> > > > > > Ideas or help is appreciated. > > > >>>>>>> > > > > > > > >>>>>>> > > > > See above for ideas, don't read them as a criticism, I > > think > > > >>>>>>> this is > > > >>>>>>> > > > > fantastic > > > >>>>>>> > > > > what you've done so far. I remember someone posting "we > > are > > > >>>>>>> working on > > > >>>>>>> > > > > andriod > > > >>>>>>> > > > > in our spare time" post to spice-devel, please grep the > > > >>>>>>> archive. > > > >>>>>>> > > > > > > > >>>>>>> > > > > Alon > > > >>>>>>> > > > > > > > >>>>>>> > > > > > Best regards. > > > >>>>>>> > > > > > > > >>>>>>> > > > > > _______________________________________________ > > > >>>>>>> > > > > > Spice-devel mailing list > > > >>>>>>> > > > > > [email protected] > > > >>>>>>> > > > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > >>>>>>> > > > > > > > >>>>>>> > > > > > > > >>>>>>> > > > > > >>>>>>> > > > _______________________________________________ > > > >>>>>>> > > > Spice-devel mailing list > > > >>>>>>> > > > [email protected] > > > >>>>>>> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > >>>>>>> > _______________________________________________ > > > >>>>>>> > Spice-devel mailing list > > > >>>>>>> > [email protected] > > > >>>>>>> > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Spice-devel mailing list > > > >>>> [email protected] > > > >>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > _______________________________________________ > > > Spice-devel mailing list > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > > > _______________________________________________ > Spice-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
