I committed some changes to the GTK native peer code to try get it to
run a little further than it did before.
Now I can sometimes get a very simple application (with one Frame) to
run some of the time.
It seems that sometimes there is some threading problem which causes an
Xlib error:
Xlib: une
All,
I know some folks are working on the gtk peers. I think we'd like to
make the code enabled with --enable-portable-native-sync the default
if possible. Any problems with doing this? This build option may
only exist in classpath, not sure about gcj.
Thanks,
Brian
--
Brian Jones &l
I like the nice little Makefile for the gtk peers, however it really
shouldn't be necessary to keep this thing. Could one of you, Jim or
Paul, update update Makefile.am in the peer directory to compile your
native files. Aaron decided the best thing to do about the header
generation is to
gdk-pixbuf has been successfully wrapped, and it now functions as an
ImageProducer. We can load any image format that gdk-pixbuf supports
-- bmp, gif, jpeg, png, pnm, ras, tiff, and xpm. All of these formats
can be incrementally loaded (except for PNG, which is due to a buggy
loader in gdk-pixbu
build procedure),
including the necessary headers from my JVM etc, and then link the objects
into a .a library.
This has worked well so far for the first two, javaio.a and javanet.a, but
when doing the gtk peers I'm missing these headers:
gnu_java_awt_peer_gtk_GtkToolkit.h
gnu_java_awt_peer
va.awt.peer.gtk/
>
> And the make my own makefile (not using classpath's build procedure),
> including the necessary headers from my JVM etc, and then link the objects
> into a .a library.
>
> This has worked well so far for the first two, javaio.a and javanet.a,
tk/
> >
> > And the make my own makefile (not using classpath's build procedure),
> > including the necessary headers from my JVM etc, and then link the objects
> > into a .a library.
> >
> > This has worked well so far for the first
John Leuner <[EMAIL PROTECTED]> writes:
> > They are generated by make and I actually should remove those others
> > in the native/* directories.
>
> Ok. Are there any plans to provide separate compilation of these
> native 'modules'? It would certainly be useful to me, but I don't
> know if t
VM that you
> > > need to build with?
> >
> > As far as I'm aware this is all that is needed.
>
> Okay, I'll probably rework the configure stuff to let you specify
> where to get jni.h from until we actually autogenerate that ourselves.
That would be most appreciated. How functional are the GTK peers at
present?
John
John Leuner ([EMAIL PROTECTED]) wrote:
> That would be most appreciated. How functional are the GTK peers at
> present?
>From the screen shots I've seen, they are working ok. Paul was
planning on packaging them up as a release soon.
--
Aaron M. Renn ([EMAIL PR
John Leuner <[EMAIL PROTECTED]> writes:
> That would be most appreciated. How functional are the GTK peers at
> present?
You can try them yourself if you want. Compile them (they are in the
usual build these days) then do a little trick Jim Blair recommends
which is to create
John Leuner <[EMAIL PROTECTED]> writes:
> Well in my case it would be nice to be able to tell the Makefile to build
> a .so library that I can just link in with a normal UNIX executable. But
> what I'm planning for my VM is also to deploy it as the kernel of an
> experimental OS (where dynamic li
John Leuner <[EMAIL PROTECTED]> writes:
> I committed some changes to the GTK native peer code to try get it to
> run a little further than it did before.
>
> Now I can sometimes get a very simple application (with one Frame) to
> run some of the time.
>
> It seems that sometimes there is some t
> > It seems that sometimes there is some threading problem which causes an
> > Xlib error:
> >
> > Xlib: unexpected async reply (sequence 0x29)!
> >
> > Using kissme, if I enable some internal debugging (with -t jni), this is
> > less likely to happen, so I think it's a thread timing issue.
>
>
On Mon, 2003-07-28 at 09:02, Brian Jones wrote:
> All,
>
> I know some folks are working on the gtk peers. I think we'd like to
> make the code enabled with --enable-portable-native-sync the default
> if possible. Any problems with doing this?
> This build option may
&g
Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> On Mon, 2003-07-28 at 09:02, Brian Jones wrote:
> > All,
> >
> > I know some folks are working on the gtk peers. I think we'd like to
> > make the code enabled with --enable-portable-native-sync the defau
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
Brian> Okay. I think that some folks on the jikesrvm team contributed the
Brian> ifdef'd code enabled by the native-sync option. It was to allow the
Brian> peers/awt to work with their JVM and supposedly had benefits of using
Brian> the JV
Brian Jones <[EMAIL PROTECTED]> writes:
> I like the nice little Makefile for the gtk peers, however it really
> shouldn't be necessary to keep this thing.
We're off in our own little world. Please leave us alone. :)
Our Makefiles work for the two of us, and that'
Paul Fisher <[EMAIL PROTECTED]> writes:
> gdk-pixbuf has been successfully wrapped, and it now functions as an
> ImageProducer. We can load any image format that gdk-pixbuf
> supports -- bmp, gif, jpeg, png, pnm, ras, tiff, and xpm.
Oh, and since gdk-pixbuf only supports single frame images, we
tk/
> >
> > And the make my own makefile (not using classpath's build procedure),
> > including the necessary headers from my JVM etc, and then link the objects
> > into a .a library.
> >
> > This has worked well so far for the first
John Leuner <[EMAIL PROTECTED]> writes:
> > My question is about the GTK peers. I have managed to generate the header files
>for each .c files, and can run up to the point where an GTK frame is created with a
>title. (Mouse events also seem to be handled)
>
> It'
> > > My question is about the GTK peers. I have managed to generate the header files
>for each .c files, and can run up to the point where an GTK frame is created with a
>title. (Mouse events also seem to be handled)
> >
> > It's not at all interesti
John Leuner <[EMAIL PROTECTED]> writes:
> > > > My question is about the GTK peers. I have managed to generate the header
>files for each .c files, and can run up to the point where an GTK frame is created
>with a title. (Mouse events also seem to be handled)
>
Hi,
Well, I got started on fixing transparency issues with AWT, and now it
seems I'm ending up rewriting most of the image-handling code here.
Most of how this stuff is implemented now makes no sense to me at all.
I propose (and am working on) the following main points:
1) GtkImage is a mess, and
Paul and I have been working on a GTK implementation of the
AWT peers. We've spent some time working on the library weirdness on
the native side and also an inordinate amount of time picking apart
GTK and putting it back together. I now have something that is not
only viewable, but is also the
Unfortunately, the end portion of this week hasn't been so kind to me,
and I haven't been able to finish up everything that's necessary for a
release.
New target date is sometime this week...
--
Paul Fisher * [EMAIL PROTECTED]
> > > My question is about the GTK peers. I have managed to generate the header files
>for each .c files, and can run up to the point where an GTK frame is created with a
>title. (Mouse events also seem to be handled)
> >
> > It's not at all interesti
> "John" == John Leuner <[EMAIL PROTECTED]> writes:
>> You should be able to finish up the peers by simply combining them
>> with a 1.1 JDK.
John> It's a pity you don't know what it is. I looked through the old
John> classpath mailing list archive but didn't find anything.
If I understand c
John Leuner <[EMAIL PROTECTED]> writes:
> It's a pity you don't know what it is. I looked through the old
> classpath mailing list archive but didn't find anything.
Wow, on a search through my sent email (since my inbox doesn't keep
things as long...) I found this in a previous response to you s
Hi Sven,
> I propose (and am working on) the following main points:
> 1) GtkImage is a mess, and is terribly inefficient. Do what was intended
> with the AWT 1.1 API and wrap something which can be blitted quickly,
> e.g. a 32-bit int vector in gtk-compatible AABBGGRR format.
>
> 2) Get rid of Gt
On Fri, 2005-05-27 at 07:41 +0200, Sven de Marothy wrote:
> Hi,
> Well, I got started on fixing transparency issues with AWT, and now it
> seems I'm ending up rewriting most of the image-handling code here.
>
> Most of how this stuff is implemented now makes no sense to me at all.
>
> I propose (
Hi all,
is there a way to build GNU Classpath with Gtk peers being usable with
DirectFB backend (instead of Xorg/X11)?
My final goal would be using these peers based on DirectFB within gcj, is this
feasible?
Thank you,
Francesco
This is great. Like the screenshot. Thanks a ton for working on this. A
working Classpath-awt/Japhar/Mozilla combo would be supreme.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
wt.Window.show(Window.java:278)
at kissme_test.FrameTest.(FrameTest.java:12)
at kissme_test.FrameTest.main(FrameTest.java:26)
I suppose I should go find a 1.1 Blackdown JDK.
Thanks for the help and tips, I would love to get the GTK peers working with my JVM,
i
)
> at java.awt.Frame.addNotify(Frame.java:270)
> at java.awt.Window.show(Window.java:278)
> at kissme_test.FrameTest.(FrameTest.java:12)
> at kissme_test.FrameTest.main(FrameTest.java:26)
>
> I suppose I should go find a 1.1 Blackdown JDK.
>
> Th
Hello,
I've just got my Nokia770 2 days ago and today I was able to build a
working sablevm package for it, after I sadly failed with kaffe.
It really works well (and slow ;) ) expect some glitches with
AWT/Peers, however one main problem is there which I wasn't able to
solve:
As soon as I crea
Hi Francesco,
> is there a way to build GNU Classpath with Gtk peers being usable with
> DirectFB backend (instead of Xorg/X11)?
There's some X11 specific code in the GTK peers. You would have to get
rid of this. Besides this, it should be possible. It's some work though.
Hi,
Roman Kennke schrieb:
> There's some X11 specific code in the GTK peers. You would have to get
> rid of this. Besides this, it should be possible. It's some work though.
at least some of this X11-specific code is only there to implement
GraphicsEnvironment and friends. It
> Hi,
>
> Roman Kennke schrieb:
> > There's some X11 specific code in the GTK peers. You would have to get
> > rid of this. Besides this, it should be possible. It's some work though.
> at least some of this X11-specific code is only there to implement
> Gra
Hi Clemens,
On Wed, 2005-10-26 at 15:42 +, Clemens Eisserer wrote:
> Nokia claims that the modified GTK-2.6.? they use is binary compatible
> to GTK-2.6.
> I went a bit through the peers code and it was quite straightforeward
> to read, however I did not find a function call to "g_object_ref"
On Wed, 2005-10-26 at 15:42 +, Clemens Eisserer wrote:
> Hello,
>
> I've just got my Nokia770 2 days ago and today I was able to build a
> working sablevm package for it, after I sadly failed with kaffe.
>
> It really works well (and slow ;) ) expect some glitches with
> AWT/Peers, however o
Thanks a lot for looking at this problem, I asked on so many lists
since I was not sure which of the many components interacting (jvm,
gtk, classpath peers, ...) could cause the problem.
> My guess is that gdk_drawable_get_colormap returns something we're not
> expecting. Can you put a printf in
Hello again,
I just played a bit further and found out that
gdk_rgb_get_visual()->depth returns 24-bit as depth.
I do not have any deeper experiences with GTK/GDK at all (since I
dislike it a bit to be honest ;) ), but the gdk documentation says
that "This colormap and the corresponding visual sho
> The strange thing is that I wrote a small test-sample myself which
> does succeed in both cases with a 16 and a 24 bit pixmap, also
> colormap creation works for both depths, I don't have any clue why it
> fails inside of classpath's peers.
Sorry for the confusion it was a bug in my simple test-p
Hi,
I tried running simple swing application, and it worked when export the display to another machine (Xwin). I am not sure if this info helps, but I wonder why the rendering fail in the tablet.
Thanks
-Somas
View this message in context: Re: Problems running GTK-peers on Nokia-770
Sent
onder why the rendering fail in the tablet.
>
>
> Thanks
>
> -Somas
>
> View this message in context: Re: Problems running GTK-peers on Nokia-770
> Sent from the Gnu - Classpath - General forum at Nabble.com.
> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
Tom> This patch merges into Classpath the improvements made to libgcj's GTK
Tom> peers since the savannah break-in.
Tom> OK to commit?
Yeah. The general rule, as I understand it, is if something has gone
through libgcj patch review th
Our GTK+ peers are currently dependent on GTK+ being run on top of X. I tried
to compile them on top of GTK+/Quartz (from GTK+ CVS) today and it failed on
GdkGraphics.c which relies on the existence of XFlush in gdk/gdkx.h. We need
to #ifdef appropriately on the underlying GDK implementation if
Hi,
Moving the the main classpath list as a FYI for all runtime developers.
They probably know, but since we are now relying on this lets explicitly
say so.
On Wed, 2005-08-17 at 23:16 -0400, Thomas Fitzsimmons wrote:
> I'm removing these workarounds for a JamVM deadlock problem that was
> fixed
49 matches
Mail list logo
