[Spice-devel] Try to port spicec into Android
Alon Levy
alevy at redhat.com
Fri Mar 4 03:04:47 PST 2011
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 <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
> >
> >
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
More information about the Spice-devel
mailing list