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
