Re: javax.swing.plaf; next steps

[Thomas Fitzsimmons]

On Fri, 2003-06-27 at 04:13, Sascha Brawer wrote:
> Hi all,
> 

Hello,

> I am glad to announce that the GNU Classpath implementation of the
> package "javax.swing.plaf" has been finished.

Cool.

>  This package provides
> abstract base classes for pluggable look and feels, so most of the work
> has been to write documentation.
> 
> Like javax.swing.border and javax.swing.plaf.basic.BasicBorders, the code
> has been tested by prepending the Classpath implementation to the
> bootclasspath of a Sun JDK, and running SwingSet2.
> 
> For a UML diagram that (sort of) explains Swing's pluggable look-and-feel
> architecture, see the file javax/swing/plaf/doc-files/ComponentUI-1.png
> in CVS. As the diagram shows, the real work is mostly done in other
> packages, especially javax.swing.plaf.basic. Unfortunately, this is a
> place where Classpath has not come very far yet.
> 
> So, if someone would like to step in, I think it would be a good time to
> start now, for example by making one of javax.swing.plaf.basic.Basic*UI
> work. One could pick a single widget (like JSlider) and develop its UI
> delegate (javax.plaf.basic.BasicSliderUI) independent of the rest. To
> test the code, use the -Xbootclasspath/p option of the Sun JDK.
> 

Currently, I'm merging classpath's GTK 2.0 peers into libgcj, but once
I'm done that, I'll start working on a UI delegate.

Concerning testing: rather than use Sun's JDK, I would like to test the
classpath Swing implementation with gcj/libgcj.  Perhaps, toward the end
of testing a simple UI delegate, I could implement the necessary
supporting classes in classpath/libgcj.  Do you have an idea of how much
work that would be?

Tom

> Best regards,
> 
> -- Sascha
> 
> Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
> 
> PS: Thanks again to Michael Koch for having run japitools.
> 
> 
> 
> _______
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath
-- 
Thomas Fitzsimmons <[EMAIL PROTECTED]>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: javax.swing.plaf; next steps

[Thomas Fitzsimmons]

On Fri, 2003-06-27 at 19:40, Brian Jones wrote:
> Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> 
> > Currently, I'm merging classpath's GTK 2.0 peers into libgcj, but once
> > I'm done that, I'll start working on a UI delegate.
> 
> Those peers still need a lot of work btw, I've not seen any AWT app
> run yet with them.

I've merged them into my local libgcj tree (see [EMAIL PROTECTED]
for the patches) and they can run most of TestAWT acceptably.  Mind you,
they still do need a lot of work.  Keyboard events seem to be completely
broken, for example.

>   Anyone know how to treat GtkEntry and GtkTextView
> the same for the functions in GtkTextComponentPeer?  Seems like in
> GTK2 they broke the whole GtkEditable concept and didn't fix it...
> 

Hmmm... I'll look into this.

Tom

> Brian
-- 
Thomas Fitzsimmons <[EMAIL PROTECTED]>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: javax.swing.plaf; next steps

[Thomas Fitzsimmons]

On Fri, 2003-06-27 at 19:40, Brian Jones wrote:
> Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> 
> > Currently, I'm merging classpath's GTK 2.0 peers into libgcj, but once
> > I'm done that, I'll start working on a UI delegate.
> 
> Those peers still need a lot of work btw, I've not seen any AWT app
> run yet with them.  Anyone know how to treat GtkEntry and GtkTextView
> the same for the functions in GtkTextComponentPeer?  Seems like in
> GTK2 they broke the whole GtkEditable concept and didn't fix it...
> 

Yeah, it looks like they just kind of abandoned the notion of
GtkEditable...

Anyway, both GtkEntry and GtkTextView have the property "editable" so
couldn't we change the GtkComponentPeer's native set methods to use
g_object_set?

Tom

> Brian
-- 
Thomas Fitzsimmons <[EMAIL PROTECTED]>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Patch: Regenerate JNI headers automatically

[Thomas Fitzsimmons]

Hello,

This patch adds a configure flag that enables automatic regeneration of
JNI headers.  The flag is disabled by default.

Each header is only rebuilt if its prerequisite .java file changes.  The
new automake file, include/Makefile.am, contains the list of header
targets.

Currently the list consists of AWT-related headers.  Could someone who
is more familiar with the other areas of classpath that require JNI
headers complete the list?  Some headers should probably be removed.

Mark Wielaard suggested that anyone checking in changes to these headers
should use gcjh, since it is free and produces clean output.  If people
agree with this, I will regenerate the AWT-headers and check them in.

Comments?

Tom

2003-07-23  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* Makefile.am (SUBDIRS): Add $(HEADER_DIR).
* configure.in: Add --enable-regen-headers flag.
(AC_OUTPUT): Add include/Makefile.
* include/Makefile.am: New file.

Index: Makefile.am
===
RCS file: /cvsroot/classpath/classpath/Makefile.am,v
retrieving revision 1.25
diff -u -b -B -r1.25 Makefile.am
--- Makefile.am	1 Feb 2003 12:54:05 -	1.25
+++ Makefile.am	23 Jul 2003 15:40:51 -
@@ -1,7 +1,7 @@
 ## Input file for automake to generate the Makefile.in used by configure
 
 # lib first, to compile .class files before native code
-SUBDIRS = lib doc gnu java javax native resource vm
+SUBDIRS = lib doc gnu java javax $(HEADER_DIR) native resource vm
 
 native: lib
 
Index: configure.in
===
RCS file: /cvsroot/classpath/classpath/configure.in,v
retrieving revision 1.127
diff -u -b -B -r1.127 configure.in
--- configure.in	16 Jul 2003 15:17:33 -	1.127
+++ configure.in	23 Jul 2003 15:40:51 -
@@ -75,6 +75,16 @@
 AM_CONDITIONAL(CREATE_CNI_LIBRARIES, test "x${COMPILE_CNI}" = xyes)
 AM_CONDITIONAL(CREATE_GTK_PEER_LIBRARIES, test "x${COMPILE_GTK_PEER}" = xyes)
 
+AC_ARG_ENABLE(regen-headers,
+[  --enable-regen-headers   automatically regenerate JNI headers [default=no]],
+[case "${enableval}" in
+  yes) HEADER_DIR=include ;;
+  no) HEADER_DIR="" ;;
+  *) HEADER_DIR="" ;;
+esac],
+[HEADER_DIR=""])
+AC_SUBST(HEADER_DIR)
+
 AC_PROG_LN_S
 AC_PROG_INSTALL
 
@@ -328,6 +338,7 @@
 gnu/javax/Makefile
 gnu/javax/rmi/Makefile
 gnu/javax/rmi/CORBA/Makefile
+include/Makefile
 include/jni.h
 java/Makefile
 java/applet/Makefile
Index: include/Makefile.am
===
RCS file: include/Makefile.am
diff -N include/Makefile.am
--- /dev/null	1 Jan 1970 00:00:00 -
+++ include/Makefile.am	23 Jul 2003 15:40:51 -
@@ -0,0 +1,100 @@
+USER_JAVAH = @USER_JAVAH@
+USER_CLASSLIB = @USER_CLASSLIB@
+ARG_JNI_JAVAH = -jni
+ARG_CLASSPATH_JAVAH = -classpath
+JAVAH = $(USER_JAVAH) $(ARG_JNI_JAVAH) $(ARG_CLASSPATH_JAVAH) ../lib:$(USER_CLASSLIB)
+
+H_FILES = \
+$(top_srcdir)/include/gnu_java_awt_image_GdkPixbufDecoder.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GdkFontMetrics.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GdkGraphics.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkButtonPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkCanvasPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkCheckboxGroupPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkCheckboxMenuItemPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkCheckboxPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkChoicePeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkClipboard.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkComponentPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkFileDialogPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkFramePeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkGenericPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkImagePainter.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkLabelPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkListPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkMainThread.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkMenuBarPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkMenuItemPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkMenuPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkPanelPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkScrollPanePeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkTextAreaPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkTextComponentPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkTextFieldPeer.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkToolkit.h \
+$(top_srcdir)/include/gnu_java_awt_peer_gtk_GtkWindowPeer.h
+
+all: $(H_FILES)
+
+$(top_srcdir)/include/gnu_j

Re: Patch: Regenerate JNI headers automatically

[Thomas Fitzsimmons]

On Wed, 2003-07-23 at 13:23, Tom Tromey wrote:
> >>>>> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> 
> Tom> Currently the list consists of AWT-related headers.  Could someone who
> Tom> is more familiar with the other areas of classpath that require JNI
> Tom> headers complete the list?  Some headers should probably be removed.
> 
> This will get you a list:
> 
> find . -name '*.[ch]' -print | xargs egrep -h '#include.*_' | grep -v target_ | grep 
> -v native_state | grep -v libart_lgpl | sort -u
> 
> So it seems anyway.
> 

Ok, I added the targets that were missing.

> Tom> Mark Wielaard suggested that anyone checking in changes to these headers
> Tom> should use gcjh, since it is free and produces clean output.  If people
> Tom> agree with this, I will regenerate the AWT-headers and check them in.
> 
> I like this, but then I would.  One question is about gcjh version
> dependency.  Older versions of gcjh don't print JNICALL and JNIEXPORT
> stuff -- we want to make sure that everybody is using a new enough
> version.
> 
> I don't think this is that big a deal, since the target is optional
> and we're checking in the canonical headers.  It will only affect
> people who need to rebuild the headers and don't want to be bothered
> to find gcjh.  But if they just refrain from checking in their
> modified versions they can use whatever tool they like...
> 
> Tom> +[case "${enableval}" in
> Tom> +  yes) HEADER_DIR=include ;;
> Tom> +  no) HEADER_DIR="" ;;
> Tom> +  *) HEADER_DIR="" ;;
> Tom> +esac],
> Tom> +[HEADER_DIR=""])
> Tom> +AC_SUBST(HEADER_DIR)
> 
> It is somewhat more idiomatic to use an AM_CONDITIONAL and then just
> wrap the rules in include/ with `if condition...'.  One reason to do
> this is that otherwise other built files in include won't be correctly
> rebuilt by a simple "make" in the non-header-regenerate case.  (E.g.,
> if you touch jni.h.in, it should rebuild automatically...)
> 

Good point.  I used the existing CREATE_JNI_HEADERS (which was otherwise
unused).

> Tom> +$(top_srcdir)/include/gnu_java_awt_image_GdkPixbufDecoder.h: 
> $(top_srcdir)/gnu/java/awt/image/GdkPixbufDecoder.java
> Tom> +$(JAVAH) -o $@ $(shell basename $@ .h | tr '_' '.')
> 
> $(shell...) is a GNU make-ism.  Chances are that nobody will notice,
> but it is more portable to write out the name here.
> 

OK.

Thanks for the comments.

New patch attached,
Tom

2003-07-23  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* Makefile.am (SUBDIRS): Add include.
* configure.in: Add --enable-regen-headers flag.
(AC_OUTPUT): Add include/Makefile.
* include/Makefile.am: New file.

Index: Makefile.am
===
RCS file: /cvsroot/classpath/classpath/Makefile.am,v
retrieving revision 1.25
diff -u -b -B -r1.25 Makefile.am
--- Makefile.am	1 Feb 2003 12:54:05 -	1.25
+++ Makefile.am	23 Jul 2003 20:00:53 -
@@ -1,7 +1,7 @@
 ## Input file for automake to generate the Makefile.in used by configure
 
 # lib first, to compile .class files before native code
-SUBDIRS = lib doc gnu java javax native resource vm
+SUBDIRS = lib doc gnu java javax include native resource vm
 
 native: lib
 
Index: configure.in
===
RCS file: /cvsroot/classpath/classpath/configure.in,v
retrieving revision 1.127
diff -u -b -B -r1.127 configure.in
--- configure.in	16 Jul 2003 15:17:33 -	1.127
+++ configure.in	23 Jul 2003 20:00:54 -
@@ -70,11 +70,21 @@
 esac],
 [COMPILE_GTK_PEER=yes])
 
-AM_CONDITIONAL(CREATE_JNI_HEADERS, test "x${COMPILE_JNI}" = xyes) 
 AM_CONDITIONAL(CREATE_JNI_LIBRARIES, test "x${COMPILE_JNI}" = xyes)
 AM_CONDITIONAL(CREATE_CNI_LIBRARIES, test "x${COMPILE_CNI}" = xyes)
 AM_CONDITIONAL(CREATE_GTK_PEER_LIBRARIES, test "x${COMPILE_GTK_PEER}" = xyes)
 
+AC_ARG_ENABLE(regen-headers,
+[  --enable-regen-headers   automatically regenerate JNI headers [default=no]],
+[case "${enableval}" in
+  yes) REGENERATE_JNI_HEADERS=yes ;;
+  no) REGENERATE_JNI_HEADERS=no ;;
+  *) REGENERATE_JNI_HEADERS=no ;;
+esac],
+[REGENERATE_JNI_HEADERS=no])
+
+AM_CONDITIONAL(CREATE_JNI_HEADERS, test "x${REGENERATE_JNI_HEADERS}" = xyes)
+
 AC_PROG_LN_S
 AC_PROG_INSTALL
 
@@ -328,6 +338,7 @@
 gnu/javax/Makefile
 gnu/javax/rmi/Makefile
 gnu/javax/rmi/CORBA/Makefile
+include/Makefile
 include/jni.h
 java/Makefile
 java/applet/Makefile
Index: include/Makefile.am
===
RCS file: include/Makefile.am
diff -N include/Makefile.am
---

Re: gtk peers

[Thomas Fitzsimmons]

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, not sure about gcj.
> 

The build option is not in libgcj, but the ifdef'd code is.  libgcj
currently uses the ifdef branch that you want to remove, where
portable-native-sync is disabled.

I just tested the libgcj peers with the enable-portable-native-sync
ifdef branch, and I get thread initialization errors:

GThread-ERROR **: The supplied thread function vector is invalid.
aborting...
Aborted

I need to look at threading anyway for gcjwebplugin, so I'll try to
solve that problem.  For now though, we need to leave the ifdef as it
is.

Tom

-- 
Thomas Fitzsimmons <[EMAIL PROTECTED]>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: extended peers

[Thomas Fitzsimmons]

On Wed, 2003-09-10 at 01:36, graydon hoare wrote:

> I think these sort of changes will help manage the increasing variety
> of java2d implementations we are seeing. do they sound acceptable?
> 

Yes, this sounds like a good design.  Michael Koch and I did something
similar, but on a smaller scale, with the EmbeddedWindow class in
libgcj.  You may want to have a look at that.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Patch: Eliminate GTK peer compiler warnings

[Thomas Fitzsimmons]

Hello,

GCC emits many warnings when it is compiling the GTK peers.  Most of the
warnings are for unused parameters which must be present to satisfy JNI
and GTK interface requirements (e.g. the JNIEnv pointer and GTK callback
parameters).

This patch flags these parameters as "unused" using GCC's __attribute__
extension.  It provides a fall-back for compilers that don't support
attributes.  The patch also contains fixes that eliminate all other
compiler warnings in the GTK peers.

Any objections?

Tom

2003-10-07  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gnu/java/awt/peer/gtk/GtkMenuItemPeer.java (setEnabled): Stub
out.
* jni/classpath/jcl.c [!__GNUC__]: Elide __attribute__.
(JCL_free): Attach "unused" attribute to env parameter.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkChoicePeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkClipboard.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkComponentPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImagePainter.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkListPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkMainThread.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkMenuItemPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkMenuPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkTextComponentPeer.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c,
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c,
jni/gtk-peer/gthread-jni.c: Attach "unused" attribute to unused
parameters.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkClipboard.c:
(initNativeState): Pass 0 as info argument to
gtk_selection_add_target.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkComponentPeer.c:
(setVisible, gtkFixedNew, gtkFixedPut, gtkFixedMove): Remove
unused method implementations.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c
(awt_event_handler): Add break statement after default label.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImagePainter.c
(drawPixels): Remove unused variable i.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkMenuItemPeer.c
(setEnabled): Remove method implementation.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkMenuPeer.c
(accel_attach): Call _gtk_accel_group_attach with G_OBJECT
argument.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkPanelPeer.c (sr): Remove
unused function.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.c
(menu_pos): Assign TRUE to push_in.
(setupAccelGroup): Call _gtk_accel_group_attach with G_OBJECT
argument.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollPanePeer.c
(create): Remove unused variable layout.
* jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c (create):
Pass window_widget, rather than window, to
gtk_widget_set_size_request.
* jni/gtk-peer/gthread-jni.c (g_thread_jni_functions): Fill out
structure initialization with NULL values.
* jni/gtk-peer/gtkpeer.h [!__GNUC__]: Elide __attribute__.

Index: gnu/java/awt/peer/gtk/GtkMenuItemPeer.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/peer/gtk/GtkMenuItemPeer.java,v
retrieving revision 1.2
diff -u -r1.2 GtkMenuItemPeer.java
--- gnu/java/awt/peer/gtk/GtkMenuItemPeer.java	13 Jul 2003 15:09:20 -	1.2
+++ gnu/java/awt/peer/gtk/GtkMenuItemPeer.java	7 Oct 2003 23:01:15 -
@@ -85,7 +85,10 @@
 setEnabled (true);
   }
 
-  native public void setEnabled (boolean b);
+  public void setEnabled (boolean b)
+  {
+// do nothing, for now.
+  }
   native public void setLabel (String label);
 
   protected void postMenuActionEvent ()
Index: jni/classpath/jcl.c
===
RCS file: /cvs/gcc/gcc/libjava/jni/classpath/jcl.c,v
retrieving revision 1.1
diff -u -r1.1 jcl.c
--- jni/classpath/jcl.c	31 Jan 2003 17:54:14 -	1.1
+++ jni/classpath/jcl.c	7 Oct 2003 23:01:16 -
@@ -39,6 +39,10 @@
 #include 
 #include 
 
+#ifndef __GNUC__
+#define __attribute__(x) /* nothing */
+#endif
+
 static char errstr[4098]; // this way the memory is pre-allocated, so that we do not have to worry if we are out of memory.
 
 JNIEXPORT void JNICALL JCL_ThrowException(JNIEnv * env, char * className, char * errMsg) {
@@ -85,7 +89,9 @@
   return(ptr);
 }
 
-JNIEXPORT void JNICALL JCL_free(JNIEnv * env, void * p) {
+JNIEXPORT void JNICALL JCL_free(JNIEnv * env __attribute__((unused)),
+void * p)
+{
 	if(p != NULL) {
 		free(p);
 	}
Index: jni/gtk-peer/gnu_java_awt_peer_gtk_GtkChoicePeer.c
===
RCS file: /cvs/gcc/gcc/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkChoicePeer.c,v
retrieving revision 1.1
diff -u -r1.1 gnu_java

Re: CVS configure.in is broken

[Thomas Fitzsimmons]

On Fri, 2003-10-24 at 04:31, Dalibor Topic wrote:
> Mark Wielaard wrote:
> > Hi,
> > 
> > On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote:
> > 
> >>apparently the configure.in in CVs is broken. I tried the
> >>aclocal; autoheader; automake; autoconf
> >>routine as recommended in the HACKING document, but it doesn't work: 
> >>aclocal complains about
> >>
> >>aclocal: configure.in: 134: macro `AM_PATH_GTK_2_0' not found in library
> >>aclocal: configure.in: 137: macro `AM_PATH_GLIB_2_0' not found in library
> >>aclocal: configure.in: 140: macro `AM_PATH_LIBART' not found in library
> >>
> >>and it's all down from there ;)
> > 
> > 
> > Also from the HACKING document:
> > 
> > the following are required.
> >  
> > - GTK+ 2.x.x
> > - libart_lgpl 2.1.0
> > 
> > Those packages should provide the missing AM_ macros.
> 
> Not in my HACKING document ;) There is says:
> 
> For building the JNI native libraries, the following are required.
> 
>  - GTK+ 2.x.x
>  - libart_lgpl 2.1.0
>  - gdk-pixbuf (Only needed if you want to compile the native 
> library)
> 
> But as I don't want to build the JNI libraries, I figured I wouldn't 
> need it ;)
> 
> Anyway, thanks, I'll fetch them just for the macros. Any idea where the 
> macros hide in those packages?
> 

They're defined in gtk-2.0.m4, glib-2.0.m4 and libart.m4.

> Stupid question no 2: why aren't those macros in the CVS archive? They 
> are not generated files, as far as I can tell. Installing gtk2, glib2 
> and libart just to be able to compile Classpath's java classes with 
> jikes seems like a bit of overkill ;)

Yes, I agree.  We should probably just check the macro files into
Classpath's top-level directory.  That's what we've done with libgcj. 
We should also update the HACKING file to recommend

aclocal -I .

That should solve the problem.

Tom

> 
> cheers,
> dalibor topic
> 
> 
> 
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Patch: image loading fixes

[Thomas Fitzsimmons]

Hi,

This patch fixes various problems related to image loading.  It also
implements Component.imageUpdate, GtkToolkit.prepareImage and the
byte-array GtkToolkit.createImage method.

Comments?

Tom

2003-11-06  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* Makefile.am: Add GdkPixbufDecoder.java and
gnu_java_awt_peer_gtk_GdkPixbufDecoder.c
* Makefile.in: Regenerate.
* gnu/java/awt/image/ImageDecoder.java (ImageDecoder(byte[],int,int)):
New constructor.
(startProduction): Create ByteArrayInputStream when url and filename
are
null.
(produce): Declare stream parameter as InputStream.
* gnu/java/awt/image/XBMDecoder.java (produce): Declare stream
parameter
as InputStream.
* gnu/java/awt/peer/gtk/GdkPixbufDecoder.java
(GdkPixbufDecoder(byte[],int,int)): New constructor.
(produce): Declare stream parameter as InputStream.
* gnu/java/awt/peer/gtk/GtkComponentPeer.java (prepareImage): Throw NPE
if image is null.  Set image's observer before running PrepareImage
thread.  Pass image to startProduction.
* gnu/java/awt/peer/gtk/GtkImage.java: Add null checks before calls to
source's member functions.
(observer): New field.
(setObserver): New method.
(setDimensions, setPixels, imageComplete): Call observer's imageUpdate.
* gnu/java/awt/peer/gtk/GtkToolkit.java (checkImage, getImage): Return
new GtkImage.
(prepareImage): Implement.
* java/awt/Component.java (imageUpdate): Implement.
(createImage): Call Toolkit's createImage if peer is null.
(prepareImage): Throw NPE if image is null.
* java/awt/MediaTracker.java: Fix return value.

Index: Makefile.am
===
RCS file: /cvs/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.334
diff -u -r1.334 Makefile.am
--- Makefile.am	29 Oct 2003 16:07:58 -	1.334
+++ Makefile.am	6 Nov 2003 19:46:29 -
@@ -170,6 +170,7 @@
 gtk_c_source_files = \
 jni/gtk-peer/gnu_java_awt_peer_gtk_GdkFontMetrics.c \
 jni/gtk-peer/gnu_java_awt_peer_gtk_GdkGraphics.c \
+jni/gtk-peer/gnu_java_awt_peer_gtk_GdkPixbufDecoder.c \
 jni/gtk-peer/gnu_java_awt_peer_gtk_GtkButtonPeer.c \
 jni/gtk-peer/gnu_java_awt_peer_gtk_GtkCanvasPeer.c \
 jni/gtk-peer/gnu_java_awt_peer_gtk_GtkCheckboxMenuItemPeer.c \
@@ -206,6 +207,7 @@
 gtk_awt_peer_sources = \
 gnu/java/awt/peer/gtk/GdkFontMetrics.java \
 gnu/java/awt/peer/gtk/GdkGraphics.java \
+gnu/java/awt/peer/gtk/GdkPixbufDecoder.java \
 gnu/java/awt/peer/gtk/GtkArg.java \
 gnu/java/awt/peer/gtk/GtkArgList.java \
 gnu/java/awt/peer/gtk/GtkButtonPeer.java \
Index: gnu/java/awt/image/ImageDecoder.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/image/ImageDecoder.java,v
retrieving revision 1.1
diff -u -r1.1 ImageDecoder.java
--- gnu/java/awt/image/ImageDecoder.java	9 Aug 2002 04:32:43 -	1.1
+++ gnu/java/awt/image/ImageDecoder.java	6 Nov 2003 19:46:31 -
@@ -48,6 +48,10 @@
   Vector consumers = new Vector ();
   String filename;
   URL url;
+  byte[] data;
+  int offset;
+  int length;
+  InputStream input;
 
   public static ColorModel cm;
 
@@ -69,6 +73,13 @@
 this.url = url;
   }
 
+  public ImageDecoder (byte[] imagedata, int imageoffset, int imagelength)
+  {
+data = imagedata;
+offset = imageoffset;
+length = imagelength;
+  }
+
   public void addConsumer (ImageConsumer ic) 
   {
 consumers.addElement (ic);
@@ -90,11 +101,22 @@
 Vector list = (Vector) consumers.clone ();
 try 
   {
-	FileInputStream is = (url == null) ? new FileInputStream (filename) :
-	  (FileInputStream) url.openStream();
-		  
-	produce (list, is);
-  } 
+	// Create the input stream here rather than in the
+	// ImageDecoder constructors so that exceptions cause
+	// imageComplete to be called with an appropriate error
+	// status.
+	if (url != null)
+	  input = url.openStream();
+	else
+	  {
+	if (filename != null)
+	  input = new FileInputStream (filename);
+	else
+	  input = new ByteArrayInputStream (data, offset, length);
+	  }
+
+	produce (list, input);
+  }
 catch (Exception e)
   {
 	for (int i = 0; i < list.size (); i++)
@@ -109,5 +131,5 @@
   { 
   }
 
-  abstract void produce (Vector v, FileInputStream is) throws IOException;
+  abstract void produce (Vector v, InputStream is) throws IOException;
 }
Index: gnu/java/awt/image/XBMDecoder.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/image/XBMDecoder.java,v
retrieving revision 1.1
diff -u -r1.1 XBMDecoder.java
--- gnu/java/awt/image/XBMDecoder.java	9 Aug 2002 04:32:43 -	1.1
+++ gnu/java/awt/image/XBMDecoder.java	6 Nov 2003 19:46:31 -
@@ -62,7 +62,7 @@
 super (url);
   }
 
-  

Re: Patch: image loading fixes

[Thomas Fitzsimmons]

On Fri, 2003-11-07 at 15:00, Tom Tromey wrote:
> >>>>> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> 
> Tom> This patch fixes various problems related to image loading.  It also
> Tom> implements Component.imageUpdate, GtkToolkit.prepareImage and the
> Tom> byte-array GtkToolkit.createImage method.
> 
> Looks good.
> 
> Tom> -// FIXME - gcj local: GdkPixbufDecoder doesn't work.
> Tom> -// return new GtkImage (new GdkPixbufDecoder (filename), null);
> Tom> -return null;
> Tom> +return new GtkImage (new GdkPixbufDecoder (filename), null);
> 
> I don't remember why I commented out this code in libgcj, other than
> what the comment says.  I assume it is ok to enable now?
> 

Yes, we can remove these FIXMEs since Graydon fixed GdkPixbufDecoder.

> Tom> +boolean incrementalDraw = Boolean.getBoolean ("awt.image.incrementalDraw");
> Tom> +Long redrawRate = Long.getLong ("awt.image.redrawrate");
> 
> Should these be computed once, at class init time?

Yes, looking again, I think they should.

> Or do we want to recompute them each time this method is called?
> 
> Also, I forget where and how we're documenting properties we
> recognize.  I know this has come up before though.  These two should
> at least be mentioned in the javadoc for the method.
> 

Yup, they're already mentioned in the existing javadoc.

Are the attached changes to Component.java ok?  If so, I'll check them
in along with the rest of the patch.

Tom

Index: java/awt/Component.java
===
RCS file: /cvs/gcc/gcc/libjava/java/awt/Component.java,v
retrieving revision 1.29
diff -u -r1.29 Component.java
--- java/awt/Component.java	20 Sep 2003 21:30:39 -	1.29
+++ java/awt/Component.java	11 Nov 2003 21:22:58 -
@@ -555,6 +555,17 @@
*/
   transient BufferStrategy bufferStrategy;
 
+  /**
+   * The system properties that affect image updating.
+   */
+  transient private static boolean incrementalDraw;
+  transient private static Long redrawRate;
+
+  static
+  {
+incrementalDraw = Boolean.getBoolean ("awt.image.incrementalDraw");
+redrawRate = Long.getLong ("awt.image.redrawrate");
+  }
 
   // Public and protected API.
 
@@ -1832,7 +1843,9 @@
* @param y the Y coordinate
* @param w the width
* @param h the height
-   * @return true if the image has been fully loaded
+   * @return false if the image is completely loaded, loading has been
+   * aborted, or an error has occurred.  true if more updates are
+   * required.
* @see ImageObserver
* @see Graphics#drawImage(Image, int, int, Color, ImageObserver)
* @see Graphics#drawImage(Image, int, int, ImageObserver)
@@ -1842,8 +1855,24 @@
*/
   public boolean imageUpdate(Image img, int flags, int x, int y, int w, int h)
   {
-// XXX Implement.
-throw new Error("not implemented");
+if ((flags & (FRAMEBITS|ALLBITS)) != 0)
+  repaint ();
+else if ((flags & SOMEBITS) != 0)
+  {
+	if (incrementalDraw)
+	  {
+	if (redrawRate != null)
+	  {
+		long tm = redrawRate.longValue();
+		if (tm < 0)
+		  tm = 0;
+		repaint (tm);
+	  }
+	else
+	  repaint (100);
+	  }
+  }
+return (flags & (ALLBITS|ABORT|ERROR)) == 0;
   }
 
   /**
@@ -1854,8 +1883,11 @@
*/
   public Image createImage(ImageProducer producer)
   {
-// XXX What if peer or producer is null?
-return peer.createImage(producer);
+// Sun allows producer to be null.
+if (peer != null)
+  return peer.createImage(producer);
+else
+  return getToolkit().createImage(producer);
   }
 
   /**
@@ -1930,6 +1962,9 @@
*/
   public boolean prepareImage(Image image, ImageObserver observer)
   {
+if (image == null)
+  throw new NullPointerException ();
+
 return prepareImage(image, image.getWidth(observer),
 image.getHeight(observer), observer);
   }
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

PixelGrabber fixes

[Thomas Fitzsimmons]

Hello,

This patch completes the PixelGrabber implementation, updates its
javadocs and includes a mauve test case.

OK to commit?

Tom

2003-11-24  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

* gnu/java/awt/peer/gtk/GtkImage.java (setDimensions,
setProperties): Check that io is not null before calling
io.imageUpdate.
* java/awt/image/ImageConsumer.java (setPixels, imageComplete):
Update javadocs.
* java/awt/image/PixelGrabber.java: Fix implementation and
update javadocs.

Index: gnu/java/awt/peer/gtk/GtkImage.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/peer/gtk/GtkImage.java,v
retrieving revision 1.3
diff -u -r1.3 GtkImage.java
--- gnu/java/awt/peer/gtk/GtkImage.java	12 Nov 2003 00:37:33 -	1.3
+++ gnu/java/awt/peer/gtk/GtkImage.java	25 Nov 2003 03:59:01 -
@@ -1,5 +1,5 @@
 /* GtkImage.java
-   Copyright (C) 1999, 2002 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2002, 2003 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -168,13 +168,15 @@
 for (int i = 0; i < widthObservers.size (); i++)
   {
 	ImageObserver io = (ImageObserver) widthObservers.elementAt (i);
-	io.imageUpdate (this, ImageObserver.WIDTH, -1, -1, width, height);
+	if (io != null)
+	  io.imageUpdate (this, ImageObserver.WIDTH, -1, -1, width, height);
   }
 
 for (int i = 0; i < heightObservers.size (); i++)
   {
 	ImageObserver io = (ImageObserver) heightObservers.elementAt (i);
-	io.imageUpdate (this, ImageObserver.HEIGHT, -1, -1, width, height);
+	if (io != null)
+	  io.imageUpdate (this, ImageObserver.HEIGHT, -1, -1, width, height);
   }
 
 if (observer != null)
@@ -192,7 +194,8 @@
 for (int i = 0; i < propertyObservers.size (); i++)
   {
 	ImageObserver io = (ImageObserver) propertyObservers.elementAt (i);
-	io.imageUpdate (this, ImageObserver.PROPERTIES, -1, -1, width, height);
+	if (io != null)
+	  io.imageUpdate (this, ImageObserver.PROPERTIES, -1, -1, width, height);
   }
   }
 
Index: java/awt/image/ImageConsumer.java
===
RCS file: /cvs/gcc/gcc/libjava/java/awt/image/ImageConsumer.java,v
retrieving revision 1.6
diff -u -r1.6 ImageConsumer.java
--- java/awt/image/ImageConsumer.java	11 Oct 2003 17:19:46 -	1.6
+++ java/awt/image/ImageConsumer.java	25 Nov 2003 03:59:01 -
@@ -1,5 +1,5 @@
 /* ImageConsumer.java -- Java interface for image consumption
-   Copyright (C) 1999 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2003 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -160,17 +160,45 @@
 void setHints(int flags);
 
 /**
- * This function delivers a rectangle of pixels where any
- * pixel(m,n) is stored in the array as a byte at
- * index (n * scansize + m + offset).  
+ * Deliver a subset of an ImageProducer's pixels to this ImageConsumer.
+ *
+ * Each element of the pixels array represents one pixel.  The
+ * pixel data is formatted according to the color model model.
+ * The x and y parameters are the coordinates of the block of
+ * pixels being delivered to this ImageConsumer.  They are
+ * specified relative to the top left corner of the image being
+ * produced.  Likewise, w and h are the pixel block's dimensions.
+ *
+ * @param x x coordinate of pixel block
+ * @param y y coordinate of pixel block
+ * @param w width of pixel block
+ * @param h height of pixel block
+ * @param model color model used to interpret pixel data
+ * @param pixels pixel block data
+ * @param offset offset into pixels array
+ * @param scansize width of one row in the pixel block
  */
 void setPixels(int x, int y, int w, int h, 
 	   ColorModel model, byte[] pixels, int offset, int scansize);
 
 /**
- * This function delivers a rectangle of pixels where any
- * pixel(m,n) is stored in the array as an int at
- * index (n * scansize + m + offset).  
+ * Deliver a subset of an ImageProducer's pixels to this ImageConsumer.
+ *
+ * Each element of the pixels array represents one pixel.  The
+ * pixel data is formatted according to the color model model.
+ * The x and y parameters are the coordinates of the rectangular
+ * region of pixels being delivered to this ImageConsumer,
+ * specified relative to the top left corner of the image being
+ * produced.  Likewise, w and h are the pixel region's dimensions.
+ *
+ * @param x x coordinate of pixel block
+ * @param y y coordinate of pixel block
+ * @param w width of pixel block
+ * @param h height of pixel block
+ * @param model color model used to interpret pixel data
+ * @param pixels pixel block data
+ * @param offset offset into pixels array
+ * @param scansize width of one row in

Re: [PATCH] enable Graphics2D at configure and runtime

[Thomas Fitzsimmons]

On Wed, 2003-12-17 at 09:41, graydon hoare wrote:
> hi,
> 
> this patch provides a new bit of configury (--enable-gtk-cairo) and a 
> runtime system property ("gnu.java.awt.peer.gtk.Graphics" == "Graphics" 
> or "Graphics2D") which permits the cairo/graphics2d code I've been 
> working on to coexist with the existing GTK peers and GDK Graphics 
> object, as an option at both compile and runtime.
> 
> I'm sure there'll be a few suggestions about how "best" to do this, so I 
> just picked what seemed like an unintrusive method and implemented it, 
> to make sure it's even possible. any suggestions on how to do it better?
> 

Nope, I think this approach is good.

A few comments:

> +dnl determine whether to enable the cairo GTK Graphics2D backend
> +AC_ARG_ENABLE(gtk-cairo, [  --enable-gtk-cairo   build the cairo Graphics2D 
> implementation on GTK])
> +AM_CONDITIONAL(GTK_CAIRO, test "x${enable_gtk_cairo}" = xyes)
> +if test "x${enable_gtk_cairo}" = xyes
> +then
> + AC_CHECK_LIB([cairo], [cairo_create])
> + AC_CHECK_LIB([pixman], [pixman_region_create])
> + if (echo $LIBS | grep -v -q cairo) || (echo $LIBS | grep -v -q pixman)
> + then
> + AC_MSG_ERROR(need both libcairo and libpixman for cairo support)
> + fi

I've got cairo installed in a non-standard prefix, and AC_CHECK_LIB
doesn't seem to like this (even when LD_LIBRARY_PATH is set to
$(nonstandardprefix)/lib).  Can we use PKG_CHECK_MODULES here instead? 
(We should be using PKG_CHECK_MODULES for GTK, GLib and libart as well,
I think).

> +  public static boolean useGraphics2D()
> +  {
> +if (useGraphics2dSet)
> +  return useGraphics2d;
> +useGraphics2d = System.getProperty("gnu.java.awt.peer.gtk.Graphics", 
> +   "Graphics").equals("Graphics2D");
> +useGraphics2dSet = true;
> +  }

There should be a return statement here.

> +  /* newer method to produce a peer for a Font object, even though Sun's
> + design claims Font should now be peerless, we do not agree with this
> + model, hence "ClasspathFontPeer". */
> +
> +  public ClasspathFontPeer getClasspathFontPeer (String name, Map attrs)
> +  {
> +if (useGraphics2D)

This should be useGraphics2d.

I tested this patch, and apart from the problems I mentioned, it works
well.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [PATCH] enable Graphics2D at configure and runtime

[Thomas Fitzsimmons]

On Thu, 2003-12-18 at 17:30, Thomas Fitzsimmons wrote:
> > +  /* newer method to produce a peer for a Font object, even though Sun's
> > + design claims Font should now be peerless, we do not agree with this
> > + model, hence "ClasspathFontPeer". */
> > +
> > +  public ClasspathFontPeer getClasspathFontPeer (String name, Map attrs)
> > +  {
> > +if (useGraphics2D)
> 
> This should be useGraphics2d.
> 

Err, useGraphics2D (). :-)

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

jhbuild and classpath

[Thomas Fitzsimmons]

Hi James,

I've been experimenting with using jhbuild for GNU Classpath
development.  My compliments on jhbuild; it's a very nice tool!

Our AWT implementation relies on GTK, so jhbuild is a natural fit for
us.  And it looks like jhbuild has the potential to make bootstrapping a
Classpath-based development environment dramatically simpler.

I've run into one problem though.  In the GNU Classpath world, we prefer
to have builddir != srcdir, whereas it seems most GNOME modules, and
hence jhbuild, assume builddir == srcdir.  What do you think about
having a builddir != srcdir mode that could be set in .jhbuildrc?

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: jhbuild and classpath

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 06:13, James Henstridge wrote:
> On 5/04/2004 6:22 AM, Thomas Fitzsimmons wrote:
> 
> >Hi James,
> >
> >I've been experimenting with using jhbuild for GNU Classpath
> >development.  My compliments on jhbuild; it's a very nice tool!
> >  
> >
> Cool.  I put a fair bit of work into making jhbuild usable outside of 
> Gnome (primarily for some of the freedesktop.org projects such as the X 
> server), so it'll be good if it benefits you too.
> 
> If you use a URL for the module set in ~/.jhbuildrc, jhbuild should 
> download and cache the module information from
> 

Oh, cool!  I was going to submit classpath.modules for inclusion in the
jhbuild repository, but hosting it at a URL is much better.

> >Our AWT implementation relies on GTK, so jhbuild is a natural fit for
> >us.  And it looks like jhbuild has the potential to make bootstrapping a
> >Classpath-based development environment dramatically simpler.
> >
> >I've run into one problem though.  In the GNU Classpath world, we prefer
> >to have builddir != srcdir, whereas it seems most GNOME modules, and
> >hence jhbuild, assume builddir == srcdir.  What do you think about
> >having a builddir != srcdir mode that could be set in .jhbuildrc?
> >  
> >
> Shouldn't be too difficult to implement.  What layout do you use for 
> your source/build trees in this setup?
> 

Usually we keep the build directory completely separate.  For example, I
have ~/sources and ~/build directories.

Ideally the layout would look like this:

~/sources/jhbuild-src/jhbuild
~/sources/jhbuild-src/module1
~/sources/jhbuild-src/module2
...


~/build/jhbuild-bld/module1-bld
~/build/jhbuild-bld/module2-bld
...


I like to append -bld to the build directories so that I can easily
differentiate them from the corresponding source directories.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.ColorModel

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 07:11, Ingo PrÃtel wrote:
> I suggest the following patch
> 
> 2004-04-05  Ingo Proetel <[EMAIL PROTECTED]>
> 
>   * java/awt/image/ColorModel.java (getRGBdefault): Default ColorModel has 32 
> bit pixels not 8 bit 
> pixels.
>   (isCompatibleRaster): Added javadoc comment.
> 
> ingo


> -  // Typically overridden
> +  /**
> +   * Checks if the given raster has a compatible data-layout
> (SampleModel).
> +   * @param raster The Raster to test.
> +   * @return true if raster is compatible.
> +   */ 

This implementation is different from the description in Sun's
javadocs.  Their default implementation is to throw an
UnsupportedOperationException, since ColorModel is an abstract class. 
Does the implementation here need to be moved into one of the derived
classes?

>public boolean isCompatibleRaster(Raster raster)
>{
>  SampleModel sampleModel = raster.getSampleModel();

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.Raster

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 11:06, Ingo PrÃtel wrote:
> Note new attachment.
> 
> Ingo PrÃtel wrote:
> > I suggest the following patch
> > 2004-04-05  Ingo Proetel  <[EMAIL PROTECTED]>
> > 
> > * java/awt/image/Raster.java (toString): Added method.
> > 
> > ingo
> > 
> > 

+  
+  /**
+   * Create a String representing the stat of this Raster.
   ^
   state?

+   * @return A String representing the stat of this Raster.
+   * @see java.lang.Object#toString()
+   */
+  public String toString()
+  {
+StringBuffer result = new StringBuffer();
+
+result.append(getClass().getName());
+result.append("[(");
+result.append(minX).append(",").append(minY).append("), ");
+result.append(width).append(" x ").append(height).append(",");
+result.append(sampleModel).append(",");
+result.append(dataBuffer);
+result.append("]");
+

Is this result in the same format as the result produced by Sun's
Raster.toString? 

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.Raster

[Thomas Fitzsimmons]

On Tue, 2004-04-06 at 13:13, Ingo PrÃtel wrote:
> Thomas Fitzsimmons wrote:
> > On Mon, 2004-04-05 at 11:06, Ingo PrÃtel wrote:
> > 
> >>Note new attachment.
> >>
> >>Ingo PrÃtel wrote:
> >>
> >>>I suggest the following patch
> >>>2004-04-05  Ingo Proetel  <[EMAIL PROTECTED]>
> >>>
> >>>* java/awt/image/Raster.java (toString): Added method.
> >>>
> >>>ingo
> >>>
> >>>
> > 
> > 
> > +  
> > +  /**
> > +   * Create a String representing the stat of this Raster.
> >^
> >state?
> > 
> > +   * @return A String representing the stat of this Raster.
> > +   * @see java.lang.Object#toString()
> > +   */
> > +  public String toString()
> > +  {
> > +StringBuffer result = new StringBuffer();
> > +
> > +result.append(getClass().getName());
> > +result.append("[(");
> > +result.append(minX).append(",").append(minY).append("), ");
> > +result.append(width).append(" x ").append(height).append(",");
> > +result.append(sampleModel).append(",");
> > +result.append(dataBuffer);
> > +result.append("]");
> > +
> > 
> > Is this result in the same format as the result produced by Sun's
> > Raster.toString? 
> > 
> > Tom
> > 
> Actually, I don't know. The doc says Raster does not overwrite the toString method. 
> So I guess it 
> looks different. I just found it helpful to debug.

OK.  We may want to change it later to match Sun's output for
mauve/testing purposes, but for now this is fine.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.SinglePixelPackedSampleModel

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 08:03, Ingo PrÃtel wrote:
> I suggest the following patch
> 
> 2004-04-05  Ingo Proetel  <[EMAIL PROTECTED]>
> 
>   * java/awt/image/SinglePixelPackedSampleModel.java (getDataElements): New 
> method.
>   (setDataElements): New method.
>   (setPixels): New method.
>   (toString): New method.
> 
> ingo

This looks great.

Thanks!
Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.ComponentSampleModel

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 11:02, Ingo PrÃtel wrote:
> Note new attachment.
> 
> Ingo PrÃtel wrote:
> > I suggest the following patch:
> > 
> > 2004-04-05  Ingo Proetel  <[EMAIL PROTECTED]>
> > 
> > * java/awt/image/ComponentSampleModel.java (setDataSamples):Do not 
> > reset scanline stride.
> > 
> >


>  if (scanlineStride == rowSize)
>{
> // Collapse scan lines:
> -   scanlineStride = rowSize *= h;
> +   rowSize *= h;
> h = 1;
>}

Can you accompany your patches with a description of the problem they
solve?  What's the rationale for this change?

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.image.SampleModel

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 10:59, Ingo PrÃtel wrote:
> Note new attachment.


> Index: java/awt/image/SampleModel.java
> ===
> RCS file: /cvsroot/classpath/classpath/java/awt/image/SampleModel.java,v
> retrieving revision 1.2
> diff -u -r1.2 SampleModel.java
> --- java/awt/image/SampleModel.java 22 Jan 2002 22:26:59 -  1.2
> +++ java/awt/image/SampleModel.java 5 Apr 2004 14:57:53 -
> @@ -58,7 +58,9 @@
>  
>public SampleModel(int dataType, int w, int h, int numBands)
>{
> -if ((w<=0) || (h<=0)) throw new IllegalArgumentException();
> +if ((w<=0) || (h<=0)) 
> +  throw new IllegalArgumentException( (w<=0?" width<=0":" width is ok")
> + +(h<=0?" height<=0":" height is ok"));

This patch is fine, except for the formatting.  The GNU coding style
that Classpath uses mandates that there should always be spaces between
operators and their operands.

(w<=0?" width<=0":" width is ok")

should be:

(w <= 0 ? " width<=0" : " width is ok")

Thanks,
Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch for java.awt.Polygon

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 10:57, Ingo PrÃtel wrote:
> Let try this again with the correct attachment.
> 

Looks good.

Thanks,
Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Patch to implement ColorGraphicsContext

[Thomas Fitzsimmons]

On Mon, 2004-04-05 at 08:59, Ingo PrÃtel wrote:
> I suggest the following patch
> 2004-04-05  Ingo Proetel  <[EMAIL PROTECTED]>
> 
>   * java/awt/ColorPaintContext.java (): Added ColorModel to signature.
>   (getColorModel): Return the actual color model.
>   (getRaster): Implemented.
>   (ColorRaster): New inner class.
>   * java/awt/SystemColor.java (createContext): Use ColorModel when creating
>   a PaintContext.
>   * java/awt/Color.java (): Make exception more verbose.
>   (createContext): Use ColorModel when creating a PaintContext.
>   
> 
> ingo


> Index: java/awt/ColorPaintContext.java
> ===
> RCS file:
> /cvsroot/classpath/classpath/java/awt/ColorPaintContext.java,v
> retrieving revision 1.1
> diff -u -r1.1 ColorPaintContext.java
> --- java/awt/ColorPaintContext.java 8 May 2002 03:07:24
> -   1.1
> +++ java/awt/ColorPaintContext.java 5 Apr 2004 12:43:00 -
> @@ -39,7 +39,13 @@
>  package java.awt;
>  
>  import java.awt.image.ColorModel;
> +import java.awt.image.DataBuffer;
> +import java.awt.image.DataBufferByte;
> +import java.awt.image.DataBufferInt;
> +import java.awt.image.DataBufferUShort;
>  import java.awt.image.Raster;
> +import java.awt.image.SampleModel;
> +import java.util.Arrays;
>  
>  /**
>   * This class provides a paint context which will fill a rectanglar
> region of
> @@ -55,15 +61,19 @@
> * SystemColor.
> */
>final int color;
> +  final ColorModel colorModel;
>  
> +  private ColorRaster mCachedRaster;
> + 

We don't use the 'm' prefix on fields.

>/**
> * Create the context for a given color.
> *
> * @param c the solid color to use
> */
> -  ColorPaintContext(int c)
> +  ColorPaintContext(ColorModel cm,int c)

You should probably create a new constructor (that uses the previous
default colour model), rather than changing the old one.  Color.java,
for example, calls ColorPaintContext(int c).

>{
>  color = c;
> +colorModel = cm;
>}
>  
>/**
> @@ -75,14 +85,13 @@
>}
>  
>/**
> -   * Return the color model of this context. This ignores the model
> passed
> -   * in the request, since colors are always in sRGB.
> +   * Return the color model of this context. 
> *
> * @return the context color model
> */
>public ColorModel getColorModel()
>{
> -return ColorModel.getRGBdefault();
> +return colorModel;
>}
>  
>/**
> @@ -96,8 +105,71 @@
> */
>public Raster getRaster(int x, int y, int w, int h)
>{
> -// XXX Implement. Sun uses undocumented implementation class
> -// sun.awt.image.IntegerInterleavedRaster.
> -throw new Error("not implemented");
> +   if(  mCachedRaster == null 
> +   || mCachedRaster.getWidth() < w
> +   || mCachedRaster.getHeight() < h)
> +{
> + mCachedRaster = new ColorRaster(colorModel, 0, 0, w, h, color);
> +}
> +   return mCachedRaster.createChild(0,0,w,h,x,y,null);

   

Arguments should be separated by spaces.

>}
> +  
> +  private class ColorRaster extends Raster{
> +  
> +/**
> + * 
> + * @param cm
> + * @param rgbPixel
> + */
> +ColorRaster(ColorModel cm,int x, int y, int width, int
> height, int rgbPixel)
> +{ 
> +  super(cm.createCompatibleSampleModel(width,height),new
> Point(x,y));
> +  Object pixel = cm.getDataElements(rgbPixel,null);
> +  getSampleModel().setDataElements(0,
> 0,width,height,multiplyData(pixel,null,width*height),dataBuffer);


Lines should be no more than 80 characters long, so lines like this need
to be wrapped.


> +}
> +   
> +
> +
> +private Object multiplyData(Object src, Object dest, int
> factor)
> +{
> +  Object from;
> +  int srcLength = 0;
> +  if (src instanceof byte[])
> +   {
> +srcLength = ((byte[])src).length;
> +
> +if (dest == null) dest = new byte[factor * srcLength];
> +  }
> +  else if (src instanceof short[])
> +   {
> +srcLength = ((short[])src).length;
> +if (dest == null) dest = new short[factor * srcLength];
> +  }
> +  else if (src instanceof int[])
> +   {
> +srcLength = ((int[]) src).length;
> +if (dest == null) dest = new int[factor * srcLength];
> +  }
> +  else
> +   {
> +throw new ClassCastException("Unknown data buffer type");
> +  }
> +
> +  System.arraycopy(src,0,dest,0,srcLength);
> +  
> +  int count = 1;
> +  while(count*2 < factor)
> +  {
> +System.arraycopy(dest, 0, dest, count * srcLength,
> count*srcLength);
> +count *= 2; 
> +  }
> +  
> +  if(factor > 

Re: JamVM 1.1.3 released

[Thomas Fitzsimmons]

On Tue, 2004-04-13 at 11:04, Robert Lougher wrote:
> Hi Sascha,
> 
> Yes, I know :)  I couldn't decide whether it was a good idea to slavishly 
> follow Sun's options or not. The -X (as you're obviously aware) means 
> "non-standard options", and includes -Xms and -Xmx which I also do not have 
> an X in front of (as used to be in JDK 1.1.x).  Also, on Sun's VM, 
> -classpath is specified as -classpath xxx:yyy whereas -Xbootclasspath is 
> -Xbootclasspath:xxx:yyy which is (in my mind anyway) confusing.  On JamVM 
> it's -bootclasspath xxx:yyy (added in 1.1.1), so I'd have had to change that 
> as well.
> 
> CC'ing to the mailing list, as I'm interested in other people's opinions on 
> this!
> 

I'd prefer that JamVM slavishly follow the options provided by Sun's
latest released java command.  There may be many scripts and tools that
assume e.g. the -Xbootclasspath:xxx:yyy syntax.  I think drop-in
compatibility is more important than a self-consistent set of
command-line options.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: AWT regression?

[Thomas Fitzsimmons]

On Sat, 2004-04-24 at 18:52, Grzegorz B. Prokopski wrote:
> Hi all,
> 
> We've just imported fresh GNU CP as of Fri Apr 23 and running SymbolTest
> program, that previously worked nicely, as documented ex. at
> http://www.sablevm.org/screenshots , now gives this:
> 
> $ ~/work/bin/java-sablevm SymbolTest 
> (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
>   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
> (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
>   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
> (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
>   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
>  java.lang.NullPointerException
> at java.applet.Applet.getDimensions (Applet.java:469)
> at java.applet.Applet.preferredSize (Applet.java:486)
> at java.awt.Container.getPreferredSize (Container.java:576)
> at java.awt.BorderLayout.calcCompSize (BorderLayout.java:647)
> at java.awt.BorderLayout.calcSize (BorderLayout.java:692)
> at java.awt.BorderLayout.preferredLayoutSize (BorderLayout.java:454)
> at java.awt.Container.preferredSize (Container.java:589)
> at java.awt.Container.getPreferredSize (Container.java:576)
> at java.awt.Window.pack (Window.java:206)
> at SymbolTest.main (SymbolTest.java:100)
> at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
> at java.lang.VirtualMachine.main (VirtualMachine.java:88)
> 

I recently changed size reporting in Applet.java.  I made applets report
their preferred size as the width and height attributes given in the
applet tag.  However, the current code assumes that an applet stub is
present that can be queried for these attributes.  The NPE you're seeing
is likely caused by the stub not having been set.

The attached patch should fix the problem, though I haven't tested it. 
Can you try it out?

Thanks,
Tom

Index: java/applet/Applet.java
===
RCS file: /cvs/gcc/gcc/libjava/java/applet/Applet.java,v
retrieving revision 1.3.36.3
diff -u -r1.3.36.3 Applet.java
--- java/applet/Applet.java	16 Mar 2004 04:43:35 -	1.3.36.3
+++ java/applet/Applet.java	28 Apr 2004 16:35:36 -
@@ -483,7 +483,7 @@
*/
   public Dimension preferredSize()
   {
-return getDimensions ();
+return stub == null ? super.preferredSize () : getDimensions ();
   }
 
   /**
@@ -494,7 +494,7 @@
*/
   public Dimension minimumSize()
   {
-return getDimensions ();
+return stub == null ? super.minimumSize () : getDimensions ();
   }
 
   /**
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: AWT regression?

[Thomas Fitzsimmons]

On Thu, 2004-04-29 at 09:42, Grzegorz B. Prokopski wrote:
> On Wed, 2004-04-28 at 12:46, Thomas Fitzsimmons wrote:
> > On Sat, 2004-04-24 at 18:52, Grzegorz B. Prokopski wrote:
> > > Hi all,
> > > 
> > > We've just imported fresh GNU CP as of Fri Apr 23 and running SymbolTest
> > > program, that previously worked nicely, as documented ex. at
> > > http://www.sablevm.org/screenshots , now gives this:
> > > 
> > > $ ~/work/bin/java-sablevm SymbolTest 
> > > (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
> > >   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
> > > (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
> > >   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
> > > (:19347): Gtk-CRITICAL **: file gtkwidget.c: line 4248
> > >   (gtk_widget_modify_fg): assertion `GTK_IS_WIDGET (widget)' failed
> > >  java.lang.NullPointerException
> > > at java.applet.Applet.getDimensions (Applet.java:469)
> > > at java.applet.Applet.preferredSize (Applet.java:486)
> > > at java.awt.Container.getPreferredSize (Container.java:576)
> > > at java.awt.BorderLayout.calcCompSize (BorderLayout.java:647)
> > > at java.awt.BorderLayout.calcSize (BorderLayout.java:692)
> > > at java.awt.BorderLayout.preferredLayoutSize (BorderLayout.java:454)
> > > at java.awt.Container.preferredSize (Container.java:589)
> > > at java.awt.Container.getPreferredSize (Container.java:576)
> > > at java.awt.Window.pack (Window.java:206)
> > > at SymbolTest.main (SymbolTest.java:100)
> > > at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
> > > at java.lang.VirtualMachine.main (VirtualMachine.java:88)
> > > 
> > 
> > I recently changed size reporting in Applet.java.  I made applets report
> > their preferred size as the width and height attributes given in the
> > applet tag.  However, the current code assumes that an applet stub is
> > present that can be queried for these attributes.  The NPE you're seeing
> > is likely caused by the stub not having been set.
> > 
> > The attached patch should fix the problem, though I haven't tested it. 
> > Can you try it out?
> 
> Hi Thomas,
> 
> I got a report (had no time to do it myself :-( ) that your patch
> actually fixed the problem.  I guess it should go into GNU CP CVS ASAP
> and 0.09 release too.
> 

OK, patch checked in.  I think the fix will make it into 0.09.  Thanks
for the report,

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Working On Classpath

[Thomas Fitzsimmons]

On Sun, 2004-05-23 at 22:04, Andrew John Hughes wrote:
> On Sun, 2004-05-23 at 22:50, Mark Wielaard wrote:
> > In general the easiest way to get started is to take one of the
> > development environments based on GNU Classpath (gcj, kaffe, ...) and
> > take one of the free software projects written in java and see whether
> > or not they work or not. And then try to figure out which functionality
> > would be needed to get them working. See also:
> > http://sources.redhat.com/rhug/
> > http://www.kaffe.org/compatibility_applications.shtml
> > 
> > Cheers,
> > 
> > Mark
> Hi,
> 

Hi,

> Apologies for spamming the list last time -- seems the mailing list has
> been lagging a little recently.
> 
> Well, I've been using a mix of gcj and sablevm with classpath for a
> while, but I've just put on Jam with the latest CVS version of Classpath
> so I can work on it (the former being maintained system-wide by Debian).
> Testing existing apps. does seem like the best route, and there are a
> few Java projects I'd like to see work with a Free base (namely Ant and
> Tomcat)

Modified versions of ant and tomcat that work with GCJ are available
from the RHUG project:

http://sources.redhat.com/rhug/

We're also doing work that will eventually allow these packages to run
unmodified on GCJ.

>  and a fair few of my own apps that I can also test (a fair range
> of assignment work, including AWT, Swing, RMI, TCP, UDP and servlets). 
> There are a few things I've spotted already, which I don't know if you
> know about or not:
> 
> * I've managed to get some very basic AWT and Swing examples running
> (just a button in a frame).  AWT seems to work almost flawlessly (which
> is a big improvement on last time I tried this), but seems to not handle
> window closing events correctly.

This is fixed on GCJ's java-gui-branch.

>   The Swing one is unfortunately still
> very buggy (throwing up both some display glitches and GTK errors), but
> I suppose this is to be expected.  One problem with Swing is that the
> access privileges of the getContentPane() method in JDialog seem to be
> wrong (compared with Sun's docs), preventing some of my code compiling. 

This is also fixed on java-gui-branch.

> The main question is how is the AWT/Swing code being handled?  I know
> recent code has been coming upstream from GCJ -- is this the case for
> all AWT/Swing code?

Yes, almost all AWT and Swing development is currently done on GCJ's
java-gui-branch.  We do java-gui-branch-to-Classpath merges about once
every three months.

>   I don't really want to handle anything here if its
> already being handled elsewhere.

It's probably best to work on the java-gui-branch then.  I've done some
work to simplify setting up a comfortable development environment.  See:

http://people.redhat.com/fitzsim/gcj-and-jhbuild.html

for an explanation.

>   Another problem I noticed -- as soon
> as a toolkit is instantiated, the code doesn't exit anymore, presumably
> because some thread is hanging on -- even something as simple as
> getDefaultToolkit().getScreenSize() needs a Ctrl+C.  It doesn't seem to
> be a JVM problem (same on Jam, Sable and gij) so must be something in
> the shared gcj/classpath code for the AWT (either in the main code or in
> the peers).

Yes, this is still a problem.  I haven't figured out yet what should be
the exit criteria for a GUI app.  Sun's JVM seems to exit some time
after the last window is disposed.  In my test applications I explicitly
call System.exit, but we should make our AWT implementation work like
Sun's when dispose is called.  It will take some experimentation -- do
you want to give it a go?

> * Both Tomcat and Ant seem to want tools.jar for Sun's compiler classes,
> which seems a bizarre dependency (especially considering the package is
> com.sun) -- is there a Free software version of this or some way of
> disabling it? Ant works fine without, until the compile stage (so its
> fairly required).  Tomcat only needs it for JSP AFAICS.
> 

People have worked around this dependency before.  See the RHUG version
of ant for instance.

> Anyway, I'll start posting patches once the copyright assignment is
> through,
> 

Excellent!

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Working On Classpath

[Thomas Fitzsimmons]

On Wed, 2004-05-26 at 17:47, Andrew John Hughes wrote:
> On Wed, 2004-05-26 at 18:44, Thomas Fitzsimmons wrote:
> > 
> > Modified versions of ant and tomcat that work with GCJ are available
> > from the RHUG project:
> > 
> > http://sources.redhat.com/rhug/
> > 
> > We're also doing work that will eventually allow these packages to run
> > unmodified on GCJ.
> > 
> I'm going to take a look now -- I think its great someone is doing this,
> although it probably should have been Apache to start with.  Given the
> length of time that the Free Java projects have now been active, it
> amazes me that so little consideration is given to alternate VMs and
> compilers by the Java community, especially for FOSS.  I know Ant
> supports alternate compilers, but this wouldn't exactly be very clear to
> someone who wants to use Ant in the same way as make ('make' -->
> 'ant').  One of the reasons that I think the autoconf/make stuff is
> still a superior solution, even for Java, is that these solutions tend
> to detect what a user actually has, instead of defaulting to Sun's JVM. 
> Apologies if some of this is wrong, but this is the impression I, and I
> guess other users, get of the Ant/Tomcat situation.
> 
> > Yes, almost all AWT and Swing development is currently done on GCJ's
> > java-gui-branch.  We do java-gui-branch-to-Classpath merges about once
> > every three months.
> ...
> > It's probably best to work on the java-gui-branch then.  I've done some
> > work to simplify setting up a comfortable development environment.  See:
> > 
> > http://people.redhat.com/fitzsim/gcj-and-jhbuild.html
> > 
> > for an explanation.
> > 
> I guessed as much, which was why I was wary of committing any patches
> for the small problems I've noticed.  It seems it would be best for me
> to get this set up as you say, and contribute any AWT/Swing patches to
> gcj rather than Classpath -- does this need a separate copyright
> assignment?
> > >   Another problem I noticed -- as soon
> > > as a toolkit is instantiated, the code doesn't exit anymore, presumably
> > > because some thread is hanging on -- even something as simple as
> > > getDefaultToolkit().getScreenSize() needs a Ctrl+C.  It doesn't seem to
> > > be a JVM problem (same on Jam, Sable and gij) so must be something in
> > > the shared gcj/classpath code for the AWT (either in the main code or in
> > > the peers).
> > 
> > Yes, this is still a problem.  I haven't figured out yet what should be
> > the exit criteria for a GUI app.  Sun's JVM seems to exit some time
> > after the last window is disposed.  In my test applications I explicitly
> > call System.exit, but we should make our AWT implementation work like
> > Sun's when dispose is called.  It will take some experimentation -- do
> > you want to give it a go?
> > 
> I'd be happy to have a look.  Even the following causes the problem:
> 
> import java.awt.Toolkit;
>  
> public class AWTGetScreenSize
> {
>  
> public static void main(String[] args)
> {
> System.out.println(Toolkit.getDefaultToolkit().getScreenSize());
> }
>  
> }
> 
> Which is possibly one of the most minimal examples you could give for
> this (dropping .getScreenSize() would probably drop it down even more).
> From looking at the code, I know the instantiating the toolkit via
> getDefaultToolkit() spawns the underlying GDK event threads, so it may
> be related to this -- the only way to really find out is to trace the
> calls, I suppose.  AFAIK, Java apps. should die when all non-daemon
> threads have stopped (i.e. the GC can still be running, as its a
> daemon).

Right, but we can't make all default threads daemons, or programs will
exit right away.  The two non-daemon threads in a typical AWT program
are EventDispatchThread and GtkMainThread.  I'm wondering if we should
make GtkMainThread a daemon, and have the exit criteria for AWT programs
be that all threads except EventDispatchThread are daemons, all
EventQueues are empty, and all top-level windows have been disposed.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Proposal for a "main class" system property

[Thomas Fitzsimmons]

Hello,

What do people think of having a system property that stores the name of
the class whose main method is being run?  I need this value to properly
initialize the GTK peers.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Proposal for a "main class" system property

[Thomas Fitzsimmons]

On Thu, 2004-05-27 at 23:37, Tom Tromey wrote:
> >>>>> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:
> 
> Tom> What do people think of having a system property that stores the name of
> Tom> the class whose main method is being run?  I need this value to properly
> Tom> initialize the GTK peers.
> 
> On irc you had an example showing that this is what Sun's AWT does
> under the hood.
> 

Yeah, when I take a screenshot of any window created by Sun's AWT, it is
saved as Screenshot-Mainclassname.png.  When I take a screenshot of a
pure GTK application, it is saved as Screenshot-Binaryname.png.  When I
take a screenshot of our AWT, it is saved as Screenshot-.png.  gtk_init
sets the wmclass property of every window it creates to argv[0] (unless
one overrides the value with gtk_window_set_wmclass).  The screenshot
mechanism puts that property's value in the filename.  We currently set
argv[0] to "" when calling gtk_init, which explains the weird screenshot
name.

> I think it would be fine to have some `gnu.classpath.whatever'
> property that VMs are encouraged to set.  My impression is that AWT
> will work even if you don't set this, it just might not be as friendly
> in some situations.
> 

Yes, that's right.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Working On Classpath

[Thomas Fitzsimmons]

On Mon, 2004-06-07 at 17:31, Andrew John Hughes wrote:
> On Mon, 2004-06-07 at 19:57, Dalibor Topic wrote:
> > Andrew John Hughes wrote:
> > > One thing I do think the Windows community still have over us by a long
> > > shot is Java within the browser.  Is the OJI project still active for
> > > Mozilla, and will we see a Free Java plug-in at some point?  It would
> > > definitely give us a lot more test-cases, and simpler ones at that ;-)
> > > Something I would like to look into, if anyone has any pointers...
> > 
> > http://www.nongnu.org/gcjwebplugin/ :)
> > 
> > cheers,
> > dalibor topic
> Thanks!  Looking at the page, I do recall now having seen it before. 
> The page suggests the project is dead, but the mailing list and CVS show
> it as still pretty active...
> 

Yes, sorry about the web page -- I'm sending an S.O.S. out to Michael to
update it! ;-)  Lately, I haven't been working directly on gcjwebplugin
and gcjappletviewer themselves, but rather using them to test applets,
and fix the AWT bugs that they expose.

Here's a screenshot I created last night to prove that gcjappletviewer
is alive and well:

http://people.redhat.com/fitzsim/vncviewer-2004-06-11.png

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: [Fw] GridBagLayout in kaffe CVS HEAD

[Thomas Fitzsimmons]

On Tue, 2004-06-15 at 10:00, Arnaud Vandyck wrote:
> Maybe [EMAIL PROTECTED] or [EMAIL PROTECTED] will help you better than
> me. I Cc them.
> 
> Thanks for your time,
> 
> Cheers,
> 
> 
> __
> From: James Damour <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: GridBagLayout in kaffe CVS HEAD
> Date: Tue, 15 Jun 2004 08:38:26 -0400
> 
> Hello!

Hi,

>   I am a developer of the MegaMek project
> (http://megamek.sourceforge.net) and I'm trying to get MegaMek to run
> under a free VM.  So far, Kaffe is the most successful at running
> MegaMek, but it has problems with laying out the windows.  I was
> wondering if you could help me debug the problem or point me to someone
> who can.
> 
> I've created a simple test case and I've attached it to this email.

Thanks!  David Jee is looking into this.

>   I
> compile the code using both the jikes v1.18 that is in Debian Sarge
> (with -bootclasspath is /usr/local/kaffe/jre/lib/rt.jar) and with kjc. 
> When I run under Blackdown JRE v1.3.1, I can see the text in all of the
> buttons (and they're about 8 cm wide); when I run under Kaffe, the
> buttons are too narrow (about 1 cm wide).  As this email's title says,
> I'm currently following Kaffe's HEAD branch, so I've gotten the
> latest-and-greatest version of your Classpath.
> 
> I'm willing to take whatever steps are necessary to resolve this issue,
> but I'm not really sure where to start.  Should I even try to work this
> through with Kaffe?  Should I try using the gcj AWT/Swing CVS branch
> instead?  Any insights that you may provide would be greatly
> appreciated.
> 

Yes, I would recommend working on GCJ's java-gui-branch, since that's
where new AWT and Swing development is being done.  I've done some work
that makes setting up a GCJ-based GUI development environment pretty
easy:

http://people.redhat.com/fitzsim/gcj-and-jhbuild.html

Do you already have an FSF copyright assignment?  If not, you'll need to
get one before you start submitting AWT/Swing patches.

Good to hear you're interested in helping out!

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: does somebody work on JSpinner and friends?

[Thomas Fitzsimmons]

On Tue, 2004-06-29 at 04:31, Roman Kennke wrote:
> Hi,
> 
> I'd like to work on JSpinner and related classes. First I would like to
> check, if somebody else is already working on it. I see, that
> javax.swing.SpinnerModel is already there, so this might be the case.
> 
> In case somebody is already working on it, maybe I could help with some
> pieces (there are quite a view classes involved). Otherwise I would
> start with the xxxSpinnerModel classes and then continue with the rest.
> 
> Please let me know, if there is already work done. Maybe I should say,
> that I only have the latest classpath CVS at hand, and not GCCs
> java-gui-branch.
> 

Yes, Ka-Hing has already submitted a patch.  We have to wait for his FSF
copyright assignment to go through before we can review the changes.

http://lists.gnu.org/archive/html/classpath/2004-05/msg00107.html

Tom

> Best regards, Roman
> 
> 
> __
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/classpath



___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: GNU Classpath and JDK1.0 completeness and compatibility

[Thomas Fitzsimmons]

On Mon, 2004-07-12 at 13:37, Roman Kennke wrote:
> Hi list,
> 
> In one of the last threads on this list there was a discussion about
> which JDK spec GNU Classpath should have as a goal for its 1.0 release.
> I will not answer it here (altough it seemed that most people see 1.4 as
> a reasonable goal).
> 
> To concentrate efforts and to provide a basis for future development I
> think it is reasonable to start with spec JDK1.0, complete this and then
> concentrate on 1.1 and so on. Sure, there are some incompatibilities and
> inconsistencies when going this way, in these cases I propose to make a
> compromise in favour of the newer spec.
> 
> I have put together a checklist against JDK 1.0:
> 
> http://ontographics.com/classpath/status-1.0.html
> 
> I am starting now to manually audit all classes listed there with the
> criteria listed on this page in mind. I'll start with documentation,
> then check for implementations of the specified classes and public
> methods and then write missing tests and/or fix failing tests. Of course
> everybody is invited to join these efforts. :)
> 

This is hugely useful.  Once you're done the AWT audit, I will write
documentation and tests to fill in the missing bits.

While the Acunia Visual Test Suite is excellent for testing general
functionality, it doesn't really test API conformance.  For API-level
testing, we need a new AWT test suite that contains minimal test cases
and detailed instructions for how to run each one.  I think we should
write a test suite like this as part of the JDK 1.0 effort.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: Problem with component image capture with Component.printAll()

[Thomas Fitzsimmons]

On Sat, 2004-07-24 at 13:58, Jeff Myers wrote:
> Greetings All,
> 
> I'm attempting to test out Classpath's AWT support, specifically in
> the context of component image capture capability necessary to support
> the Eclipse Visual Editor project.  Classpath's Component.printAll()
> method is returning a badly garbled image (with Classpath 0.10 running
> via jamvm).  Attached is a simple testcase of this issue.  Any help
> resolving this issue would be appreciated.
> 

I looked at this briefly.  What you're seeing is the result of painting
uninitialized image data.  To solve this, we'll need to have GTK not
only paint widgets on its native windows, but also into the graphics
object that we pass to the peers' paint methods.

For example, see GtkComponentPeer.paint.  We'll need to call a native
method there that calls GTK to paint the widget into g's buffer.  I
don't know how to do this, but I'm pretty sure it's possible, since I've
heard Mozilla does something like this to render its native-looking
widgets.

Can you file a bug in GCC bugzilla under the AWT component, and attach
this test case?

Thanks,
Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

AWT and Swing bug reports

[Thomas Fitzsimmons]

Hi,

With lots of help from Daniel Berlin (thanks Daniel!), I just finished
exporting Red Hat's internal AWT and Swing bug reports to GCC bugzilla.

Currently, each bug is assigned to one of us Red Hat hackers but that
doesn't necessarily mean we're working on all of them at once.  So if
you'd like to help out on a particular bug, just ask, and we'll reassign
it to you.

Go get 'em!
Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: Japi results updated - full 1.0 and 1.1 *extremely* close

[Thomas Fitzsimmons]

On Fri, 2004-10-29 at 11:52, Stuart Ballard wrote:

> I have a few more things I want to do before making a release of this, 
> but I thought people might want to know about this so they can 
> immediately set to fixing those 4 remaining errors to claim complete 1.1 
> and 1.0 coverage :)
> 

I committed a fix for the missing java.awt.Font fields.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: Visual mauve test?

[Thomas Fitzsimmons]

On Mon, 2004-12-13 at 12:44 +0100, Thomas Zander wrote:
> Would anyone have problems with me committing a mauve test that opens a 
> Window for a very little time?
> 

No, we can't do this yet, but it's something we should work on.  We need
to put a gui testing framework in mauve first.  We'll need to use Xvfb
so that nothing is actually displayed on the tester's desktop.  And
we'll likely want a java.awt.Robot implementation too so that we can
script gui tests.

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: GdkGraphics extending Graphics2D?

[Thomas Fitzsimmons]

On Sat, 2005-03-05 at 17:46 +0100, Sven de Marothy wrote:
>Hello,
>
>Currently we have a Cairo-based Graphics2D peer and a GTK-based Graphics
>peer. 
>
>The way I understand it, the plan is to throw out GtkGraphics completely
>and make the Cairo-based Graphics2D peer the default as soon as Cairo
>becomes integrated into GNOME, which is scheduled for this year.
>
>The way I see it, just adding stub methods might cause more problems
>than it solves. Whereas implementing them would be a waste of effort
>which could be better spent on improving the Cairo peer instead. 
>(And the Java2D support in general)
>
>It's not quite as simple as just adding the missing methods either.
>Java2D is basically a completely different thing, which Sun rather
>klugily grafted onto the existing API. So it's not just a question of
>missing methods but a rather different architecture. The GtkGraphics
>implementation can get away with doing nasty things internally like cast
>Image to GtkImage. It does quite a lot of nastiness like that, since the
>original Java 1.0/1.1 model is much more abstract. This won't work with
>Java2D which has BufferedImage, and so on. 
>
>So, IMHO, trying to turn the Graphics peer into Graphics2D will just add
>to the kluginess. Better to do the proper thing and throw it out as soon
>as it's practical to do so, and put our effort into Graphics2D and
>Cairo.
>

Very well said.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Proposal: merge Jessie as an external project

[Thomas Fitzsimmons]

Hi,

I propose that we build Jessie directly into glibj.zip.  Having Jessie
present by default would be convenient both for GNU Classpath developers
and also for packagers.

For GNU Classpath developers who want to test apps that require SSL, it
would mean one less dependency to fetch and setup on CLASSPATH.

For packagers obviously it would mean one less package to maintain.
More importantly though, it would eliminate a circular dependency.  In
Fedora Core 4, for example we want a Java SSL provider available by
default.  This means that ideally the libgcj package should depend on
the Jessie package.  But Jessie's build requires libgcj.  We worked
around this by having java-gcj-compat depend on both libgcj and Jessie,
and packages requiring a Java SSL provider requiring java-gcj-compat.
However in my opinion this complexity is unwarranted especially given
that Jessie's SSL provider jar is only 350K.

Because Jessie is its own separate project I'm thinking that at least in
the short term we should cvs import it into classpath/external
periodically, and let upstream development happen in its current
repository.

Sound reasonable?

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Proposal: merge Jessie as an external project

[Thomas Fitzsimmons]

On Wed, 2005-04-27 at 16:14 -0500, Archie Cobbs wrote:
> Thomas Fitzsimmons wrote:
> > I propose that we build Jessie directly into glibj.zip.  Having Jessie
> > present by default would be convenient both for GNU Classpath developers
> > and also for packagers.
> > 
> > For GNU Classpath developers who want to test apps that require SSL, it
> > would mean one less dependency to fetch and setup on CLASSPATH.
> > 
> > For packagers obviously it would mean one less package to maintain.
> > More importantly though, it would eliminate a circular dependency.  In
> > Fedora Core 4, for example we want a Java SSL provider available by
> > default.  This means that ideally the libgcj package should depend on
> > the Jessie package.  But Jessie's build requires libgcj.  We worked
> > around this by having java-gcj-compat depend on both libgcj and Jessie,
> > and packages requiring a Java SSL provider requiring java-gcj-compat.
> > However in my opinion this complexity is unwarranted especially given
> > that Jessie's SSL provider jar is only 350K.
> 
> Not to be a contrarian, but in general I don't like the idea of
> glomming in more and more libraries together like this. I'll try to
> emit some coherent reasons why...
> 
> First, you are looking for a workaround to a dependency problem which
> is not of Classpath's making. "Ideally the libgcj package should depend
> on the Jessie package" -- perhaps that's true for Fedora, but if so it's
> because of a Fedora policy decision. That policy should be encapsulated
> in the Fedora build, not the Classpath build.
> 

I guess part of my proposal is that Classpath adopt the same policy (see
below).

> If Classpath wants to help users to have a good experience, we can
> point them at the relevant external 3rd party libraries to go fetch.
> 

But then the experience isn't as good as it could be, since there are
extra steps involved in producing an SSL-enabled Classpath build.

> Secondly, there are good solutions out there to the JAR interdependency
> problem, namely Jpackage. Jpackage can eliminate the habit of every
> Java project shipping every other Java project's JAR files in its lib/
> subdirectory.. invariably you end up with a zillion copies of the same
> JAR (e.g., xerces and xalan) but different (often incompatible) versions.
> 

Yes, we use the JPackage conventions in Fedora; in fact, this proposal
will help us implement them more faithfully (again, see below).

> Thirdly, there's the inevitable maintenance problem with having a copy
> of somebody else's code lying around.. it always goes out of date, becomes
> incompatible, etc. E.g., if my boot loader is loading an old, broken
> version of Jessie, just putting the new one in my (application) classpath
> won't work.. I have to perform surgery on my boot loader classpath.
> This actually happened to me with Sun's JDK because Sun ships an old,
> broken version of Xerces in their rt.jar (!)
> 

This problem exists no matter where Jessie resides.  For a core piece of
infrastructure like Jessie, I'd rather see its integration with
Classpath tested by the wider Classpath community than just tested
downstream by packagers.

> Finally (and this is only obliquely related), Classpath does not depend
> on libgcj. It builds just fine using Jikes... so don't assume they always
> go together. For example, I never use gjc (preferring JC of course :-)
> 
> Classpath should (IMHO) simply be an implementation of the core Java
> classes, nothing more.

I agree fully and that's the point of this proposal.  SSL support is
part of the "core Java classes" and that's why integrating Jessie into
Classpath is different than integrating, say Java-GNOME.  Sun's SDK
includes an SSL implementation.  They happen to ship it as a jar that is
separate from rt.jar but it is still included on the boot classpath.
The important point is that a JPackage SDK RPM includes an SSL
implementation, with no external dependencies.  We could simulate this
in Fedora but in our RPM we'd need to carry a local patch that did the
import I'm proposing.  It's much more efficient to maintain this import
upstream.

I would argue that in general, Classpath's policy should be to include
anything that's in Sun's SDK by default.   For things like image and
protocol providers I think we should strive to include more than Sun by
default.  For example, as both a Classpath developer and end-user, I'd
much rather have the ability to read and write any image format by
default.  I don't want to have to search around for external plugins to
build and install.

>  If you want the full monty, it's easy to put
> that together,

Re: Proposal: merge Jessie as an external project

[Thomas Fitzsimmons]

On Thu, 2005-04-28 at 14:32 +0200, Mark Wielaard wrote:
> On Thu, 2005-04-28 at 10:11 +0100, Andrew Haley wrote:
> > Michael Koch writes:
> >  > 
> >  > The thing is that Casey wanted to contribute it to GNU classpath anyway 
> > and
> >  > maintain it in inside classpath, AFAIK. There are just some issues with 
> > FSF
> >  > last I heard.
> > 
> > Meybe we should find out what those issues are before merging.
> 
> The issue here was bureaucracy. Some miscommunication with several
> people saying "you need to ask someone else". I have complained about
> this to some FSF people and hopefully this won't happen anymore in the
> future. But please remember we are all just human and there are a lot of
> people contacting the FSF each and every day.
> 

Was this resolved or not?  I'd like to post a patch to import Jessie
into GNU Classpath as Casey described.  Can the patch go in once Casey
approves it?

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Proposal: merge Jessie as an external project

[Thomas Fitzsimmons]

On Wed, 2005-04-27 at 22:08 -0700, Casey Marshall wrote:
> >>>>> "Archie" == Archie Cobbs <[EMAIL PROTECTED]> writes:
> 
> Archie> Thomas Fitzsimmons wrote:
> >> I propose that we build Jessie directly into glibj.zip.  Having
> >> Jessie present by default would be convenient both for GNU
> >> Classpath developers and also for packagers.  For GNU Classpath
> >> developers who want to test apps that require SSL, it would mean
> >> one less dependency to fetch and setup on CLASSPATH.  For packagers
> >> obviously it would mean one less package to maintain.  More
> >> importantly though, it would eliminate a circular dependency.  In
> >> Fedora Core 4, for example we want a Java SSL provider available by
> >> default.  This means that ideally the libgcj package should depend
> >> on the Jessie package.  But Jessie's build requires libgcj.  We
> >> worked around this by having java-gcj-compat depend on both libgcj
> >> and Jessie, and packages requiring a Java SSL provider requiring
> >> java-gcj-compat.  However in my opinion this complexity is
> >> unwarranted especially given that Jessie's SSL provider jar is only
> >> 350K.
> 
> I support doing this, and would even rather see it get its packages
> renamed to 'gnu.jessie', or 'gnu.javax.net.ssl', eventually.
> 

If you're willing to maintain this code in the GNU Classpath repository
then should we just do this rename right away?  Shall I post a patch?

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: AWT hacks (Was: [cp-patches] FYI: Only prepare GtkImages in GtkToolkit)

[Thomas Fitzsimmons]

Hi,

On Mon, 2005-05-02 at 18:09 +0200, Mark Wielaard wrote:

> I think targeting a new gtk+ and a cairo 1.0 release is easier then
> adding BufferedImage support to GdkImage. But looking at the RoadMap and
> TODO of cairo it looks like cairo 1.0 is still a long way off:
> http://cvs.cairographics.org/cairo/ROADMAP?rev=HEAD
> http://cvs.cairographics.org/cairo/TODO?rev=HEAD
> 

Yes, my plan is to wait until the Cairo APIs have settled.  Then we can
make this transition.

> On the other hand Owen Tayler has been doing reviews of java-gnome and
> the cairo bindings this last week:
> http://lists.freedesktop.org/archives/cairo/2005-April/003783.html
> http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JGDiscussionMemoryManagement
> So it might make sense to take this oppertunity to lay down a plan for
> the future needs of our gtk/cairo awt peers and ask him for input on it.
> 

That's a good idea.  It looks like I'll be able to devote more time to
AWT and Swing hacking soon, so I'll revisit this.

Thanks for the overview,
Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: IIOP tools

[Thomas Fitzsimmons]

On Fri, 2005-05-13 at 16:12 +0200, Sven de Marothy wrote:
> Hi Archit,
> 
> >GNU Classpath currently has almost no support for IIOP. I'm wondering 
> >what the interest level is in expanding GNU classpath support for
> IIOP. 
> >I'm not sure what runtime classes are needed for IIOP, but I think 
> >JacORB [1] provides most of what is needed.
> 
> Right, but not the interfaces and the like. Unfortunately we can't use
> the OMG code, due to licensing reasons.
> 

Yes, I've been wondering about this.  Audrius, are you working on
re-implementing these non-free interfaces?  That would probably be the
best place to start on Classpath's implementation.  Then maybe we can
get JacORB dual-licensed LGPL/GPL+exception and import it into Classpath
directly.

Since JacORB is already very mature and widely-used it would be a shame
to duplicate all that effort in Classpath, just for licensing reasons.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Spring-cleaning of gtk peers.

[Thomas Fitzsimmons]

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 (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 GtkImagePainter completely. I have no idea why GtkImage
> can't have package-private methods for drawing itself. (And do so
> correctly.)
> 
> 3) Get rid of GtkOffScreenImage. It doesn't seem to serve any real
> purpose.
> 
> End result: Less code, simpler code and much, much faster drawing.
> 
> Is there anyone in defense of the existing way images are handled?
> 

Not me.  Have at it!

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: ClasspathToolkit redesign.

[Thomas Fitzsimmons]

Hi,

On Sun, 2005-07-24 at 00:19 +0200, Sven de Marothy wrote:

[...]

> Method: getClasspathFontPeer(), getClasspathTextLayoutPeer(), getFont() 
> Comment: We need these. No way around that. But they could perhaps be
> put in a seperate ClasspathFontInterface or something.

OK.

> 
> Method: createFont()
> Comment: Um, we don't even implement this ourselves. Sorry Sacha, but
> there's no point. Right now anyway.
> 
> Method: createRobot()
> Comment: This we need. But it's a rather singular item. Replace with a
> property setting? Certain peers may not (or cannot) have Robots anyway.

How could this be replaced by a property setting?

> 
> Method: createEmbeddedWindow ()
> Comment: What's an EmbeddedWindow and why do we need this as part of the
> peer interface?

An EmbeddedWindowPeer is a wrapper around the native toolkit's
implementation of the XEMBED protocol.  gnu.java.awt.EmbeddedWindow
should use the current toolkit's XEMBED implementation, e.g. for GTK,
GtkPlug.  We'll need some way to create the peer dependent on the
toolkit.  Whatever we do for Robot can be done here too.

> 
> Method: registerImageIOSpis()
> Comment: Unnecessary. The peers can register their SPIs (if they have
> any) themselves without this.
> 
> Method: nativeQueueEmpty(), wakeNativeQueue(), iterateNativeQueue()
> Comment: These are specific to how the GTK peers handles threads and
> events, and should certainly not be part of the interface. The versions
> of EventQueue using these methods should be reverted too. The GTK peers
> should extend and overload EventQueue for their custom approach instead.
> 
> Summary: So, my opinion: Keep most of the font stuff and the robot
> stuff. Get rid of the rest, and we'll have an interface which is both
> closer to the JDKs, and simpler.
> 
> Comments?

Yeah, this sounds good.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

cleaning up the AWT

[Thomas Fitzsimmons]

Hi,

Now that we have Qt peers, we need to be more diligent about not having
gtk-peer specific code in java.awt.  Currently, there are two main
places where such code has crept in: the native event queue interfacing
in EventQueue, and setBoundsCallback in Window.  My plan is to re-work
these two sections of code to remove these references.  Since these are
critical areas of java.awt, there may be a brief period of instability.
I'll make sure that Swing continues to work with every patch I commit,
so as not to disrupt its development.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

awt and swing bugzilla cleanup

[Thomas Fitzsimmons]

Hi,

I just finished cleaning up the awt and swing components in bugzilla.
All open bug reports now reflect real bugs in GNU Classpath CVS HEAD,
and each one has been assigned to an appropriate active developer.

There are currently 50 open GUI bugs.  Let's see how many we can fix
before 0.18 is released!

Tom




___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: JAWT odds

[Thomas Fitzsimmons]

Hi,

On Wed, 2005-09-07 at 02:10 +0200, Robert Schuster wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> I have some questions about the JAWT interface in Classpath.
> 
> 1) To compile the JAWT demo I had to copy the source files into the object
> folder and run make with:
> 
> make -f Makefile.jawt (from ${obj_dir}/examples)
> 
> It would be nice if the makefile would work without the need to copy the 
> sources
> over.

Yes, even better would be if the JAWT demo were built automatically
along with the other examples.  But that requires extra build machinery
that's not in place yet.

> 
> 2) Then I had troubles running the demo in the way I am used to (JDK-like). I
> would call:
> 
> jamvm -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT
> 
> (In "." lies the libDemoJAWT.so library and my jamvm is compiled to use
> Classpath and its libraries from a user directory - so no additional arguments
> should be needed.)

Yes, I'm currently sorting this out for libgcj and java-gcj-compat.  Sun
puts libjawt.so in $JAVA_HOME/jre/lib/i386.  To ensure that libjawt.so
is found automatically, Sun's java executable prepends
$JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within
the new environment.

I've just added a java command to java-gcj-compat that does the same
thing only exec's gij instead of re-exec'ing itself.

java.library.path has nothing to do with LD_LIBRARY_PATH except that its
user-visible value defaults to the contents of LD_LIBRARY_PATH.  The
argument to -Djava.library.path= should be added to the dynamic library
loader's search path.

> 
> However this failed with:
> 
> [EMAIL PROTECTED] ~/tmp/cp-dev/swing-fixes/cp-obj/examples $ jamvm
> - -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT
> java.lang.UnsatisfiedLinkError: Native library `DemoJAWT' not found (as file
> `/libDemoJAWT.so') in gnu.classpath.boot.library.path and java.library.path
>at java.lang.Runtime.loadLibrary (Runtime.java:763)
>at java.lang.System.loadLibrary (System.java:512)
>at gnu.classpath.examples.jawt.DemoJAWT. (DemoJAWT.java:30)
> 
> The only way I to run the demo was by calling:
> LD_LIBRARY_PATH=.:/home/rob/INSTALL/classpath/lib/classpath jamvm
> gnu.classpath.examples.jawt.DemoJAWT
> 
> So, now I wonder whether this is my fault because I extensively played around
> with --prefix installed software (Qt4, Classpath and JamVM) or a bug in
> Classpath (or JamVM)?
> 
> Btw: Great work with the JAWT interface. That is one really nifty feature.

Thanks!

> Btw2: It does not work with the Qt4 peers, but I think this is a known bug, 
> is it?

JAWT isn't implemented by the Qt4 peers yet.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: JAWT odds

[Thomas Fitzsimmons]

On Wed, 2005-09-07 at 18:15 +0200, Mark Wielaard wrote:
> Hi Tom,
> 
> On Tue, 2005-09-06 at 20:50 -0400, Thomas Fitzsimmons wrote:
> > > It would be nice if the makefile would work without the need to copy the 
> > > sources
> > > over.
> > 
> > Yes, even better would be if the JAWT demo were built automatically
> > along with the other examples.  But that requires extra build machinery
> > that's not in place yet.
> 
> That is the idea. But I didn't want to introduce that extra build
> machinery one day before the release. So I choose to make a self
> contained example that the user would have to compile/run by hand for
> 0.18. If someone wants to merge example/Makefile.am with
> example/Makefile.jawt.in that would be cool.
> 
> > Yes, I'm currently sorting this out for libgcj and java-gcj-compat.  Sun
> > puts libjawt.so in $JAVA_HOME/jre/lib/i386.  To ensure that libjawt.so
> > is found automatically, Sun's java executable prepends
> > $JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within
> > the new environment.
> > 
> > I've just added a java command to java-gcj-compat that does the same
> > thing only exec's gij instead of re-exec'ing itself.
> 
> I am not sure I have to be impressed or appalled by this hack :)
> 
> Would it by an idea for the runtime (libgcj or some other) to dlopen the
> installed jawt library with RTLD_GLOBAL set before opening any other jni
> library (or maybe dlopen with the full path to libjawtgnu.so with
> RTLD_GLOBAL as soon as dlopen on a jni library fails and then retry
> loading that jni library)? That way it seems the linker can resolve the
> jawt symbols without needing to explicitly opening the shared library
> itself.

Yes, good idea.  I'm going to leave libgcj as-is since I'm pretty sure
its maintainers would reject hacks like this (whereas java-gcj-compat is
a good place to contain them) but it might be interesting to try these
approaches in other runtimes.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: ImageIO reader based on ImageMagick

[Thomas Fitzsimmons]

On Thu, 2005-09-08 at 20:32 +0200, Robert Schuster wrote:
> Hi folks,
> for some time now I want to see an ImageIO reader in Classpath which uses
> ImageMagick. However because of lack of time I could not finish it.

This is a good start.  Thanks!

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: ImageIO reader based on ImageMagick

[Thomas Fitzsimmons]

On Thu, 2005-09-08 at 20:32 +0200, Robert Schuster wrote:
> Hi folks,
> for some time now I want to see an ImageIO reader in Classpath which uses
> ImageMagick. However because of lack of time I could not finish it.
> 
> Now I tarred the sources together in the hope that somebody else who is more
> experienced with ImageIO can finish it.
> 
> The program in the attachment (Viewer) can display anything that ImageMagick 
> is
> able to read (even PDF :) ). You need to compile java-img.c into a shared
> library for this.
> 
> What I have basically implemented is a native method that turns a (NIO)
> ByteBuffer into a BufferedImage (RGBA - regardless of what the source image
> really needed).
> 
> The program works like this:
> First parameter can be i or r. 'i' tells it to load via ImageIO while 'r' uses
> the native method. Second parameter is the name of the file you want to look 
> at.

The license in the tarball is GPL.  Is it OK if we incorporate this code
into GNU Classpath, changing the license to GPL+exception?

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Using headless awt...

[Thomas Fitzsimmons]

On Mon, 2005-09-19 at 11:30 -0400, Martin Cordova wrote:
> Hello, I am using JamVM with Classpath 0.18
> 
> I wonder if it is possible to use the system property:
> 
> -Djava-awt.headless=true in order to create server-side graphics from
> servlets running on Linux with X common libs installed, but without a
> graphics environment.
> 
> I am not able to test it myself a this moment, but previous tests with
> 0.17 generated exceptions. That's why I am asking.

It likely still will generate exceptions; if you can reproduce them with
a small test case please submit a bug report to the classpath/awt
component in gcc.gnu.org/bugzilla.  Eventually we'll have to start
testing headless mode but we haven't been so far.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Classpath Meeting Minutes (2005-10-07)

[Thomas Fitzsimmons]

On Fri, 2005-10-07 at 13:25 +0200, Mark Wielaard wrote:
> Hi,
> 
> On Fri, 2005-10-07 at 02:49 +0200, Robert Schuster wrote:
> > GNU Classpath Meeting Minutes from 2005-10-07 17:00 UTC
> 
> Thanks for making the minutes Robert.
> 
> > Basically, Mark explained, he could not believe that everything is going on
> > smoothly. He studied Apache's procedures and asked the attendents whether 
> > these
> > would be useful for Classpath, too.
> > 
> > However everybody seemed happy with the way it is and Mark was a surprized 
> > that
> > people seem so happy to hack on GNU Classpath while the project has no real
> > formal structure.
> 
> Just to be clear. There is a "formal structure" as outlined in our
> Hacking Guide .
> But we are very light on procedures. Basically the only formality is
> making sure the legal side is correctly handled. After that the "rules"
> are more like gentlemen agreements. We expect people to play nice,
> listen to each other and take each others opinion seriously.
> This seems to work just fine. Tom Tromey said that we should not impose
> any extra procedures unless there is a clear need. For example because
> people are actively behaving in an "anti-social" manner. And that time
> has (luckily!) not come.
> 
> > Mark was worried about introducing dependencies on Gtk+-2.8 and Cairo-1.0.0 
> > .
> > These would be a necessity of the AWT rework[0]. Sven added that he does not
> > expect these changes before 0.19 .
> > 
> > Unfortunately Thomas was not present to discuss the item so we remained at
> > postponing any major AWT rework to a time after the November release.
> 
> Lets try a release in the first week of November then. We could set the
> release date a bit earlier if Tom, or anybody else, wants to start the
> migration to 2.8 earlier. Just to make sure that we have one more
> release that doesn't need a "bleeding edge" gtk+ version. But we will
> need modern versions of various libraries in the end anyway to support
> all the cool stuff we want to have. So we could also just bite the
> bullet early if that is more convenient.

I'm fine with postponing the GTK 2.8 migration until after a November
release.  I think this will be a major refactoring of GdkGraphics2D that
will have to be done all at once, so I can commit it just after the next
release and leave lots of time for debugging before the subsequent
GTK2.8-enabled release.

> 
> > Integration of GNU Crypto was mentioned and that we have to wait for Casey's
> > rewrite of it. Mark stated that Casey would be the only one being able to 
> > do the
> > integration nicely.
> 
> s/GNU Crypto/Jessie/
> Casey Marshall is working on NIO support in Jessie
> . Jessie is packaged for the various
> distributions. But various people (on the Jessie mailinglist) had
> trouble getting the latest release integrated with the latest inetlib
> and classpath releases.

Actually I'd like to see the bits of GNU Crypto that Classpath and
Jessie require merged in as well.  I believe that was also on Casey's
roadmap.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Swing (more screenshots)

[Thomas Fitzsimmons]

On Fri, 2005-10-07 at 15:24 +0200, Norman Hendrich wrote:
> Hello all,
> 
> a while ago I made myself some enemies complaining about the AWT/Swing
> support in gcj (http://gcc.gnu.org/ml/java/2005-05/msg00052.html).
> Back then, I was really frustrated about obscure compiler bugs in gcj
> being fixed within minutes, while even small test programs like many
> of the Swing-trail examples from the Java tutorial would crash...
> 
> Since then, I swiched from testing gcj+classpath to jamvm+classpath.
> Overall, the progress with Swing is really astonishing, despite a few
> drawbacks due to added functionality (like the accessibility stuff,
> better plaf support, and the repainting refactoring).
> 
> ---
> 
> Perhaps submitting bug reports with testcases made all the difference?

Yes, it really did.  Bug reports with test cases help us focus our
development efforts and make fixing problems much easier.

[...]

> (1) fix JScrollPane and JViewport
> (2) make JTextField and JTextArea more robust
> (3) implement the missing bits of Graphics2D (fix segfaults)

Yes, Graphics2D is in terrible shape.  I'm currently working on ImageIO,
but I'll turn my attention to GdkGraphics2D next, and you'll see your
bug list dwindling.

Thank you for your continued testing efforts!

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Swing (more screenshots)

[Thomas Fitzsimmons]

Hi,

On Sun, 2005-10-09 at 18:04 +0200, Luis W. Sevilla wrote:
> Hi all,
> this may be a little off-topic, 'cause we've done any test already. 
> Our application it's a very big and demanding one for desktop mapping, 
> and includes a bunch of dependencies. It's available (GNU/GPL licensing) 
> at www.gvsig.gva.es, and needs JAI, image i/o, full swing and full JNI 
> for running.

JAI is the only item we likely won't have full support for in the
foreseeable future.  Do you use it heavily?  Unfortunately, I'm not
aware of any free software replacements for those APIs.

> We're considering to add someone to classpath evaluation, testing 
> and maybe codding, for helping to finish those parts we need to run over 
> a free VM, and in two or three months we'll need some advice about 
> what's more needed and the path to did it.

Excellent; keep us posted on your progress.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: "release meeting" minutes

[Thomas Fitzsimmons]

Hi,

On Fri, 2005-10-21 at 19:36 +0200, Mark Wielaard wrote:

> - What about Graphics2D (move to cairo 1.0/gtk+2.8)? imageio? qt4-peers?
>   For 0.19 we are still on  gtk+ 2.4/6 for the gtk+ awt peers.
>   We can revamp and upgrade to gtk+2.8.x, cairo 1.0.x after 0.19.
>   Neither Tom Fitzsimmons nor Sven de Marothy were available to give an
>   update on the imageio/qt4 status. We probably just "ship" with what we
>   have. Unless one of them yells and shouts that they want something
>   specific in before 0.19.
>   - That means, sorry to those wanting "core graphics" upgrades for
> 0.19, that is just too big a thing for the last 2 weeks.
> (Soon after though we will hopefully start overhauling some of it.)

Right, I'll start the Graphics2D overhaul sometime after 0.19.  For
ImageIO, I plan to have javax.imageio 1.5-complete except for the jpeg
and bmp packages.  I'll have to leave the ImageMagick backend until
after 0.19.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Problems running GTK-peers on Nokia-770

[Thomas Fitzsimmons]

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 main problem is there which I wasn't able to
> solve:
> 
> As soon as I create a JFrame I get the following expections, although
> adding Swing components to a Frame works:
> jamvm[1625]: GLIB CRITICAL ** GLib-GObject - g_object_ref: assertion
> `G_IS_OBJECT (object)' failed
> java.lang.InternalError: GLib-GObject: g_object_ref: assertion
> `G_IS_OBJECT (object)' failed

My guess is that gdk_drawable_get_colormap returns something we're not
expecting.  Can you put a printf in
native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkGraphics.c in
Java_gnu_java_awt_peer_gtk_GdkGraphics_initFromImage to see what it
returns?  It looks like GDK is having trouble allocating colours in its
colormap.

Tom

>at gnu.java.awt.peer.gtk.GdkGraphics.initFromImage (Native Method)
>at gnu.java.awt.peer.gtk.GdkGraphics. (GdkGraphics.java:108)
>at gnu.java.awt.peer.gtk.GtkImage.getGraphics (GtkImage.java:405)
>at gnu.java.awt.peer.gtk.GtkComponentPeer.createImage
> (GtkComponentPeer.java:236)
>at java.awt.Component.createImage (Component.java:2083)
>at java.awt.Component.createImage (Component.java:2081)
>at javax.swing.RepaintManager.getOffscreenBuffer (RepaintManager.java:487)
>at javax.swing.JComponent.paint (JComponent.java:1442)
>at java.awt.Container$GfxPaintVisitor.visit (Container.java:1765)
>at java.awt.Container.visitChild (Container.java:1569)
>at java.awt.Container.visitChildren (Container.java:1531)
>at java.awt.Container.paint (Container.java:764)
>at gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent
> (GtkComponentPeer.java:313)
>at java.awt.Component.dispatchEventImpl (Component.java:4845)
>at java.awt.Container.dispatchEventImpl (Container.java:1592)
>at java.awt.Window.dispatchEventImpl (Window.java:628)
>at java.awt.Component.dispatchEvent (Component.java:2343)
>at java.awt.EventQueue.dispatchEvent (EventQueue.java:475)
>at java.awt.EventDispatchThread.run (EventDispatchThread.java:75)
> jamvm[1625]: GLIB CRITICAL ** Gdk - gdk_colormap_alloc_colors:
> assertion `GDK_IS_COLORMAP (colormap)' failed
> java.lang.InternalError: Gdk: gdk_colormap_alloc_colors: assertion
> `GDK_IS_COLORMAP (colormap)' failed
>at gnu.java.awt.peer.gtk.GdkGraphics.setFGColor (Native Method)
>at gnu.java.awt.peer.gtk.GdkGraphics.setColor (GdkGraphics.java:372)
> .
> 
> 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
> I have to admit that I am a gtk noob.
> As far as I can see either classpath makes some assumptions how GTK
> should be (low probability) or Nokia's GTK implementation is broken
> (more likely). Any ideas where the root of the problem could come
> from?
> 
> Thank you in advance, lg Clemens
> 
> 
> ___
> Classpath mailing list
> Classpath@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Comment to 0.19

[Thomas Fitzsimmons]

On Mon, 2005-11-07 at 14:11 +, theUser BL wrote:
> > > Additional to bugs, which Sun have, GNU Classpath have its own bugs. I 
> >have
> > > seen, that the AWT don't recognice, when the window was moved.
> > > For example the Listing2902 at
> > > http://www.mycore.de/library/go-to-java-2/html/k100181.html
> > > works only right at start. But if you move the window, the program don't
> > > recogniczed it.
> > > Only to mention it. Because without completly functional AWT, a 
> >completly
> > > functional Swing isn't possible.
> >
> >Please file this as a bug report if you haven't already.
> >
> >Thanks for your comments. If you feel we should fix the first bug (that
> >would be possible since we are talking about a not-specified area),
> >please also file a bug report.
> 
> I haven't done it. And I would be happy, if anybody other doing it.

This is a hard bug -- we need to update the x and y fields of the Window
without causing it to call back into the peers to move the GtkWindowPeer
to a specific location.  I've never been able to receive reliable
configure events from the window manager on window-move events.  The
symptom of blindly updating a Window's position with setBounds calls
from the peers is a move-set loop that causes windows to either wiggle
back and forth between two positions or to glide across the screen
before hitting an edge (at which point window manager limits kick in).

My previous workaround was ugly but it did work.  I had a package
private method in Window called setBoundsCallback that the peers called
and would not in turn attempt to move the window peer (see CVS history).
For now we could revive that patch, though Sven would likely object.

To fix this properly, we need to analyze how window managers produce
configure events and why the ones we receive are not consistent.  This
may require a window manager fix, or it may require us to ignore certain
events.  However I'd like to avoid heuristics since they didn't work
reliably for me in the past.

I recommend testing on metacity which has great developer support
features (e.g. good debug output logging, simple Xnest setup).

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: libtool warning in libjawtgnu

[Thomas Fitzsimmons]

On Sun, 2005-11-06 at 14:04 +, Frederick C. Druseikis wrote:
> Greetings,
> 
> Can someone help me understand the significance of the libtool Warning below? 
> Google reveals no relevant commentary on this issue.
> 
> --
> 
> gmake[3]: Entering directory
> `/usr/ports/mystuff/classpath-0.18/w-classpath-0.18/classpath-0.18/native/jawt'
> 
> 
> 
> *** Warning: Linking the shared library libjawtgnu.la against the loadable 
> module
> *** libgtkpeer.so.0.0 is not portable!
> 
> 
> 
> gmake[3]: Leaving directory
> `/usr/ports/mystuff/classpath-0.18/w-classpath-0.18/classpath-0.18/native/jawt'
> 
> --
> 
> I'm porting to openbsd; there are packaging issues but classpath-0.1[89] both
> compile successfully and install through the stock gnu install into 
> /usr/local.
> 
> Can someone tell me what's trying to be accomplished -- specifically why this
> non-portability is currently permitted?  Is this just a transient until jawt 
> is
> put somewhere else?  Or libtool is fixed?

Libtool is complaining about linking a shared library to a loadable
module.  This works perfectly fine on GNU/Linux but is apparently
unsupported on MacOS X (and possibly other systems).

Perhaps a developer whose system can't handle shared library-to-loadable
module linking can test libjawtgnu.so and submit a patch.  I don't have
access to any such system.

The patch would likely split libgtkpeer.so into a small wrapper loadable
module and a larger shared library.  Both the wrapper and libjawtgnu.so
would link to the common shared library.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [Fwd: Re: batik with GNU Classpath]

[Thomas Fitzsimmons]

On Tue, 2005-11-22 at 06:26 -0800, Anthony Green wrote:
> Jeremias Maerki is taking on the Batik-on-Classpath challenge!
> 
> But he will really need a working BasicStroke soon:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22938
> 
> IIRC, fitzsim said he was going to work on this relatively soon, is that
> right?

I may do this as part of the Graphics2D/Cairo work but it will be a
while before I get to it.  I suppose writing BasicStroke is a major
component of the "Batik-on-Classpath" challenge.

Tom

> 
> AG
> 
> 
> email message attachment, "Forwarded message - Re: batik with GNU
> Classpath"
> On Tue, 2005-11-22 at 06:26 -0800, Anthony Green wrote:
> > This is just to let you know that I've started to work on that. It's not
> > like it's my highest priority but I want to put some energy into this.
> > 
> > During the weekend I've started to do the necessary changes to remove
> > the dependency on the com/sun/* classes. The following is mostly for the
> > Batik people to comment on the approach I have in mind:
> > 
> > - I've locally started to move the codec classes (TIFF and PNG) to the
> > sources-1.3 directory.
> > - I'm writing an adapter to encode images to TIFF/PNG to hide the
> > dependency.
> > - For JDKs >= 1.4 (and for GNU Classpath) I propose to write additional
> > adapters that use the ImageIO API to handled the image decoding/encoding.
> > These adapters will land in sources-1.4.
> > - The adapter implementations will be discovered through the Service
> > class.
> > 
> > Binaries compiled under Sun JDK 1.3.1 would still run on Sun JDKs 1.4.2 and
> > 5. For GNU Classpath the sources will be compiled in JDK 1.4 fashion. I
> > assume that ImageIO support for GNU Classpath is there, right?
> > 
> > So far I've had problems compiling stuff under CygWin because GNU
> > Classpath seems to require GCC 4.0. CygWin only contains GCC 3.x. ATM, I
> > don't have access to any Unix machine with GCJ installed. On the other
> > side, I've been able to make experiments with IKVM which also uses GNU
> > Classpath. But there seems to be bigger problems with its AWT
> > implementation so that I currently don't have high hopes that Batik will
> > run under IKVM which would also have been nice.
> > 
> > On 24.10.2005 15:38:59 Anthony Green wrote:
> > > On Mon, 2005-10-24 at 09:52 +0200, Jeremias Maerki wrote:
> > > > since I've heard a number of times now about the desire to run Batik/FOP
> > > > on GNU Classpath I'd like to help make sure this can happen. However,
> > > > the last time I tried to do anything in this direction I was utterly
> > > > stuck. Do you have any pointers, hints, advice for me how to build a
> > > > normal Java project that has an Ant build using GNU Classpath on 
> > > > Windows?
> > > 
> > > As far as I know there's no simple solution for Windows right now.
> > > However, there's still an easy way to help.
> > > 
> > > I believe that the main problem with Batik vis-a-vis GNU Classpath, is
> > > the use of com.sun.* classes for JPEG handling.  The answer here is to
> > > use standard (1.4+) APIs for JPEG handling (and use the old classes when
> > > running on a <=1.3 JRE).  Batik has a directory for 1.4 classes now.  It
> > > seems that all the support could go in there, and some combination of
> > > build.xml and runtime check magic could figure out what classes to build
> > > and run.
> > > 
> > > The Wikipedia people want to use batik on gcj/GNU Classpath to render
> > > svg for wikipedia entries, but they're stuck on this as well.
> > > 
> > > Of course, the GNU Classpath people need to fix the missing bits in
> > > java.awt.BasicStroke.  I think this could happen relatively quickly
> > > given all the demand.
> > > 
> > > Thanks!
> > > 
> > > AG
> > 
> > 
> > 
> > Jeremias Maerki
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FreeSWTTestApps page added to wiki

[Thomas Fitzsimmons]

On Tue, 2005-11-22 at 13:02 -0500, Jeff Myers wrote:
> The Eclipse code that uses the XEmbeddedFrame is most likely the
> SWT_AWT bridge.  This class is a platform-dependent hack that's used
> to embed AWT/Swing within SWT apps, and vice versa.
> 
> See: 
> http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/awt/SWT_AWT.html
> 
> It'd be interesting to see how Classpath could provide APIs that allow
> similar function to SWT - as this function can not be achived using
> the public Java api.

We do provide similar functionality with gnu.java.awt.EmbeddedWindow
which gcjwebplugin uses to embed itself in Firefox.  That said, I
wouldn't encourage use of this class since it is private and subject to
change.

Tom

> 
>  - Jeff Myers
> 
> On 11/22/05, Meskauskas Audrius <[EMAIL PROTECTED]> wrote:
> > Egon Willighagen wrote:
> >
> > >Not implemented [need JDK 1.5 or greater] 
> > >(java.lang.ClassNotFoundException:
> > >sun/awt/X11/XEmbeddedFrame)
> > >
> > >
> > >
> > The problem is, the application is using the proprietary Sun class  from
> > the protected sun.* namespace. The Sun's license does not permit to add
> > classes from this package. Also, the class is probably totally
> > undocumented and we have no right to look into the Sun sources doing
> > "exactly the same".  If this does not come from Eclipse, we need can
> > rewrite the calling code.
> >
> > Best wishes
> > Audrius
> 
> 
> ___
> Classpath mailing list
> Classpath@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: RFC: merging GNU Crypto and Jessie

[Thomas Fitzsimmons]

Hi,

On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote:

> We can then also merge other parts of GNU Crypto to projects where  
> they make sense; its testsuite can go into Mauve (it was written to  
> use (a possibly old version of) Mauve's own test harness classes),  
> and the various tools can go into cp-tools.

I'd prefer to see the tools (and all of cp-tools, actually) go directly
into GNU Classpath's source repository (under
savannah.gnu.org:/cvsroot/classpath).  This makes it easier to import
them into the libgcj and (presumably) Kaffe repositories and it also
means one less checkout.  In the future when GNU Classpath gets a
bootstrap VM, it will mean the tools can be used in the bootstrap
process, if need be.

Otherwise this proposal looks great.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Proposal: Graphics2D rewrite branch

[Thomas Fitzsimmons]

Hi,

I'd like to propose a new branch in the GNU Classpath CVS repository:
graphics2d-rewrite.  Patches to this branch should be sent to
classpath-patches@gnu.org with a subject line prefix of [g2d rewrite].
Commit policy is the same as GNU Classpath trunk.

On this branch I'd like to do several things:

1) Make Graphics2D the default
2) Remove Graphics
3) Split Graphics2D according to
http://developer.classpath.org/mediation/ClasspathGraphicsImagesText

Once these items are done and tested to work as well or better than the
current Graphics/Graphics2D implementations, I'll merge the branch into
trunk and continue development there.

Any objections?

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Proposal: Graphics2D rewrite branch

[Thomas Fitzsimmons]

On Thu, 2005-12-08 at 13:20 +, theUser BL wrote:
> >On this branch I'd like to do several things:
> >
> >1) Make Graphics2D the default
> >2) Remove Graphics
> 
> What do you mean with this?

I meant remove GdkGraphics.

> Does this mean, that Graphics is based on Graphics2D and so for plain AWT or 
> Swing programs Cairo is needed?
> 
> I don't hope so. I have the hope, that it goes in any time the other way 
> around, that Graphics2D is based on Graphics and created with the plain 
> AWT-Graphics.

Yes, inheritance in java.awt will work the same way, with Graphics2D
inheriting from Graphics.  It's just that we'll only have a peer that
wraps Cairo and not a peer that wraps GDK drawing primitives.  So the
inheritance graph will be:

Graphics <- Graphics2D <- CairoGraphics2D <- ...

with the ... representing specialized graphics objects for different
surfaces.

> So it would also be easier to port free Javas to Windows and MacOSX. 
> Something like Sun does with its implementation. So that on Windows and 
> MacOSX "only" the bindings to GTK+ are ported to the Windows-API and the 
> Aqua-API.
> But if Cairo is needed, it seems, that you also need later on Windows and 
> MacOSX Cairo. And that is something what I don't like.

This rewrite will make the GTK AWT peers depend on GTK-2.8 which in turn
depends on Cairo so avoiding a Cairo dependency is impossible if we want
to move to newer GTK releases.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Hacking Classpath in Eclipse

[Thomas Fitzsimmons]

On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote:
> > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
> 
> Mark> I found a cute hack to actually run a single mauve Testlet from within
> Mark> eclipse using the just compiled classpath:
> 
> Mark> $ mkdir -p ~/workspace/classpath/install/jre/lib
> Mark> $ touch ~/workspace/classpath/install/jre/lib/rt.jar
> 
> Mark> Now as by magic you can add ~/workspace/classpath/install as JRE to
> Mark> eclipse (under Preferences -> Java -> JREs) and then configure Runners
> Mark> to use that alternative jre.
> 
> Note that this will work for running something, but not if you want
> to compile against that JRE.
> 
> For the latter I think we need to come up with some kind of "fake jdk"
> project.  I actually have the start of one here, but I haven't
> finished polishing it yet.

This is an example of why it would be very useful to make Classpath
fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into
the Classpath repository/build system.  Long term I guess this is where
we're headed but this is just another data point that we're going in the
right direction.

> 
> Ideally Eclipse would offer the possibility of auto-exporting the
> build results as a .jar.  That would solve this entirely.

Yes, I've wanted that in several other situations.  Let's file an
enhancement bug with Eclipse.

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Hacking Classpath in Eclipse

[Thomas Fitzsimmons]

On Thu, 2005-12-22 at 09:05 -0700, Tom Tromey wrote:
> Tom> This is an example of why it would be very useful to make Classpath
> Tom> fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into
> Tom> the Classpath repository/build system.  Long term I guess this is where
> Tom> we're headed but this is just another data point that we're going in the
> Tom> right direction.
> 
> For Eclipse-based builds we really don't want all of this; in
> particular we don't want or need a compiler here.  Using the built-in
> Eclipse compiler is superior.
> 
> >> Ideally Eclipse would offer the possibility of auto-exporting the
> >> build results as a .jar.  That would solve this entirely.
> 
> Tom> Yes, I've wanted that in several other situations.  Let's file an
> Tom> enhancement bug with Eclipse.
> 
> Are you filing it?  If so tell me the PR and I will add myself.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=121901

Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

How to check out Cacao

[Thomas Fitzsimmons]

Hi,

Is this page:

http://www.complang.tuwien.ac.at/cacaojvm/cvs.html

correct?  When I follow the instructions there I get this:

$ cvs -d :pserver:[EMAIL PROTECTED]:/ahome/cacao/cacaocvs co cacao
/ahome/cacao/cacaocvs: no such repository

ViewCVS seems to access a subversion repository.  Is it publicly
accessible?  Or is there a public CVS repository?  Help would be
appreciated.

Thanks,
Tom




___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: ANN: image viewer

[Thomas Fitzsimmons]

On Wed, 2006-01-25 at 17:03 +0100, Norman Hendrich wrote:

> BTW: any news about the big Java2D rewrite?

Yes, I'm currently working on getting Batik building on GNU Classpath.
That involves first implementing javax.imageio.plugins.jpeg.  Once I
have it building I'm going to work on getting its testsuite results to
100%.  I think that will be a very good test of our headless Java2D
implementation.  Once that's done I'll rework the X window-backed
Graphics2D code.  It's a big job so bear with me.

Tom



___
Classpath mailing list
Classpath@gnu.org
http://developer.classpath.org/mailman/listinfo/classpath

Re: ANN: image viewer

[Thomas Fitzsimmons]

On Thu, 2006-01-26 at 15:12 +0100, Ziga Mahkovec wrote:
> On Thu, 2006-01-26 at 08:34 -0500, Thomas Fitzsimmons wrote:
> > On Wed, 2006-01-25 at 17:03 +0100, Norman Hendrich wrote:
> > > BTW: any news about the big Java2D rewrite?
> > 
> > Yes, I'm currently working on getting Batik building on GNU Classpath.
> > That involves first implementing javax.imageio.plugins.jpeg.  Once I
> > have it building I'm going to work on getting its testsuite results to
> > 100%.  I think that will be a very good test of our headless Java2D
> > implementation.  Once that's done I'll rework the X window-backed
> > Graphics2D code.  It's a big job so bear with me.
> 
> Hi Tom,
> 
> this sounds great.  I thought you might be interested in some Java2D
> test suite work I did some time ago:
> 
>   http://lists.gnu.org/archive/html/classpath/2005-06/msg00048.html
> 

Thanks for the pointer.  My long term testing plan is to add nightly
runs of the Batik test suite to builder.classpath.org.

Tom

Re: Planning to check-in new branch: the GIOP extensions for rmic.

[Thomas Fitzsimmons]

On Mon, 2006-02-06 at 18:04 +0100, Audrius Meskauskas wrote:
> I have just finished writing the GIOP stub and tie code generator that 
> is needed to develop the applications, using javax.rmi.CORBA package. It 
> generates stubs and two required types of ties. I tested it with our x5 
> CORBA game: the generated stubs and ties seem interoperating well with 
> the code, generated by the Sun's rmic.
> 
> Implementing this functionality fixes the bug 25704.
> 
> Initially, I wanted to put the new classed to cp-tools branch.

I'd prefer if this tool were committed directly to GNU Classpath CVS.
It's much more convenient for bundlers of GNU Classpath (GCJ, Kaffe) if
the tools sources are right in cvs.savannah.gnu.org:/sources/classpath.
It means that we can do one source drop (GNU Classpath) instead of two
(GNU Classpath + cp-tools) and it will likely mean everyone will just
use the Classpath tools rather than everyone writing their own (e.g.
fastjar vs. jar).  In fact, long term, I'd rather see all of the tools
in cp-tools merged into cvs.savannah.gnu.org:/sources/classpath and used
by all bundlers of GNU Classpath.  Toward that end, I plan to propose
merging gcjappletviewer into GNU Classpath once the security work is
done.

Tom

Re: GtkComponentPeer realization

[Thomas Fitzsimmons]

On Thu, 2006-02-09 at 13:52 +0100, Mark Wielaard wrote:
> Hi,
> 
> After a lot of debugging I finally found out why a program I was testing
> was crashing sometimes. (The hsqldb AWT frontend - try the
> org.hsqldb.util.DatabaseManager class from the hsqldb.jar as distributed
> with OpenOffice for example.) A GtkGraphics object is created
> differently for realized and un-realized components. When we get a paint
> event for an unrealized component and try to use the associated
> GdkGraphics object bad things happen (because NSA_GET_G_PTR returns null
> in such cases).
> 
> The attached hack makes things work for now by just ignoring such paint
> events for such objects. It gives:
> 
> NOT handling 
> java.awt.event.PaintEvent[UPDATE,updateRect=java.awt.Rectangle[x=0,y=0,width=360,height=300]]
>  on org.hsqldb.util.Grid[panel0,0,0,360x300,invalid,parent=panel1] for 
> UNREALIZED org.hsqldb.util.Grid[panel0,0,0,360x300,invalid,parent=panel1]
> 
> I like to debug this a bit further, but I couldn't find good
> documentation on the handling of (un)realized GtkComponentPeers. Does
> anybody have a link or an explanation of whether or not the above should
> ever happen?

Yes it can happen especially in multi-threaded applications.  You're
probably right to just ignore the paint event.  It'd be useful to know
if hsqldb makes calls into the peers from different threads.  For
example if it shows a window in one thread and another thread handles
painting on that window.

An unrealized GtkComponentPeer is a GtkWidget that has an uninitialized
X window field.  In other words, the X server doesn't have a window data
structure allocated for it.  We used to force-realize every
GtkComponentPeer on construction but that lead to strange behaviour when
adding a hierarchy of components to an already-shown container (all
components would be shown first at 0,0-1x1 then layed out after that).
Delayed realization makes the peer code much more complicated, and
adding a container to an already-shown container is rare so I'm thinking
it may be acceptable to switch the code back to
force-realization-on-creation.  It would simplify GtkComponentPeer
GdkGraphics and would probably eliminate these situations that you're
describing.

Tom

Re: GtkComponentPeer realization

[Thomas Fitzsimmons]

On Fri, 2006-02-10 at 00:26 +0100, Mark Wielaard wrote:
> Hi Tom,
> 
> On Thu, 2006-02-09 at 09:53 -0500, Thomas Fitzsimmons wrote:
> > On Thu, 2006-02-09 at 13:52 +0100, Mark Wielaard wrote:
> > > I like to debug this a bit further, but I couldn't find good
> > > documentation on the handling of (un)realized GtkComponentPeers. Does
> > > anybody have a link or an explanation of whether or not the above should
> > > ever happen?
> > 
> > Yes it can happen especially in multi-threaded applications.  You're
> > probably right to just ignore the paint event.  It'd be useful to know
> > if hsqldb makes calls into the peers from different threads.  For
> > example if it shows a window in one thread and another thread handles
> > painting on that window.
> 
> No it doesn't. I was finally able to extract a simple testcase that
> shows the problem which also doesn't use any extra application Threads.
> See attached. If you update the tree to include Lillian's latest patches
> for GtkPanelPeer (which made the logic more clear to me, thanks Lillian)
> and add the following hack, you can see that the Panel doesn't seem to
> get realized. And always will print out the following after clicking on
> the button:
> 
> getGraphics() called on unrealized:
> java.awt.Panel[panel0,4,25,66x25,invalid,parent=frame0,layout=java.awt.FlowLayout]
> 
> I am not sure how/where the GtkPanelPeer should have been realized
> and/or whether this comes from the "delayed realization" you talked
> about (I don't actually see where this Panel will ever get realized to
> be honest).

Yes, panels are never realized because they do not have an X window
associated with them.  Instead they draw on their parent's X window.  So
GtkPanelPeer should probably override isRealized to check if it has a
parent and if so, if that parent is realized.

Tom

> 
> The Hack (or workaround, if you only put in the return null, and not the
> dumpStack):
> 
> --- gnu/java/awt/peer/gtk/GtkComponentPeer.java   9 Feb 2006 17:44:30 
> -   1.101
> +++ gnu/java/awt/peer/gtk/GtkComponentPeer.java   9 Feb 2006 23:14:19 
> -
> @@ -263,6 +262,13 @@
>  
>public Graphics getGraphics ()
>{
> +if (! isRealized())
> +  {
> + System.err.println("getGraphics() called on unrealized: " + awtWidget);
> + Thread.dumpStack();
> + return null;
> +  }
> +
>  if (GtkToolkit.useGraphics2D ())
>  return new GdkGraphics2D (this);
>  else
> 
> Any insights on how to properly debug this welcome.
> 
> I do have one patch to make the event passing a bit simpler. That
> doesn't change the result of this test case, but it makes it a little
> easier to follow the events that are fired. I'll post it in a second to
> the patches list.
> 
> Cheers,
> 
> Mark

Re: GtkComponentPeer realization

[Thomas Fitzsimmons]

On Sat, 2006-02-11 at 23:00 +0100, Mark Wielaard wrote:
> Hi Tom,
> 
> On Fri, 2006-02-10 at 12:52 -0500, Thomas Fitzsimmons wrote:
> > > I am not sure how/where the GtkPanelPeer should have been realized
> > > and/or whether this comes from the "delayed realization" you talked
> > > about (I don't actually see where this Panel will ever get realized to
> > > be honest).
> > 
> > Yes, panels are never realized because they do not have an X window
> > associated with them.  Instead they draw on their parent's X window.  So
> > GtkPanelPeer should probably override isRealized to check if it has a
> > parent and if so, if that parent is realized.
> 
> But then they should also override getGraphics() I presume to return the
> (translated) Graphics of their parent Container? And currently they
> don't. Also we seem to explicitly request an X window to be associated
> since in GtkPanelPeer.c we say:
>   gtk_fixed_set_has_window (GTK_FIXED (widget), TRUE);
> We also request GTK_CAN_FOCUS. Is that possible on widgets without a
> window?
> 
> And in fact Graphics object returned from a Panel is often correct. Only
> in situations like the example I gave does it never get realized
> correctly it seems.
> 
> Puzzling...

You're right.  GtkPanelPeers do have their own windows now; I was
thinking of a previous revision of this code.  To answer your original
question, GtkPanelPeers are realized when they are shown.

Tom

> 
> Cheers,
> 
> Mark

Re: GtkComponentPeer realization

[Thomas Fitzsimmons]

On Mon, 2006-02-20 at 17:47 +0100, Mark Wielaard wrote:
> On Mon, 2006-02-20 at 15:20 +0100, Roman Kennke wrote:
> > > I don't see how/if 2) ever happens/should happen after a
> > > Container.add(Component). The Container is invalid after an add().
> > > When/Where should validate[Tree]() be called after a new component has
> > > been added?
> > 
> > This is not performed automatically in AWT. We used to do it in
> > setVisible somewhere if I remember correctly, but tests have shown that
> > this is not right (and in fact leads to strange interactions with Swing,
> > where we _do_ perform validation automatically).
> 
> OK. Thanks. That probably explains why the delayed parenting and
> realization did work in the past.
> 
> >  The GTK peers therefore
> > should initialize correctly even when the component is not validated and
> > not try to defer things. (Actually, the AWT itself defers initialization
> > of the peers themselves, they are not created with the component, but
> > instead when the component receives a call to addNotify).
> 
> Yes. We do defer creation of the gtk-peer till the actual addNotify()
> call. But then we also defer the parent/bound-setting if the container
> is already visible till the container is actually made valid. This is at
> least a problem with (sub) classes of Panel and Canvas where
> applications seem to expect to be able to paint on them before they are
> actually validated.

This is a very strange requirement; they require the ability to draw on
a Component that may not be sized correctly?  Presumably that component
will not be in that invalid state for long, and so will be repainted
correctly when it is validated?

> 
> Tom, do you have an example where the delayed realization of the gtk+
> component was necessary/gave strange visual effects? I like to get to
> the bottom of this one.

Yes, the problem was with adding a container of widgets to another
already-showing container.  Since we were force-realizing widgets on
creation, each widget would be shown at 0,0 with size 1x1, then moved
into place and resized upon validation.  At the time there were bugs in
the peer resizing code that made some widgets, including buttons, show
up at their natural sizes.  The result was that for a big button box in
vte, you'd see all the buttons stack up at 0,0 at their natural sizes,
then be moved and resized into the right spot.

There are two cases that we must handle when adding a container to
another container and both cases must be handled differently when
implementing them on GTK:

1) the parent container is not showing

2) the parent container is showing

For case 1 forced realization works fine because the widgets aren't
actually shown until the parent is showing, and at that point everything
is correctly laid out.

For case 2 forced realization causes child components to be shown as
soon as their peers are created.  Container.validateTree does this:

  ContainerPeer.beginValidate()

  create peers for all child components in this container

  do layout, setting the child component and child component peers'
bounds

  validate child containers recursively

  ContainerPeer.endValidate()

With forced realization all the peers are shown when they are first
created, *then* moved and resized when layout is called.  This was a bug
in our AWT implementation which didn't affect other peer sets.

In an attempt to solve this, and to be more in-line with GTK
conventions, I eliminated forced realization.  The idea is that widgets
should be realized when GTK decides to realize them: after they've been
properly sized and parented.  So with the current code, I leave
realization up to GTK and I only set bounds and parents on the peer side
after all the AWT validation has occurred, in
GtkContainerPeer.endValidate().

Unfortunately, as Mark points out, this approach relies on validation to
occur before getGraphics is called on a component, which (apparently)
isn't guaranteed.  In fact, getGraphics must work as soon as addNotify
has been called on it which can happen anytime independent of
validation.  So delayed realization is unworkable and we should change
back to forced-realization.

Maybe we can solve the original problem using
gtk_widget_show/gtk_widget_hide.  I wonder how other toolkits (e.g.
Sun's Motif implementation) solve this validate-while-showing problem.
Perhaps it's not worth worrying about at this point (though I find
validating-while-showing very sloppy).

Tom

Re: RFC: jessie-nio branch, keytool

[Thomas Fitzsimmons]

On Sun, 2006-02-26 at 13:42 -0800, Casey Marshall wrote:
> Hi.
> 
> I had been doing a little work on rewriting Jessie to support the new  
> JSSE API in J2SE 1.5, which adds support for SSL-over-NIO. A rewrite  
> is probably the only way to support this; I looked at the current  
> code to see if I could just insert a shim over the blocking-IO code,  
> but it doesn't look like that will fly; at least not without creating  
> a new thread or two per SSL connection, in which case, what would be  
> the point?
> 
> So, now that Jessie's been merged into Classpath, I'd like to create  
> a `jessie-nio' branch to continue this work. I assume it's OK for me  
> to go ahead and make this branch, modulo any naming suggestions.
> 
> Also, in GNU Crypto we were working on a replacement for `keytool;'  
> do we want to merge that into Classpath, too? It is currently using  
> Aaron Renn's Java Getopt package to do option parsing. Do we want to  
> bring a version of this into Classpath (I think it would be a good  
> idea, because then all tools we support could have a standard GNU  
> command-line interface for all tools, which even a Java project  
> should try to do), or should the parts here be rewritten? Getopt is  
> LGPL, but I don't see that as a barrier for using a copy in Classpath.

I'm in favour of merging both keytool and getopt into GNU Classpath.
gcjappletviewer uses getopt to provide a GNU command-line interface and
I agree that all the tools should use it.

I'd like to see keytool (and all the other Classpath Tools) merged
directly into cvs.savannah.gnu.org:/sources/classpath, rather than
having them in a separate repository.  This will ready GNU Classpath to
be self-bootstrapping when we introduce a bootstrap runtime.

Tom

Re: Next release

[Thomas Fitzsimmons]

On Mon, 2006-02-27 at 20:36 +, Chris Burdess wrote:
> Archie Cobbs wrote:
> >> - Decide on the version number.
> >>   We had a very small/brief discussion about this during Fosdem.
> >>   Everybody seems to agree 0.x really doesn't do justice to the  
> >> maturity
> >>   we have reached over the years. And it is really hard to define  
> >> when
> >>   we hit "1.0". So the proposal is to keep using a "sequence version
> >>   number". Either just drop the "0." and make the next release-number
> >>   classpath-21, or adopt a year.month style version number and  
> >> make the
> >>   next version number classpath-6.3 for the March 2006 release.
> >>   In either case we will just use a code name for a release that has
> >>   some special feature set that we are proud of, but we will always
> >>   just increase the release snapshot number. Suggestions or Opinions?
> >
> > Opinion requested, here granted :-)
> >
> > Changes in version number format, etc. have a cost in that can
> > confuse (or at least complicate) packaging and versioning software
> > like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users).
> >
> > If all we want is a sequence numbering, then 0.xx has been working
> > fine so why change it?
> >
> > If we want to be prouder, let's just release 1.0 and be done with it.
> > Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole  
> > grandness
> > of "1.0" will fade quickly.
> >
> > So I vote either keeping the status quo, or releasing 1.0.
> > A "classpath-6.3" seems to be the worst of both worlds.
> 
> I agree with the above but my preference would be for "1.4.x". We are  
> at about 99% of 1.4 API coverage, and we have many features that  
> weren't shipped by Sun until 1.5. When we are in the same situation  
> with respect to 1.5, we should call ourselves 1.5.x and so forth.  
> This makes the situation much more clear to casual users as to what  
> they can expect in terms of features.

I agree that this would be the best versioning scheme.  If we're 1.4
API-complete then we want to advertise that fact, since it will help
users know what to expect.

Tom

Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD

[Thomas Fitzsimmons]

Hi,

On Thu, 2006-03-02 at 00:06 -0500, James Damour wrote:
> Lillian Angel has done a truely remarkable job squashing rendering
> problems, so what once looked like [1] now looks like [2].  I have
> therefore built CVS HEAD of Classpath and Cacao in my Debian Sid chroot,
> changed MegaMek "stable" (the "-r rel-0-30-0" branch) to use reflection
> instead of a compile-time dependancy on sun.audio.* classes, and built
> MegaMek.

I'm looking at reviving the mkcollections script so that you can replace
collections.jar with a free replacement.

> 
> There are still a few little bugs (which appear to depend on one's
> operating environment:-( ).  I'll be writing up Bugzilla reports over
> the next few days/weeks to help run down the last few problems.

Great, thanks.

> 
> I also looked into the compatability between MegaMek clients and servers
> running on proprietary and free VMs.  There was an initial hiccup where
> I was getting incompatable serialVersionUID, but I quickly realized that
> the problem was caused by my compiling MegaMek twice, once with Sun
> tools, and once with Free tools.  When I gave both VMs the same set of
> classes (or JAR file), they could connect without difficulty.

Isn't this the point of serialVersionUID though?  If someone builds and
runs MegaMek with Sun's tools and another person builds and runs MegaMek
with free tools, the two MegaMek instances should be able to serialize
and unserialize each other's data.  Where this isn't the case don't we
need to update our serialVersionUID fields?

Tom

Re: GtkComponentPeer realization

[Thomas Fitzsimmons]

On Fri, 2006-03-03 at 21:30 +0100, Mark Wielaard wrote:
> Hi Tom,
> 
> On Mon, 2006-02-20 at 15:50 -0500, Thomas Fitzsimmons wrote:
> > On Mon, 2006-02-20 at 17:47 +0100, Mark Wielaard wrote:
> > > Yes. We do defer creation of the gtk-peer till the actual addNotify()
> > > call. But then we also defer the parent/bound-setting if the container
> > > is already visible till the container is actually made valid. This is at
> > > least a problem with (sub) classes of Panel and Canvas where
> > > applications seem to expect to be able to paint on them before they are
> > > actually validated.
> > 
> > This is a very strange requirement; they require the ability to draw on
> > a Component that may not be sized correctly?  Presumably that component
> > will not be in that invalid state for long, and so will be repainted
> > correctly when it is validated?
> 
> I am not sure it is an requirement. But there are clearly programs that
> call paint(), update() and/or getGraphics() on Components at the
> weirdest times.
> 
> > > Tom, do you have an example where the delayed realization of the gtk+
> > > component was necessary/gave strange visual effects? I like to get to
> > > the bottom of this one.
> > 
> > Yes, the problem was with adding a container of widgets to another
> > already-showing container.  Since we were force-realizing widgets on
> > creation, each widget would be shown at 0,0 with size 1x1, then moved
> > into place and resized upon validation.  At the time there were bugs in
> > the peer resizing code that made some widgets, including buttons, show
> > up at their natural sizes.  The result was that for a big button box in
> > vte, you'd see all the buttons stack up at 0,0 at their natural sizes,
> > then be moved and resized into the right spot.
> >
> > In an attempt to solve this, and to be more in-line with GTK
> > conventions, I eliminated forced realization.  The idea is that widgets
> > should be realized when GTK decides to realize them: after they've been
> > properly sized and parented.  So with the current code, I leave
> > realization up to GTK and I only set bounds and parents on the peer side
> > after all the AWT validation has occurred, in
> > GtkContainerPeer.endValidate().
> > 
> > Unfortunately, as Mark points out, this approach relies on validation to
> > occur before getGraphics is called on a component, which (apparently)
> > isn't guaranteed.  In fact, getGraphics must work as soon as addNotify
> > has been called on it which can happen anytime independent of
> > validation.  So delayed realization is unworkable and we should change
> > back to forced-realization.
> 
> OK, I did this and I tried to make the impact as little as possible.
> This patch handles the most common case where the Component bounds have
> not been set yet (so are zero) then it wont show the component yet. This
> doesn't solve all the cases as seen with vte when a Component is set to
> a particular size before being added though. (It does solve one other
> issue I was seeing where my app was "hiding" an Component by setting its
> size to 0, previously we would ignore such a reshape call...)
> 
> I think this is the best we can do for now without doing something much
> more tricky such hooking into things like endLayout which we don't
> currently seem to support anyway. And it solve the crashes I was seeing
> which I think is a more important issue then the "jumping components"
> problem.

Yes, I agree.  This patch looks good, and even avoids force-realizing
widgets with gtk_widget_realize, while satisfying the AWT's
peer-creation criteria.  One small request: that you expand
Component.addNotify's javadocs to describe these criteria clearly for
future reference.

Thanks,
Tom

Re: [maemo-developers] J2ME on Nokia 770

[Thomas Fitzsimmons]

Hi,

On Tue, 2006-03-07 at 13:46 +0100, Clemens Eisserer wrote:
> > Classpath's AWT of course runs on top of GTK+.
> 
> Not on the 770, it has several problems but I am not experienced
> enough to solve them:
> 
> - Expose events seem not to be sent by X or at least are not received
> by java. I did some debgugging and as far as I can tell no expose
> events are sent by X.

Interesting.  Does the 770 window manager allow overlapping windows or
dialogs?  Maybe there is no need for expose events except one on initial
startup.  Maybe we need to post paint events in response to something
other than an expose event, when running on the 770.  I'd appreciate
more information on this.

> 
> - When creating offscreen images they are created using 24 bit depth
> since GTK_RGB thinks this is best (why do we ask GTK_RGB for the
> default pixmap depth and do not simply use the depth the screen is
> running?). But 770's X server has no colormap assigned to 24-bit mode
> so it asserts.

Yes, I think we currently assume a 24-bit colormap in the GTK peers,
which is wrong.  I'd like to see this fixed.

> 
> - Swing propably needs to be extended to allow the virtual keyboard to
> send key events.

How is the virtual keyboard different from a standard keyboard, from X's
perspective?  I don't see how Swing would be affected.

Tom

Re: classpath on an ipaq

[Thomas Fitzsimmons]

On Tue, 2006-03-14 at 13:17 +, Ben Pirt wrote:
> Hi,
> I have been trying to get classpath working on a hx4700 iPaq using  
> the openembedded build system. I am using jamvm as my virtual  
> machine, but every time I try to run any app which is not headless I  
> get the following error:
> 
> (.:32755): Gdk-WARNING **: gdk_property_get(): length value has  
> wrapped in calculation (did you pass G_MAXLONG?)
> java.lang.InternalError: Gdk: gdk_property_get(): length value has  
> wrapped in calculation (did you pass G_MAXLONG?)
>   at gnu.java.awt.peer.gtk.gtkToolkit.gtkMain (Native Method)
>   at gnu.java.awt.peer.gtk.gtkToolkit$1.run (GtkToolkit.java:129)
> 
> I have tried several different versions of classpath (up to 0.20) and  
> am running the latest jamvm. Gtk+ is at version 2.6.10-r2

Can you try applying the attached patch to your GNU Classpath tree?
Then we'll know if this is happening in the peers or in the underlying
libraries.

Tom

Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c
===
RCS file: /sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c,v
retrieving revision 1.65
diff -u -r1.65 gnu_java_awt_peer_gtk_GtkWindowPeer.c
--- native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c	15 Feb 2006 20:55:07 -	1.65
+++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c	14 Mar 2006 17:25:31 -
@@ -1479,6 +1479,7 @@
   *bottom = 6;
   *right = 6;
 
+#if 0
   /* Request that the window manager set window's
  _NET_FRAME_EXTENTS property. */
   request_frame_extents (window);
@@ -1501,6 +1502,7 @@
   *top = extents [2];
   *bottom = extents [3];
 }
+#endif
 }
 
 static Atom extents_atom = 0;
@@ -1706,6 +1708,7 @@
   unsigned long *extents;
   union extents_union gu_ex;
 
+#if 0
   gu_ex.extents = &extents;
   if (gdk_atom_intern ("_NET_FRAME_EXTENTS", FALSE) == event->atom
   && gdk_property_get (event->window,
@@ -1726,6 +1729,7 @@
 (jint) extents[3],  /* bottom */
 (jint) extents[1]); /* right */
 }
+#endif
   
 
   return FALSE;

Re: classpath on an ipaq

[Thomas Fitzsimmons]

On Wed, 2006-03-15 at 14:48 +, Ben Pirt wrote:
> Hi Tom
> Thanks for the patch. I applied it, but it didn't change anything
> unfortunately, so I guess it's in the libraries.
> From what I can tell, it's in the GTK+ library. which gets called
> from gnu_java_awt_peer_gtk_GtkToolkit.c in
> the Java_gnu_java_awt_peer_gtk_GtkToolkit_gtkMain function. which
> basically calls gtk_main in the GTK+ library.
> 
> 
> I guess I'll try updating the GTK+ library.

This bug report may help you track the problem down:

http://bugzilla.gnome.org/show_bug.cgi?id=161520

Let us know if you do get this working.

Tom

> 
> 
> Thanks for your help,
> 
> 
> Ben
> 
> On 14 Mar 2006, at 17:31, Thomas Fitzsimmons wrote:
> 
> > On Tue, 2006-03-14 at 13:17 +, Ben Pirt wrote:
> > > Hi,
> > > I have been trying to get classpath working on a hx4700 iPaq
> > > using  
> > > the openembedded build system. I am using jamvm as my virtual  
> > > machine, but every time I try to run any app which is not headless
> > > I  
> > > get the following error:
> > > 
> > > 
> > > (.:32755): Gdk-WARNING **: gdk_property_get(): length value has  
> > > wrapped in calculation (did you pass G_MAXLONG?)
> > > java.lang.InternalError: Gdk: gdk_property_get(): length value
> > > has  
> > > wrapped in calculation (did you pass G_MAXLONG?)
> > > at gnu.java.awt.peer.gtk.gtkToolkit.gtkMain (Native Method)
> > > at gnu.java.awt.peer.gtk.gtkToolkit$1.run (GtkToolkit.java:129)
> > > 
> > > 
> > > I have tried several different versions of classpath (up to 0.20)
> > > and  
> > > am running the latest jamvm. Gtk+ is at version 2.6.10-r2
> > 
> > 
> > Can you try applying the attached patch to your GNU Classpath tree?
> > Then we'll know if this is happening in the peers or in the
> > underlying
> > libraries.
> > 
> > 
> > Tom
> > 
> > 
> > Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c
> > ===
> > RCS
> > file: 
> > /sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c,v
> > retrieving revision 1.65
> > diff -u -r1.65 gnu_java_awt_peer_gtk_GtkWindowPeer.c
> > --- native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c 15 Feb
> > 2006 20:55:07 - 1.65
> > +++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c 14 Mar
> > 2006 17:25:31 -
> > @@ -1479,6 +1479,7 @@
> >*bottom = 6;
> >*right = 6;
> > 
> >  
> > 
> > 
> > +#if 0
> >/* Request that the window manager set window's
> >   _NET_FRAME_EXTENTS property. */
> >request_frame_extents (window);
> > @@ -1501,6 +1502,7 @@
> >*top = extents [2];
> >*bottom = extents [3];
> >  }
> > +#endif
> >  }
> >  
> > 
> > 
> >  static Atom extents_atom = 0;
> > @@ -1706,6 +1708,7 @@
> >unsigned long *extents;
> >union extents_union gu_ex;
> >  
> > 
> > 
> > +#if 0
> >gu_ex.extents = &extents;
> >if (gdk_atom_intern ("_NET_FRAME_EXTENTS", FALSE) == event->atom
> >&& gdk_property_get (event->window,
> > @@ -1726,6 +1729,7 @@
> >   (jint) extents[3],  /* bottom */
> >   (jint) extents[1]); /* right */
> >  }
> > +#endif
> >
> > 
> > 
> >  
> > 
> > 
> >return FALSE;
> 
> 

Mauve wishlist

[Thomas Fitzsimmons]

Hi,

Anthony Balkissoon has expressed interest in improving Mauve so we'd
like to know what would be the best things to work on.

Here are two items on my list:

- A web reporting facility that generates JAPI-style bar graphs.
Ideally the graphs would represent a code-coverage analysis but I have
no idea how feasible that is using free tools.

- A framework for testing VM invocations and the tools' command-line
interfaces -- in other words, a framework that can exec commands.  This
may be best done as an independent module, separate from Mauve.

There is also lots of room for improvement in how Mauve tests are
selected and run.  I'm hoping someone who better understands Mauve's
design will elaborate.

Tom

Re: Mauve wishlist

[Thomas Fitzsimmons]

On Fri, 2006-03-17 at 11:32 -0500, Thomas Fitzsimmons wrote:
> Hi,
> 
> Anthony Balkissoon has expressed interest in improving Mauve so we'd
> like to know what would be the best things to work on.
> 
> Here are two items on my list:
> 
> - A web reporting facility that generates JAPI-style bar graphs.
> Ideally the graphs would represent a code-coverage analysis but I have
> no idea how feasible that is using free tools.
> 
> - A framework for testing VM invocations and the tools' command-line
> interfaces -- in other words, a framework that can exec commands.  This
> may be best done as an independent module, separate from Mauve.

I thought of another item:

- A serialization test suite that given two class library
implementations will test serialization compatibility in both
directions.

Tom

> 
> There is also lots of room for improvement in how Mauve tests are
> selected and run.  I'm hoping someone who better understands Mauve's
> design will elaborate.
> 
> Tom

Re: AWT problems on the 770 status

[Thomas Fitzsimmons]

Hi,

On Thu, 2006-03-23 at 22:31 +0100, Clemens Eisserer wrote:
> Hi again,
> 
> > We are currently investigating the problem with the other VMs.
> To be honest I wonder what this should be good for...
> All are based on the same source

I've filed a bug about our AWT on the Nokia 770:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26812

Unfortunately I don't have a Nokia 770 to test on so I'm currently
operating under the assumption that the colormap problems are a result
of our mis-use of the GDK colormap APIs.  We're auditing their use now
-- patches may follow.

As for expose event problems, we tested matchbox-window-manager in an
Xnest session and there were no painting problems.  I'm wondering if
it's instead a bad interaction between the 770's custom port of GTK and
our GTK peers.

Can someone post to that bug report instructions on how to build the
770's GTK on an x86 workstation?

Thanks,
Tom

Re: Screenshots and Videos: KF/GST with Classpath on the 770

[Thomas Fitzsimmons]

Hi,

On Wed, 2006-03-29 at 13:33 +0200, Philippe Laporte wrote:
> Hi,
>  Please find shots of Java in action on the 770 at:
> 
> http://www.geocities.com/philippelaporte1/

Is this the problem reported here?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26848

Tom

Re: GConf - java.util.prefs integration

[Thomas Fitzsimmons]

On Fri, 2006-04-07 at 03:19 +0200, Mario Torre wrote:
> Hi!
> 
> As part of an internal project we are developing, I'm writing a simple
> backed to integrate GConf with java.util.prefs.
> 
> The backend uses java-gnome (GConf and glib bindings), so I don't know
> if it can be used as part of classpath.
> 
> I would like to rewrite it to drop java-gnome dependencies, but it is
> still useful in a number of situations (the most important one is to let
> java applications on linux to use the preference api instead of GConf
> when GConf is the only external requirement).
> 
> Given the way that GConf handle preferences, there a couple of issues
> that I'm currently investigating.
> 
> For example, java.util.prefs defines system and user preferences, but
> has no concept of application-only preferences.
> 
> This means, for example, that the standard path to a GConf key for a
> given application is "/apps/appname/key", while in java.util.prefs we
> have always "/" as a starting point.
> 
> More over, GConf keys are not limited to system and user (and system
> here is more of: "user configs related to system application").
> 
> I'm trying to solve the issues about the root directory making a default
> path of "/apps/appname", and only access "/" if a special environment
> variable is set (most likely, many applications would not use that).
> 
> The backend main class is finished, I'm writing few tests to check that
> everything works right, plus I want to be sure that all the
> functionality are in place.
> 
> If you think that it can be integrated in classpath (it would be great),
> we are ready to assign copyright to the classpath team to solve license
> issues (we just need some hint to start this process). In any case, we
> will release the sources under the same license of classpath (GPL +
> exception) so that it can be easily integrated at any point if needed.
> 
> I can send the sources as soon as I'm sure everything is right (at least
> a couple of days).
> 
> Please, let me know if you are interested

Yes, this sounds great.  We've wanted a GConf backend to java.util.prefs
for a long time now.  Introducing a requirement on GConf to GNU
Classpath won't be a problem since we already require GTK for the AWT
peers (and systems with GTK normally have GConf too).  Just post the
patch when it's ready and we'll take it from there.

Tom

Re: FMJ: new open-source alternative to/implementation of JMF

[Thomas Fitzsimmons]

Dalibor Topic wrote:

On Mon, 2006-04-17 at 09:03 -0400, Ken Larson wrote:
I'm pleased to announce the creation of a new open-source project, FMJ 
("Freedom for Media in Java"), with the goal of providing a replacement 
for/alternative to JMF.


Thanks for getting this going, Ken!

I'm hoping that this project will be able to be used in GNU classpath as 
well.  I've chosen the GPL-compatible modified BSD license, which should 
allow this and pretty much anything else.


I think it'd help us greatly if we could use this for applications that
are using JMF atm. Currently, I know of TV apps (vdr-kaffe plugin, and
such), XSmiles (which has a JMF backed for Xine) and OpenOffice.org (for
multimedia content in presentatins, afair).


Yes, see this Fedora Core bug report for an OpenOffice.org use-case:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161474

I couldn't try to fix this because I didn't want to click-through the 
JMF license.


Tom

Re: Build failure: mozilla-plugin

[Thomas Fitzsimmons]

Norman Hendrich wrote:

Hello all,

trying to build classpath cvs fails for me right now, because I 
don't  have package "mozilla-plugin" installed on my Linux system. 
(I do have mozilla, but I don't have any plugins except Suns JRE

and flash-blocked flash.)

Anyway, I think that classpath should be buildable without any
mozilla dependencies.


Try --disable-plugin.

Tom

Re: GConf-backend for java.util.prefs

[Thomas Fitzsimmons]

Hi,

Robert Schuster wrote:


2) Backend chosing
How is should the user or the package maintainers decide which backend is to be
used? Do we want a configure-time option or provide a possibility to chose the
backend when starting the VM (using a property).


I think the --disable-gconf-peer configure option that Mario provided is 
fine, at least until other backends exist.  These peers should be on by 
default and configure should fail if the necessary support libraries are 
not available.  I prefer this behaviour to auto-disabling the peers if 
the libraries aren't available, since it makes clear that the resulting 
build will be less functional than it could be if the build system had 
the right dependencies installed.


Tom

Re: GConf-backend for java.util.prefs

[Thomas Fitzsimmons]

Hi,

Mario Torre wrote:


As a side note, these directory can be configured at runtime by setting
one of these two properties:

java.util.prefs.gconf.user_root
java.util.prefs.gconf.system_root


Since these are GNU-specific properties, they should probably be 
prefixed with "gnu.".


Tom

Re: Build failure: mozilla-plugin

[Thomas Fitzsimmons]

Tom Tromey wrote:

"Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes:



Anyway, I think that classpath should be buildable without any
mozilla dependencies.


Tom> Try --disable-plugin.

For eclipse-based builds it would be friendlier if, by default,
configure would search for the needed libraries and then simply not
compile things if dependencies are missing.


I considered this approach.  I'd rather it be clear that certain 
features of GNU Classpath are disabled if one does not have the proper 
dependencies installed.  An alternative to configure failing outright 
that I've seen in other projects is printing out a long list of:


feature x: enabled
feature y: disabled

lines at the end of the configure run.  Even then though, it's not clear 
to a person wanting to build the plugin (which should be the majority of 
GNU Classpath developers) why it is disabled.  The current configure 
failure makes it very clear that he needs the Mozilla development 
libraries to have a full-featured GNU Classpath build.




Also I noticed we are doing this:

AC_SUBST(PLUGIN_DIR, $HOME/.mozilla/plugins/)

That seems weird, especially for distro use.  (Also according to GNU
standards we shouldn't install anything outside $prefix.)  I think we
probably need another option to set this install directory.

Finally... I see this in the plugin Makefile.am:

install-libLTLIBRARIES: $(lib_LTLIBRARIES)
$(INSTALL) -d -m0755 $(DESTDIR)@PLUGIN_DIR@
$(INSTALL) .libs/libgcjwebplugin.so $(DESTDIR)@PLUGIN_DIR@

Overriding an internal rule is not supported by automake.  If we
really, really want to do this, then the correct approach is a new
directory variable.


Yes, these are a little weird.  I copied them directly from 
gcjwebplugin.  I like this as the default behaviour because it means 
that make && make install actually installs the plugin in a useable way. 
   What about a --with-plugin-directory option that defaults to 
$HOME/.mozilla/plugins?  Then packagers could override this with 
/usr/lib/mozilla/plugins.


Tom

GTK 2.8

[Thomas Fitzsimmons]

Hi,

I just committed my patch to make GdkGraphics2D the default Java2D backend.  Now 
GTK-2.8 or higher is required to build the GNU Classpath GTK peers.


Tom

Re: GTK 2.8

[Thomas Fitzsimmons]

Hi,

Mark Wielaard wrote:


If someone could do some make distchecks and see if everything can be
made to build out of the box again that would be appreciated.


I fixed one problem with make distcheck but now the tools are failing to run 
because they can't find a VM.  I'm not sure how to locate a suitable VM binary. 
 A guess-and-check approach seems hacky since "make distcheck" should be 
totally self-contained and reproducible.  Perhaps we should disable these tests 
until GNU Classpath has a proper bootstrap VM?


Tom

Merging cp-tools and GNU Classpath rmic

[Thomas Fitzsimmons]

Hi,

I'm wondering if anyone has looked at merging the cp-tools and GNU Classpath 
rmic implementations.  What are the issues?  I'm interested in getting this 
resolved so that we can focus on one implementation rather that dealing with the 
current three (GNU Classpath, cp-tools and libgcj).


Tom

Re: Java2D Headless

[Thomas Fitzsimmons]

Robert Schuster wrote:

Hi,
here is the corresponding PR:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23786

Follow the link to the ML to get my preliminary image loading code. It may be
useful to write the start of a full ImageMagick based plugin. However fitzsim
said that ImageMagick provide to few features for a real ImageIO plugin. I think
this means that access to meta-information is impossible. Still simple image
loading should be doable ...


Yes, I'd still like to have an ImageMagick back-end as a catch-all for formats 
not supported by the built-in plugins.


Tom



cya
Robert


Juerg Lehni wrote:

Hi Sven,

Thank you for the update on the status quo of both Java2D and  ImageIO.
And great to hear that work is currently done for this.

I wonder about ImageIO through ImageMagick though. Are you sure that 
there is no code for this so far? I saw it mentioned here, and from 
what I read it sounds like it's already working:


http://developer.classpath.org/doc/javax/imageio/package-summary.html

And how much more time do you think will be needed for the Java2D  stuff
to work completely headless?

Is there anything I could help with?

Jürg

Am 07.06.2006 um 14:20 schrieb Sven de Marothy:


Hello Juerg,


I wonder: Does Java2D and ImageIO work on Unix without an X Server
installed, e.g. in a server environment or on OS X? If so: How do I
need to compile?


Roman has been doing some work on this, however it's not ready for
production use yet, AFAIK. The existing Java2D on Cairo peers will
probably be able to work headless. They don't at this very moment
though. The main remaining dependency on GTK for headless is for  fonts,
but I'm actually working on removing that right now.


And what is the situation on Windows?


Same as above. (The Cairo libs used for offscreen drawing are portable
and shouldn't have any problems under Windows.)


I read somewhere that ImageIO by default is based on ImageMagick. Is
this mature, does it work well?


This is planned, but hasn't been implmented yet. At the moment there's
an ImageIO plugin based on GdkPixbuf and a pure-java BMP plugin, and a
JPEG one in the works.

So, we're not quite there yet. But since you've shown interest, I'll
keep it in mind and see what I can do once we're finished with this
overhaul. Most of the code is there, it's mostly just the font stuff
and then cleaning up the dependencies to allow for headless.

/Sven

Re: Mauve reports

[Thomas Fitzsimmons]

Bryce McKinlay wrote:

Roman Kennke wrote:
Also, the ability to see/track when a failure started occurring could 
be very useful. That way we could easily match up new failures with 
patches that caused them.



Hmm, that's an interesting feature indeed. We would have to keep diffs
between versions around and teach the script to parse and display them
somehow. I must think about this a little.
  


It should become a bit easier with the new test harness. When you treat 
1 test = 1 failure, each pass/fail can be uniquely identified, and 
regressions can be distinguished easily from new test cases.


Yes, I posted a patch that makes the new harness the default and removes the old 
one to [EMAIL PROTECTED] yesterday.  No one has responded thus 
far, but I'd appreciate comments.


Tom

Re: Java2d Benchmarking results

[Thomas Fitzsimmons]

Francis Kung wrote:

Hi Christian, Roman,


How can I run the benchmarks?  I'd like to run it with CACAO.



From your classpath directory (/usr/local/classpath/share/classpath by

default) you can invoke it using "cacao
gnu.classpath.examples.java2d.J2dBenchmarkGUI"


Yeah sure, most of the work is done in native code, so it doesn't really
matter if the VM is an interpreter, completely compiled or jit.


I was talking to fitzsim yesterday, and we also figured that it was
down to Cairo.  I spent a bit of time trying to install cairo with
glitz, to see what the improvement would be, but had no luck.


I talked with Carl Worth about this yesterday.  To test this, we'd need a 
Graphics that could draw to a GL surface, and we'd need to build Cairo and glitz 
from source.  A "GLGraphics" may be something we need in the future, but for now 
the released versions of Cairo do not have glitz support and won't until glitz 
commits to a stable API, which hasn't happened yet.


Even so, I think our graphics backend should be much faster without us needing 
to draw directly to a GL surface.  It may be worthwhile to write a Cairo 
benchmark that performs the same operations as J2dBenchmark to see how far off 
our Java implementation is from the theoretical best native implementation. 
Such a benchmark would also allow us to test fastpath optimizations easily. 
We'd need a set of benchmarks for each of the Cairo surfaces we draw to.


Tom