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. 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) libspicec.so(do most jobs) <==finished images/audio>>===<<inputs==>spicec.java.ui(only UI) Am I right? Is there any design that will frustrate this in spicec or spice-gtk? Regards. <div class="gmail_quote">On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy <<a href="mailto:alevy@redhat.com">alevy@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">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 </div>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 :) <div><div></div><div class="h5"> > 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 > <a href="http://code.google.com/p/*android*-*vnc*-viewer/,then" target="_blank">code.google.com/p/*android*-*vnc*-viewer/,then</a> 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. </div></div>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 <div><div></div><div class="h5"> > Best regards. > _______________________________________________ > Spice-devel mailing list > <a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> </div></div></blockquote></div>