[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Fri Mar 4 02:21:19 PST 2011
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.
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)
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?
Regards.
On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy <alevy at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110304/5c3dc755/attachment.html>
More information about the Spice-devel
mailing list