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). 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.) Regards. <div class="gmail_quote">On Fri, Mar 4, 2011 at 7:04 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 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. </div>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 :) <div class="im"> > 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) </div>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. <div class="im">> > libspicec.so(do most jobs) </div>> <==finishedimages/audio>>===<<inputs==>spicec.java.ui(only UI) <div class="im">> > Am I right? Is there any design that will frustrate this in spicec or > spice-gtk? </div>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?). <div><div></div><div class="h5"> > Regards. > > > On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy <<a href="mailto:alevy@redhat.com">alevy@redhat.com</a>> 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 > > > <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. > > > > 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 > > > <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> > > > > > _______________________________________________ > 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>