[Spice-devel] Try to port spicec into Android
Alon Levy
alevy at redhat.com
Mon Mar 7 01:14:05 PST 2011
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 <alevy at redhat.com> 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 <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
> >
> >
> _______________________________________________
> 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