Well, I think I may try the "--with-coroutine=gthread" in spice-gtk configuring to walk around that... <div class="gmail_quote">On Wed, Mar 9, 2011 at 11:10 AM, Shuxiang Lim <<a href="mailto:shohyanglim@gmail.com">shohyanglim@gmail.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;">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.<div><div></div><div class="h5"> <div class="gmail_quote">On Mon, Mar 7, 2011 at 5:14 PM, Alon Levy <<a href="mailto:alevy@redhat.com" target="_blank">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>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). </div>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). <div> > 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.) </div>Definitely easier to port to Maemo :) <div><div></div><div> > Regards. > > On Fri, Mar 4, 2011 at 7:04 PM, Alon Levy <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> 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 <<a href="mailto:alevy@redhat.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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> </div></div></blockquote></div>