[Kde-java] KPanelApplet
KJ P
kde-java@kde.org
Thu, 14 Feb 2002 10:13:42 +0000
Hello Richard
>Yes, you are dealing with some 'hot wax' in Qt/KDE. A good place to look
>for
>an example of C++ wrapper code starting a jvm and invoking some java is in
>kdevelop/parts/javasupport/javasupportfactory.cpp
Thanks for this. I could not find anything in the sources. The sources I
have from cvs (about 7 months) does not have anything or else I could not
find it. I did not have the kdevelop source on my machine. Great code. I
got a JVM created yesterday (never have done this before) and started
messing around with passing information to my very simple java program. I
was getting all sorts of crap! Then I was wondering how to get the
environment information from KDE (me being a newbie and all) and I just left
it at that. Blew out my candles, stretched my creaking C++ joints and went
to bed.
Then I wake up to find the answers sitting here. Well most of them anyway.
I will try from this base if you do not mind. You guys really do great
work.
Well come to find out the KSystemTray is exactly what I wanted in the first
place. I have some examples of using this in java if you want. Mine are
very simple just to test some of the functionality, very simple learning
examples. Since you have already implemented this you will be putting these
in the examples or would you be willing to except mine? Simple examples are
easier to follow for new people than full blown programs when the people do
not know how to read C++ code.
I am not giving up on the JVM instantiation because it is a challenge for
me. I hope to have something in a couple of days.
>'Ongoing' as in 'not yet started' - yes :) I think compiling with gcj would
>be
>the best way to speed up start times. Thomas Kuhn has adapted the bindings
>to
>work with gcj. But I haven't been able to check the changes in because gcj
I thought about gcj for one of my projects about 2 moths ago but never got
around to trying it out because of the swing implementation but since the
bindings use the Qt and KDE I can not wait to get my hands and some time on
it.
>They need serialization to be implemented first, the C++ '>>' and '<<'
>operators translated into suitable java method names. Again Thomas Kuhn
>sent
>me some interesting stuff on DCOP/serialization, which I haven't had any
>time
>to do anything about. I think the more people who look at the 'not
>finished'
>bits the better - so please carry on and find out what needs to be done..
For DCOP/serialization that would mean something like what Java RMI does?
Again thanks.
Kenneth
>From: Richard Dale <Richard_Dale@tipitina.demon.co.uk>
>Reply-To: kde-java@kde.org
>To: kde-java@kde.org
>Subject: Re: [Kde-java] KPanelApplet
>Date: Thu, 14 Feb 2002 00:42:36 +0000
>
>On Wednesday 13 February 2002 11:57 am, KJ P wrote:
> > Hello Richard
> >
> > Yes looking back at the mailing list it was KSystemTray. my bad.
> >
> > I have been trying this with KJavaProcess. Maybe that is not the way to
>go
> > and I should try to create a jvm from native code.
> >
> > The KJavaProcess is hanging me up for right now. I have looked at the
>test
> > examples and followed the code but to now avail. I will try to look at
> > another solution. I guess it is time to go read about invoking the JVM.
> > That and brushing up on my C++ skills plus learning the KDE and Qt
> > libraries is burning a lot of candles :-)
>Yes, you are dealing with some 'hot wax' in Qt/KDE. A good place to look
>for
>an example of C++ wrapper code starting a jvm and invoking some java is in
>kdevelop/parts/javasupport/javasupportfactory.cpp
>
> > I also noticed that for a TODO item in the bindings there was something
> > about creating another process like kdeinit called kdejavainit. Is that
> > ongoing?
>'Ongoing' as in 'not yet started' - yes :) I think compiling with gcj would
>be
>the best way to speed up start times. Thomas Kuhn has adapted the bindings
>to
>work with gcj. But I haven't been able to check the changes in because gcj
>doesn't work properly with overloaded methods on my machine.
>
> > The DCOPClient in java is killing me as well. I am not getting the
> > response type and data back. I can send to a DCOP interface as long as
>I
> > am not expecting back data. There is also a TODO item on this as well.
>I
> > can get the type and data back using the javadcop library and compiling
> > agains the Client, DCOPRef, Response classes. I just can not parse the
> > DREF objects. Listing all the processes from a byte data is fine as long
>as
> > there is a len:data associated in the byte array returned. A little
> > cumbersome to use in my opinion. Maybe I should not be looking at this
> > part because they are not finished?
>They need serialization to be implemented first, the C++ '>>' and '<<'
>operators translated into suitable java method names. Again Thomas Kuhn
>sent
>me some interesting stuff on DCOP/serialization, which I haven't had any
>time
>to do anything about. I think the more people who look at the 'not
>finished'
>bits the better - so please carry on and find out what needs to be done..
>
>-- Richard
>
>_______________________________________________
>Kde-java mailing list
>Kde-java@mail.kde.org
>http://mail.kde.org/mailman/listinfo/kde-java
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com