Could you maybe give access to other devs to aid the development? Rgrds,
Attila On Wed, Mar 9, 2011 at 11:18 AM, Shuxiang Lim <[email protected]> wrote: > Yep, I walked around this but to face more chored and nasty troubles in > porting Pulseaudio lib, time limited, so I decided to DISABLE the > audio(playback/record) channels first. Thus the porting of libspicec_glib.so > is finished(along with all its dependences) and androidVNCViewer(whose UI > will be peeled to become spicec's) proj. has been built: > *#file libspicec_glib.so * > libspicec_glib.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), > dynamically linked, not stripped > *#arm-eabi-readelf -d libspicec_glib.so * > Dynamic section at offset 0x774a4 contains 27 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libc.so] > 0x00000001 (NEEDED) Shared library: [libm.so] > 0x00000001 (NEEDED) Shared library: [libpixman-1.so.0] > 0x00000001 (NEEDED) Shared library: [libssl.so.1.0.0] > 0x00000001 (NEEDED) Shared library: > [libcrypto.so.1.0.0] > 0x00000001 (NEEDED) Shared library: [libjpeg.so.62] > 0x00000001 (NEEDED) Shared library: [libz.so] > 0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0] > 0x00000001 (NEEDED) Shared library: [libgio-2.0.so.0] > 0x00000001 (NEEDED) Shared library: > [libgobject-2.0.so.0] > 0x00000001 (NEEDED) Shared library: > [libgmodule-2.0.so.0] > 0x00000001 (NEEDED) Shared library: > [libgthread-2.0.so.0] > 0x00000010 (SYMBOLIC) 0x0 > .... > Now comes the last adventure of Native interfaces exposing and UI building! > Regards. > > > On Wed, Mar 9, 2011 at 3:57 PM, Shuxiang Lim <[email protected]>wrote: > >> 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 > >
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
