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
