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 uses the xrandr
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
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.
/Roman
--
http
/java/awt/peer/gtk/GtkToolkit.java: Removed mistakenly
committed code.
/Roman
Am Freitag, den 08.02.2008, 23:22 +0100 schrieb Roman Kennke:
This changes the System.loadLibrary() calls in the GTK peers, so that
they are only called when configured so. This is important for VMs that
can't
This changes the System.loadLibrary() calls in the GTK peers, so that
they are only called when configured so. This is important for VMs that
can't or don't want to link dynamically, e.g. when creating full static
linked binaries like Jamaica.
2008-02-08 Roman Kennke [EMAIL PROTECTED
Committed.
Ian Rogers wrote:
Hi,
attached is a patch required to make JNI GTk peers work on 32bit
architectures.
Regards,
Ian
Hi,
attached is a patch required to make JNI GTk peers work on 32bit
architectures.
Regards,
Ian
--- native/jni/gtk-peer/gtkpeer.c 2007-05-08 01:00:54.0 +0100
+++ native/jni/gtk-peer/gtkpeer.c 2007-10-17 10:49:25.0 +0100
@@ -102,11 +102,13 @@
#else
Andrew John Hughes writes:
On Monday 08 October 2007 16:58:57 Andrew John Hughes wrote:
On Thursday 27 September 2007 14:24:50 Ian Rogers wrote:
Hi,
this patch removes a call to atexit from GtkToolkit. The comment didn't
give sufficient detail as to why the atexit call was
On Monday 08 October 2007 16:58:57 Andrew John Hughes wrote:
On Thursday 27 September 2007 14:24:50 Ian Rogers wrote:
Hi,
this patch removes a call to atexit from GtkToolkit. The comment didn't
give sufficient detail as to why the atexit call was necessary and the
failure I witnessed in
On Thursday 27 September 2007 14:24:50 Ian Rogers wrote:
Hi,
this patch removes a call to atexit from GtkToolkit. The comment didn't
give sufficient detail as to why the atexit call was necessary and the
failure I witnessed in the Jikes RVM was as follows:
1) VM runs some AWT code that
Hi,
this patch removes a call to atexit from GtkToolkit. The comment didn't
give sufficient detail as to why the atexit call was necessary and the
failure I witnessed in the Jikes RVM was as follows:
1) VM runs some AWT code that causes the atexit routine in GtkToolkit to
be registered
2)
Hi,
This patch changes the GTK peers, so that they can be compiled and used
on systems without X, for example on GTK for embedded or Windows
systems. In many places this only removes imports that are unused, there
are only two notable changes:
- The GdkRobotPeer now has #ifdef HAVE_XTEST for all
Roman Kennke wrote:
Hi,
This patch changes the GTK peers, so that they can be compiled and used
on systems without X, for example on GTK for embedded or Windows
systems. [...]
- The code for fetching the frame extents now uses the (new?) GDK
function gdk_window_get_frame_extents() rather than
Hi Tom,
- The code for fetching the frame extents now uses the (new?) GDK
function gdk_window_get_frame_extents() rather than pulling the frame
extents using the extended window property _NET_FRAME_EXTENTS.
This will result in the wrong insets being calculated upon window
realization,
Roman Kennke wrote:
Hi Tom,
- The code for fetching the frame extents now uses the (new?) GDK
function gdk_window_get_frame_extents() rather than pulling the frame
extents using the extended window property _NET_FRAME_EXTENTS.
This will result in the wrong insets being calculated upon window
Roman Kennke wrote:
I removed the old NSA native state handling and implemented a more
natural approach. The NSA native state API was maintaining (native)
hashtables to hold the native state to the peer objects and others. This
has a couple of disadvantages:
- It's not really scaleable.
Hi,
This patch provides closer integration between cairo and our GTK peers,
using an optimized cairo-backed Raster (and sharing a databuffer) when
possible.
These changes result in a 30-50% speedup in rendering java2d operations
on RGB/ARGB BufferedImage's.
Still a bit of a work
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
Hi,
This patch implements custom cursor support for gtk-peers. It works the
same as setting icons on frames.
2006-03-22 Mark Wielaard [EMAIL PROTECTED]
Fixes bug #26301
* gnu/java/awt/peer/gtk/GtkComponentPeer.java (gtkWidgetSetCursor):
Takes GtkImage, x and y coordinates
On Thu, 2006-03-23 at 00:27 +0100, Mark Wielaard wrote:
This patch implements custom cursor support for gtk-peers.
Forgot the new file. Sorry.
2006-03-22 Mark Wielaard [EMAIL PROTECTED]
* gnu/java/awt/peer/gtk/GtkCursor.java: New class.
Committed now.
/* GtkCursor.java -- Simple
On Thu, 2006-03-23 at 00:37 +0100, Mark Wielaard wrote:
On Thu, 2006-03-23 at 00:27 +0100, Mark Wielaard wrote:
This patch implements custom cursor support for gtk-peers.
Forgot the new file. Sorry.
And the bug number was wrong in the ChangeLog file. Sigh.
Also fix to mention the real bug
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
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
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
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
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 and
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 one
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
Hi,
On Tue, 2005-08-16 at 19:03 -0400, Thomas Fitzsimmons wrote:
Yes, please discuss this with Owen Taylor and file bugs against GTK if
necessary. This is a relatively new API and we should provide feedback
where it doesn't meet our needs.
I filed the following bugs that would make our (and
On Sun, 2005-08-21 at 16:35 +0200, Mark Wielaard wrote:
Hi,
On Tue, 2005-08-16 at 19:03 -0400, Thomas Fitzsimmons wrote:
Yes, please discuss this with Owen Taylor and file bugs against GTK if
necessary. This is a relatively new API and we should provide feedback
where it doesn't meet
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
Hi,
On Tue, 2005-08-16 at 20:00 +0200, Mark Wielaard wrote:
I would like for someone to review how I handled the native/gtk
lock/thread transitions. Since the datatransfer api is basically
synchronous, but the gtkclipboard is asynchronous we need to call into
gtk+ to setup callbacks and then
Hi,
On Mon, 2005-07-25 at 21:56 -0400, Thomas Fitzsimmons wrote:
@@ -372,8 +374,28 @@
if (x == 0 y == 0 width == 0 height == 0)
return;
-q().postEvent (new PaintEvent (awtComponent, PaintEvent.UPDATE,
- new Rectangle (x, y, width,
On Tue, 2005-07-26 at 07:48 +0200, Mark Wielaard wrote:
I don't think you want to create a (non-daemon) Timer each and every
time here. That means that on each repaint() a new Thread is created
which is never destroyed and which will prevent the application to ever
stop since the Timers will
Hi,
This patch does three things:
- implements GtkComponentPeer.repaint timed repaints properly
- implements GtkComponentPeer.updateCursorImmediately
- fixes handling of memory image sources in GtkImageConsumer
I committed this to mainline. This patch gets the Cortado applet closer
to working
Hi,
I committed this patch. It is mostly a formatting change that makes it
clearer which native functions are run with the GDK lock held.
This patch may cause some temporary regressions as I separated it out
from other work I had in my tree, but I'll fix any problems in the next
few days.
Tom
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
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
only exist in classpath
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 default
if possible. Any problems with doing
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 JVM threading
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.
See what
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:
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 threading
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 interesting, but I have a screenshot here:
http
)
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,
it will open up a whole lot of applications that my JVM could never run previously.
John Leuner
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 interesting, but I have a screenshot here:
http
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 correctly, the
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's not at all interesting, but I have
gure 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] 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 linking
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
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 there is
),
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_gtk_GtkChoicePeer.h
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
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
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]
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's all that matters.
If you want
57 matches
Mail list logo
