Hi, I would also be interested in an android port, and looking through spice-gtk, it does seems much simpler than spicec.
Best Regards, Attila On Fri, Mar 4, 2011 at 9:36 AM, Alon Levy <al...@redhat.com> 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 > > Spice-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel >
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
