java-gnome-developer — For people using the bindings to write their own applications

[Java-gnome-developer] Re: What to do in order to make the gnome development platform rock.

[Christian S. <Ur...@li...>]

Hi Kenneth,
Well as someone just begining to meddle in Java I like your ideas, I am
CC'ing it to the java-gnome list also. 

I think giving official status of a set of bindings would probably also
be an idea, for instance there are 3 different Java bindings for GTK+
and GNOME underway AFAIK and maybe if one of them got recognised as the
official GNOME bindings the duplication of effort could be minimized.

One thing I do think however is that we should demand that any language
bindings that are to become/get approved as the official GNOME and GTK+
language bindings are that they move into GNOME CVS.

Christian

On Sat, 2001-09-15 at 19:17, Kenneth Rohde Christiansen wrote:
> Some thoughs of mine, please read:
> 
> By attending the university you often hear non-gnome and non-kde
> developers discuss different platforms, technologies, kde and gnome.   
> While listening to this I have a bigger understanding why these people  
> don't join our project.
> 
> One of the reasons is that many people actually don't like C very much,
> and when these people want to code Gnome they go look for bindings.   
> Many Gnome developers think that Gnome is very cool with all it's
> binding,
> but this thought is not shared with the whole world outside out
> community.
> 
> Many people think that the Gnome development platform is difficult to
> understand. There are lots of libraries, and they are not organized in a
> nice class library. This is possible to do with bindings to OO
> languages, but is as far as I know, not done.
> 
> For instance, Java-GNOME has the following "namespaces"/"packages":
> 
> gnu.gdk, gnu.gtk, gnu.glade, gnu.gnome
> 
> This is very close to the C libs, so it would be easy to switch to Java
> from programming Gnome in C. But almost noone does this. People who want
> to use the Java bindings is often people who don't like C.
> 
> Now the naming is also very unlucky for Java-GNOME as gnu.gnome is
> actually gnome-libs, but for people from the outside Gnome consists of
> gtk, gdk, glade, gnome-libs, etc, so the class library seems weird to
> these people. Also the class library for a binding doesn't have to
> reflect that it is made by using gdk, gtk or whatever.
> 
> If we want people to use these bindings we have to make them easy and
> hide implimentation/bindings details.
> 
> An idea for Java-GNOME could be like this:
> 
> org.gnome.drawing                       - gdk
> org.gnome.ui                            - gtk
> org.gnome.ui.extra                      - libgnomeui + bonoboui
> org.gnome.ui.glade                      - glade
> org.gnome.accessibility                 - atk
> org.gnome.containers (or .utils)        - glib containers wrappers    
> org.gnome.canvas                        - libgnomecanvas
> org.gnome.vfs                           - gnome-vfs
> org.gnome.config                        - gconf or bonobo-conf
> org.gnome.bonobo                        - bonobo
> org.gnome.bonobo.activation             - bonobo-activation
> org.gnome.xml                           - libxml (if it makes sence to
> bind)
> org.gnome.print                         - libgnomeprint
> --
> org.gnome.misc.eel                      - eel
> org.gnome.misc.gal                      - gal
> org.gnome.misc.panel                    - panel applets
> ...etc.
> 
> 
> This doesn't confuse people with the difference with gtk, gdk and gnome,
> and it integrates well with the Java language. All not well integrated
> things have been put in org.gnome.misc and might be moved elsewhere
> later.
> 
> A similar hierachy can be used for C++ bindings.
> 
> Also, something people don't like about the Gnome bindings is that none
> are OFFICIAL. For people outside our community it seems that the
> bindings 
> are made by people with no connection to the Gnome Community, and they
> then fear the quality of the bindings, and goes elsewhere.
> 
> What can we do to make this better? Should we decide on a class library
> that should be followed by binders if they want their bindings to be
> official. Do we need some kind of quality control?
> 
> I really think that we should get some good Java bindings. Both Sun and
> IBM said that they support Gnome, and they both have a strong Java    
> commitment. Cooperation with Sun and IBM about this would really rock.
> Maybe something for the Gnome Foundation?.
> 
> Also the development pages really scare people away.
> 
> Take a look at these two pages:
> 
> http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html
> http://developer.apple.com/macosx/architecture/
> 
> We really need something like this. And we need to group our
> technologies,
> maybe something like this could be an idea?
> 
> GNOME System Architecture
> -------------------------
> 
> GNOME User Experience (libgnome, glade, gtk, gdk)
> --
> Bonobo Component System
> GNOME Language Framework (Java-GNOME, python, etc)
> GNOME Multimedia Framework (gstreamer)
> --
> Linux/UNIX Kernel
> UNIX into the future. GNOME expands on many open souce
> and industry standards towards providing UNIX users and
> developers with a userfriendly and powerful desktop and
> development platform.
> 
> Anyway, it's just some ideas. Please comment
> 
> Cheers, Kenneth
> 
> 
> 
> _______________________________________________
> gnome-hackers mailing list
> gno...@gn...
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 
> 
> 

[Java-gnome-developer] problem with GtkTree signals

[Damien <da...@ca...>]

Me again ... :)

I've got a problem with the tree signal "select-child". It passes a
GtkWidget has an argument to the callback function. If I print the
widget.getName(), I get a GtkTreeItem, wich is good, but when I try cast
the GtkWidget to a GtkTreeItem, nothings happen ... 

For example:

mytree.signalConnect("select-child", "onChildSelected", this)

public void onChildSelected( GtkWidget wgt )
{
	System.err.println("1");
	GtkTreeItem myitem = (GtkTreeItem) wgt;
	System.err.println("2");
}

I only get "1" has output. everything after the line GtkTreeItem myitem
... seems to not happen. If I do a System.err.println( wgt ), I get
something like GtkWidget @152136 ...

Don't know if this is a bug or if it is my fault ...

See you,

Dam
	

RE: [Java-gnome-developer] problem with GtkTree

[Jeffrey M. <Jef...@Br...>]

You are correct in that there are no methods to set
the plus or minus pixmaps.  There are members of
the GtkTreeItem structure that represent these
widgets and that a C programmer would set directly.
The methods I added to the bindings are there to allow
a Java developer to access the structure elements.

Drag and Drop is not supported at this time.

-Jeff

> 
> It seems like there are no function like these in the GtkTreeItem, in
> the doc on developer.gnome.org and in the source ....
> 
> Another thing, is there support for drag & drop ?
> 
> Dam
> 
> On ven, 2001-09-14 at 16:51, Jeffrey Morgan wrote:
> > This could be a bug in the GtkTreeItem widget.
> > After looking at the gdkdraw.c file I can
> > see that the assertion is caused when the GdkPixmap
> > is NULL.  The constructor you are using to create
> > the GtkPixmap was hand written and is located in
> > src/code/jni/glue/GtkPixmap.c.  You might add
> > some code to this file to perform a check to make
> > sure the GdkPixmap is valid.  Let me know your
> > results
> > 
> > -Jeff
> > 
> > > 
> > > 
> > > Hello
> > > 
> > > I'm having problem changing the small pixmaps in the 
> > > GtkTreeItem widget:
> > > 
> > > using mytreeitem.setMinusPixWidget(new GtkPixmap( win, transpa,
> > > "dir_open.xpm" ));
> > > 
> > > I get this error: Gdk-CRITICAL **: file gdkdraw.c: line 380
> > > (gdk_draw_pixmap): assertion `src != NULL' failed.
> > > 
> > > When I just had my GtkPixmap in a gtk window, I get the small 
> > > cross wich
> > > normally appears in the GtkTreeItem widget (this is 
> strange, it has
> > > nothing to do with my pixmap).
> > > 
> > > Any idea ?
> > > 
> > > dam
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > java-gnome-developer mailing list
> > > jav...@li...
> > > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > > 
> 
> 

RE: [Java-gnome-developer] problem with GtkTree

[Damien <da...@ca...>]

It seems like there are no function like these in the GtkTreeItem, in
the doc on developer.gnome.org and in the source ....

Another thing, is there support for drag & drop ?

Dam

On ven, 2001-09-14 at 16:51, Jeffrey Morgan wrote:
> This could be a bug in the GtkTreeItem widget.
> After looking at the gdkdraw.c file I can
> see that the assertion is caused when the GdkPixmap
> is NULL.  The constructor you are using to create
> the GtkPixmap was hand written and is located in
> src/code/jni/glue/GtkPixmap.c.  You might add
> some code to this file to perform a check to make
> sure the GdkPixmap is valid.  Let me know your
> results
> 
> -Jeff
> 
> > 
> > 
> > Hello
> > 
> > I'm having problem changing the small pixmaps in the 
> > GtkTreeItem widget:
> > 
> > using mytreeitem.setMinusPixWidget(new GtkPixmap( win, transpa,
> > "dir_open.xpm" ));
> > 
> > I get this error: Gdk-CRITICAL **: file gdkdraw.c: line 380
> > (gdk_draw_pixmap): assertion `src != NULL' failed.
> > 
> > When I just had my GtkPixmap in a gtk window, I get the small 
> > cross wich
> > normally appears in the GtkTreeItem widget (this is strange, it has
> > nothing to do with my pixmap).
> > 
> > Any idea ?
> > 
> > dam
> > 
> > 
> > 
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > 

[Java-gnome-developer] Java-GNOME 0.7.0 released

[Jeffrey M. <Jef...@Br...>]

The Java-GNOME team is pleased to announce the release
of version 0.7.0 of the bindings.  The primary enhancement
for this release is the ability to compile the bindings
to native code using gcj version 3.0.0 or higher.  New
entries have been added to the FAQ with the information
you will need to build the bindings with gcj.

---
------------------------------------
Jeffrey S. Morgan
Email: jef...@br...

RE: [Java-gnome-developer] problem with GtkTree

[Jeffrey M. <Jef...@Br...>]

This could be a bug in the GtkTreeItem widget.
After looking at the gdkdraw.c file I can
see that the assertion is caused when the GdkPixmap
is NULL.  The constructor you are using to create
the GtkPixmap was hand written and is located in
src/code/jni/glue/GtkPixmap.c.  You might add
some code to this file to perform a check to make
sure the GdkPixmap is valid.  Let me know your
results

-Jeff

> 
> 
> Hello
> 
> I'm having problem changing the small pixmaps in the 
> GtkTreeItem widget:
> 
> using mytreeitem.setMinusPixWidget(new GtkPixmap( win, transpa,
> "dir_open.xpm" ));
> 
> I get this error: Gdk-CRITICAL **: file gdkdraw.c: line 380
> (gdk_draw_pixmap): assertion `src != NULL' failed.
> 
> When I just had my GtkPixmap in a gtk window, I get the small 
> cross wich
> normally appears in the GtkTreeItem widget (this is strange, it has
> nothing to do with my pixmap).
> 
> Any idea ?
> 
> dam
> 
> 
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

[Java-gnome-developer] problem with GtkTree

[Damien <da...@ca...>]

Hello

I'm having problem changing the small pixmaps in the GtkTreeItem widget:

using mytreeitem.setMinusPixWidget(new GtkPixmap( win, transpa,
"dir_open.xpm" ));

I get this error: Gdk-CRITICAL **: file gdkdraw.c: line 380
(gdk_draw_pixmap): assertion `src != NULL' failed.

When I just had my GtkPixmap in a gtk window, I get the small cross wich
normally appears in the GtkTreeItem widget (this is strange, it has
nothing to do with my pixmap).

Any idea ?

dam

[Java-gnome-developer] RE: GCJ support in java-gnome breaks --with-kaffe

[Jeffrey M. <Jef...@Br...>]

Found the error.  It is fixed and in CVS.

> Did that, and --with-kaffe seems to in itself work again even with
> --with-gcj-compile, but the libgcj.jar location that it tries 
> to use is
> still wrong. Funny, though, that it doesn't notice it until the second
> gcj-compiled file:
> 
> --- CUT HERE ---
> gcj -fPIC -fjni -g -O
> --classpath=/usr/share/libgcj.jar:/usr/share/kaffe/Klasses.jar:. -o
> gnu/gdk/BaseBoxed.o -c gnu/gdk/BaseBoxed.java
> gcj -fPIC -fjni -g -O
> --classpath=/usr/share/libgcj.jar:/usr/share/kaffe/Klasses.jar:. -o
> gnu/gdk/BaseEnum.o -c gnu/gdk/BaseEnum.java
> java/lang/Object.java:0: The `java.lang.Object' that was found in
> `/usr/share/kaffe/Klasses.jar' didn't have the special zero-length
> `gnu.gcj.gcj-compiled' attribute. This generally means that 
> your classpath
> is incorrect set. Use `info gcj "Input Options"' to see the info page
> describing how to set the classpath.
> compilation terminated.
> --- CUT HERE ---
> 
> Anyway, in configure, I do notice a check for the libgcj.jar 
> location, but
> as it happens, it sets the same GCJ_CLASSPATH either way :)
> 
> --- CUT HERE ---
>      if test -f ${GCJ_HOME}/share/libgcj.jar ; then
>        	
> GCJ_CLASSPATH="${GCJ_HOME}/share/libgcj.jar:${CLASSPATH}"
>      elif test -f ${GCJ_HOME}/share/java/libgcj.jar ; then
> 	GCJ_CLASSPATH="${GCJ_HOME}/share/libgcj.jar:${CLASSPATH}"
> --- CUT HERE ---
> 
> Oh, by the way, this probably isn't new information to you if you've
> experimented with jikes compilation, but I'll put it here nonetheless,
> just in case. Just symlinking jikes to javac seems to be 
> almost workable
> if jikes sees the base java libraries (which I managed in my Sid
> installation by extracting libgcj.jar into 
> /usr/share/java/repository -
> this'd probably be better accomplished by adding a class library jar
> package into jikes' classpath, but I was just trying this as a quick
> hack). The compilation goes ok until a java-gnome source file tries to
> reference others of its kind.
> 
> --- CUT HERE ---
> /usr/bin/javac -d . other/BaseBoxed.java
> /usr/bin/javac -d . other/BaseEnum.java
> /usr/bin/javac -d . other/BaseFlags.java
> /usr/bin/javac -d . other/BaseObject.java
> /usr/bin/javac -d . other/GListString.java
> 
> Found 1 semantic error compiling "other/GListString.java":
> 
>     31.     extends BaseObject
>                     <-------->
> *** Error: Type gnu/gdk/BaseObject was not found.
> --- CUT HERE ---
> 
> (This, as said, with /usr/bin/javac being a symlink to jikes.)
> 
> -- 
> Mikko Rauhala - mj...@ik... - http://www.iki.fi/mjr/
> 

[Java-gnome-developer] RE: GCJ support in java-gnome breaks --with-kaffe

[Mikko J R. <mjr...@cc...>]

On Tue, 11 Sep 2001, Jeffrey Morgan wrote:

> I believe I have fixed both the Kaffe problem and
> the and the problem you were having with Debian.
> Can you please give the code in cvs a try and let
> me know your findings?

Did that, and --with-kaffe seems to in itself work again even with
--with-gcj-compile, but the libgcj.jar location that it tries to use is
still wrong. Funny, though, that it doesn't notice it until the second
gcj-compiled file:

--- CUT HERE ---
gcj -fPIC -fjni -g -O
--classpath=/usr/share/libgcj.jar:/usr/share/kaffe/Klasses.jar:. -o
gnu/gdk/BaseBoxed.o -c gnu/gdk/BaseBoxed.java
gcj -fPIC -fjni -g -O
--classpath=/usr/share/libgcj.jar:/usr/share/kaffe/Klasses.jar:. -o
gnu/gdk/BaseEnum.o -c gnu/gdk/BaseEnum.java
java/lang/Object.java:0: The `java.lang.Object' that was found in
`/usr/share/kaffe/Klasses.jar' didn't have the special zero-length
`gnu.gcj.gcj-compiled' attribute. This generally means that your classpath
is incorrect set. Use `info gcj "Input Options"' to see the info page
describing how to set the classpath.
compilation terminated.
--- CUT HERE ---

Anyway, in configure, I do notice a check for the libgcj.jar location, but
as it happens, it sets the same GCJ_CLASSPATH either way :)

--- CUT HERE ---
     if test -f ${GCJ_HOME}/share/libgcj.jar ; then
       	GCJ_CLASSPATH="${GCJ_HOME}/share/libgcj.jar:${CLASSPATH}"
     elif test -f ${GCJ_HOME}/share/java/libgcj.jar ; then
	GCJ_CLASSPATH="${GCJ_HOME}/share/libgcj.jar:${CLASSPATH}"
--- CUT HERE ---

Oh, by the way, this probably isn't new information to you if you've
experimented with jikes compilation, but I'll put it here nonetheless,
just in case. Just symlinking jikes to javac seems to be almost workable
if jikes sees the base java libraries (which I managed in my Sid
installation by extracting libgcj.jar into /usr/share/java/repository -
this'd probably be better accomplished by adding a class library jar
package into jikes' classpath, but I was just trying this as a quick
hack). The compilation goes ok until a java-gnome source file tries to
reference others of its kind.

--- CUT HERE ---
/usr/bin/javac -d . other/BaseBoxed.java
/usr/bin/javac -d . other/BaseEnum.java
/usr/bin/javac -d . other/BaseFlags.java
/usr/bin/javac -d . other/BaseObject.java
/usr/bin/javac -d . other/GListString.java

Found 1 semantic error compiling "other/GListString.java":

    31.     extends BaseObject
                    <-------->
*** Error: Type gnu/gdk/BaseObject was not found.
--- CUT HERE ---

(This, as said, with /usr/bin/javac being a symlink to jikes.)

-- 
Mikko Rauhala - mj...@ik... - http://www.iki.fi/mjr/

[Java-gnome-developer] RE: GCJ support in java-gnome breaks --with-kaffe

[Jeffrey M. <Jef...@Br...>]

I believe I have fixed both the Kaffe problem and
the and the problem you were having with Debian.
Can you please give the code in cvs a try and let
me know your findings?

Thanks
-Jeff

> 
> Hello,
> 
> yes, it's me again. Turns out --with-gcj-compile breaks --with-kaffe,
> since it uses the same classpath for both programs but Kaffe wants
> Klasses.jar before libgcj.jar (and I suppose the other way around as
> well):
> 
> make[2]: Leaving directory `/usr/local/src/java-gnome/src/tools'
> /usr/bin/kaffe -classpath
> /usr/share/java/libgcj.jar:/usr/share/kaffe/Klasses.jar:tools:.
> DefsProcessor \
> 	--out-dir=. --out-list=gtk-classes.txt defs/gtk.defs
> 
> Could not initialize Kaffe.
> It's likely that your CLASSPATH settings are wrong.  Please make sure
> your CLASSPATH does not include any java.lang.* classes from other JVM
> vendors, such as Sun's classes.zip, BEFORE Kaffe's Klasses.jar.
> It is okay to have classes.zip AFTER Klasses.jar
> 
> The current effective classpath is
> `/usr/share/java/libgcj.jar:/usr/share/kaffe/Klasses.jar:tools:.'
> 
> 
> Yeah, and good to hear about the jikes thing, since it'd be nice to be
> able to build this thing on a free system (with kaffe/jikes/gcj).
> 
> By the way, if I come across more stuff, should I keep on bugging you
> or the list or what?
> 
> -- 
> Mikko Rauhala - mj...@ik... - http://www.iki.fi/mjr/
> 

RE: [Java-gnome-developer] Java-Gnome is cool but it's a Bad Thing.

[Daniel H. <dhe...@wo...>]

Ed Symanzik wrote:
> - I write Java so my applications will be portable.  Gnome is
>   not portable.

Sure it is. It's portable across many different flavors of Unix
and Linux and *BSD.

I write applications using Java as the language because Java
is a very clean and elegant language to use. I personally 
find it a hindrance that Java's "cross-platform" nature has
made it slower than it has to be in certain situations (which
is why GCJ looks kinda cool...).

> - Microsoft did the same thing, tying Java to Windows calls,
>   and they got their hand slapped.  It was bad then and it's
>   bad now.

Er. Not true. It is not against the Sun vendor licensing to
bind Java to any native interface -- that's why JNI exists.

What M$ did was alter and/or omit core API functionality from
the java class libraries that they were bound by licensing 
agreement to include (ie not include Swing).

FYI, Apple has produced a JNI interface to Aqua, its super-
sleak UI that runs on top of OS-X. It is bundled with their
OS-X distribution of Java, along with Swing.

There's nothing wrong with extending Java for your own benefit,
or the benefit of your neighbors.

> Perhaps I don't understand but it seems to me this should be
> done as UIManager.setLookAndFeel("org.gnome.GnomeLookAndFeel")
> or perhaps by rewriting awk/swing to use gnome.

If that is what you want (a Swing PLAF that adheres to gtk),
then check out:

http://gtkswing.sourceforge.net/

But if what you want is a UI that doesn't suck (ie Swing),
and that will allow you to write fairly zippy user apps
in Java that run on any gnome-compliant machine, this looks
like a good beginning.

Thx,
-daniel
--
Daniel Hedrick,
Software Engineer
dhe...@wo...
"Some mistakes are too much fun to make only once."

[Java-gnome-developer] GCJ support for Java-GNOME

[Jeffrey M. <Jef...@Br...>]

I have just checked the changes for gcj compilation
into CVS.  This is the first major step towards
release 0.7.0 which I hope to roll out late next
week.  I anticipate much interest in this release
so any testing help over the next week would be
greatly appreciated.

In order to build the bindings with gcj native
support you must have gcj 3.0.0 or greater.  
There are new arguments to the configure scripts
that facilitate the build.  They are:

--with-gcj-compile	Compile the bindings with native
				gcj support
--with-gcj-prefix		Specify the root directory of the
				gcc tree which contains gcj.

If gcj is in your path just type

./configure --with-gcj-support

and you should be ok.

The bindings will build in the standard fashion
creating gtk.jar, gnome.jar, libGTKJava.so, and
libGNOMEJava.so.  In addition, the build process
will also create libGTKJar.so and libGNOMEJar.so.
These files contain the binary form of the java
classes in the jar files.  The build process will
also create a binary version of TestGTK and TestGNOME.

In order to compile the examples using gcj you will
need to have libgcj.jar in your CLASSPATH and execute
the following command:

gcj -fPIC -fjni -g -O -o Calculator --main=Calculator \
	-L<path to shared objects> Calculator.java -lGTKJar -lGNOMEJar

I will be adding FAQs regarding this feature.  Please
let me know if you have anything you think should be
added to the FAQ.

Thanks
---
------------------------------------
Jeffrey S. Morgan
Email: jef...@br...

Re: [Java-gnome-developer] Java-Gnome is cool but it's a Bad Thing.

[Bastien R. N. <br...@fr...>]

Ed Symanzik wrote:
> The screenshots are cool but here's why this is a Bad Thing:
> 
> - I write Java so my applications will be portable.  Gnome is
>   not portable.
> 
> - Microsoft did the same thing, tying Java to Windows calls, 
>   and they got their hand slapped.  It was bad then and it's
>   bad now.
> 
> Perhaps I don't understand but it seems to me this should be
> done as UIManager.setLookAndFeel("org.gnome.GnomeLookAndFeel")
> or perhaps by rewriting awk/swing to use gnome.

s/awk/awt/

Take a look at the GNU Classpath project if you want SWING ("portable") 
with a Gnome look and feel. If you don't like writing "non-portable 
code" as you put it, just don't use Java-Gnome.
If an application is properly designed and written, you can replace 
Swing code by Java-Gnome code, giving you a truly native GUI on a Gnome 
desktop.

That's a choice, and I like it.


Cheers

Re: [Java-gnome-developer] Java-Gnome is cool but it's a Bad Thing.

[Joe P. <joe...@in...>]

I personally use Java for the following reasons (in no particular
order):

1- easy to use language
2- OO base
3- depth of class libraries
4- portability (I use UNIX/Linux, my clients can use whatever they want)
5- good error-handling via exceptions

Portability is important to me and my company.  We like the fact that we
can develop good systems using Linux and Solaris and still deploy to MS
Windows clients if they so desire.

The current state of the java-gnome bindings are not very useful to me
but I continue to watch development and consider pitching in due to the
potential.

I know that the java-gnome bindings are not being developed with the
intention of extending AWT but there is no denying that they could be
used to do so down the road.  If it is not done by the original
developers, it can be done by someone else.  I think this would be a
nice thing to see.

I'm a Java developer AND a GNOME user.  I'd like to be able to write a
GNOME panel applet using Java.  The Java-GNOME bindings will allow me to
do so.

While I'd really like to see a GNOME-enabled AWT with GTK look-and-feel
support, there is no reason it can't be built upon the work done by the
Java-GNOME team.

-joe

On 05 Sep 2001 13:00:52 -0400, Ed Symanzik wrote:
> The screenshots are cool but here's why this is a Bad Thing:
> 
> - I write Java so my applications will be portable.  Gnome is
>   not portable.
> 
> - Microsoft did the same thing, tying Java to Windows calls, 
>   and they got their hand slapped.  It was bad then and it's
>   bad now.
> 
> Perhaps I don't understand but it seems to me this should be
> done as UIManager.setLookAndFeel("org.gnome.GnomeLookAndFeel")
> or perhaps by rewriting awk/swing to use gnome.

RE: [Java-gnome-developer] Java-Gnome is cool but it's a Bad Thin g.

[Jeffrey M. <Jef...@Br...>]

Ed,

Thanks for your feedback.  If you want to write portable
applications in Java then you shouldn't use Java-GNOME.
My goal with Java-GNOME has never been to replace AWT
or Swing.  I am coming at this from the opposite direction.
My goal is to expand the options for developers that
want to develop applications for Gnome.  If you want
to develop applications for Gnome you should be able
to use C, C++, Python, or Java.

I am just a few days away from releasing support for
native gcj compilation.  This will produce binaries from
the Java code and will make the applications even less 
portable.  At the same time, this only makes Java one 
step closer to becoming a "first class" language for 
Gnome development.

-Jeff

> 
> The screenshots are cool but here's why this is a Bad Thing:
> 
> - I write Java so my applications will be portable.  Gnome is
>   not portable.
> 
> - Microsoft did the same thing, tying Java to Windows calls, 
>   and they got their hand slapped.  It was bad then and it's
>   bad now.
> 
> Perhaps I don't understand but it seems to me this should be
> done as UIManager.setLookAndFeel("org.gnome.GnomeLookAndFeel")
> or perhaps by rewriting awk/swing to use gnome.
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

Re: [Java-gnome-developer] Java-Gnome is cool but it's a Bad Thing.

[Keith G. <kbg...@ho...>]

I'm just a lurker here, but I'm going to go ahead and strongly disagree with 
you on this one.

>- I write Java so my applications will be portable.  Gnome is
>   not portable.
Can't argue with either of these statements; I can't say why you use java, 
and gnome is not wholly portable.  I will, however, take issue with a basic 
assumption: that java's portablity is the only reason you would want to use 
the language.  There are plenty more reasons to use the language, and even a 
few why you wouldn't want the code to be necessarily cross-platform.  Off 
the top of my head:
1.) its a relatively strong language good for beginners, without many of the 
headaches of c++.
2.) performance gains are seen in compiled code, which is inherently non-xp.
3.) built-in threading and gc (i'm not sure how gcj handles this though so i 
might be talking out of my ass)
4.) easy to find programmers who can use java
5.) you work for sun in their gnome group
6.) because you can.

>- Microsoft did the same thing, tying Java to Windows calls,
>   and they got their hand slapped.  It was bad then and it's
>   bad now.

To me the whole argument boils down to the same Stallman-esque rationale 
that says all code should be GPL'ed, which i also disagree with.  Its a big 
world.  There's room enough for both views.




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Java-gnome-developer] Java-Gnome is cool but it's a Bad Thing.

[Ed S. <zi...@ms...>]

The screenshots are cool but here's why this is a Bad Thing:

- I write Java so my applications will be portable.  Gnome is
  not portable.

- Microsoft did the same thing, tying Java to Windows calls, 
  and they got their hand slapped.  It was bad then and it's
  bad now.

Perhaps I don't understand but it seems to me this should be
done as UIManager.setLookAndFeel("org.gnome.GnomeLookAndFeel")
or perhaps by rewriting awk/swing to use gnome.

RE: [Java-gnome-developer] Error compiling CroMagnon

[Jeffrey M. <Jef...@Br...>]

Sorry for this.  You will need to manually edit
the src/Makefile.  You should add "-lzvt -lutil"
to the GNOME_LIBS.  Once I complete the gcj 
support (hopefully in the next few days) this
should work as well.

-Jeff

> 
> Hi,
> I am still working on getting Java-GNOME to work under Jdeveloper, and
> as soon as I understand all the issues involved I will make a howto.
> 
> Anyway trying to compile CroMagnon I get this error (using 
> todays CVS):
> 
> /java/jdk1.3.1/bin/java -client -classpath
> /home/cschalle/jdevhome/mywork/AcmeVideo/Project1/classes_g:/u
> sr/local/share/java-gnome/gnome.jar:/usr/local/share/java-gnom
e/gtk.jar:/opt/jdev/lib/jdev-rt.jar:/usr/local/share/java->
gnome/gnome.jar:/usr/local/share/java-gnome/gtk.jar CroMagnon 
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> /usr/local/lib/libGNOMEJava.so.0.6.1:
> /usr/local/lib/libGNOMEJava.so.0.6.1: undefined symbol:
> zvt_term_set_bell
> 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
> 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1306)
> 	at java.lang.Runtime.loadLibrary0(Runtime.java:749)
> 	at java.lang.System.loadLibrary(System.java:820)
> 	at gnu.gnome.Gnome.<clinit>(Gnome.java:35)
> 	at CroMagnon.main(CroMagnon.java:253)
> Process exited with exit code 1.
> 
> 
> 
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> http://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

RE: [Java-gnome-developer] Adding bindings for other libraries... how ?

[Jeffrey M. <Jef...@Br...>]

I recently added an entry to the FAQ that 
describes how to extend the bindings.  You
will need to get this from CVS.

-Jeff

> 
> 
> Hi,
> 
> I would need, for work purposes, to have some Java bindings to an XML 
> library written in C. As I am a Gnome developer I thought of 
> Java-Gnome 
> instantly.
> 
> Could anybody with the knowledge post a "Guide for Dummies" on how to 
> add support for other libraries/widgets to the bindings ? I'm very 
> interested in trying this out, although I'm a lame Java developer ;)
> 
> Cheers
> 
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

[Java-gnome-developer] Adding bindings for other libraries... how ?

[Bastien R. N. <br...@fr...>]

Hi,

I would need, for work purposes, to have some Java bindings to an XML 
library written in C. As I am a Gnome developer I thought of Java-Gnome 
instantly.

Could anybody with the knowledge post a "Guide for Dummies" on how to 
add support for other libraries/widgets to the bindings ? I'm very 
interested in trying this out, although I'm a lame Java developer ;)

Cheers

[Java-gnome-developer] Error compiling CroMagnon

[Christian S. <Ur...@li...>]

Hi,
I am still working on getting Java-GNOME to work under Jdeveloper, and
as soon as I understand all the issues involved I will make a howto.

Anyway trying to compile CroMagnon I get this error (using todays CVS):

/java/jdk1.3.1/bin/java -client -classpath
/home/cschalle/jdevhome/mywork/AcmeVideo/Project1/classes_g:/usr/local/share/java-gnome/gnome.jar:/usr/local/share/java-gnome/gtk.jar:/opt/jdev/lib/jdev-rt.jar:/usr/local/share/java-gnome/gnome.jar:/usr/local/share/java-gnome/gtk.jar CroMagnon 
Exception in thread "main" java.lang.UnsatisfiedLinkError:
/usr/local/lib/libGNOMEJava.so.0.6.1:
/usr/local/lib/libGNOMEJava.so.0.6.1: undefined symbol:
zvt_term_set_bell
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1306)
	at java.lang.Runtime.loadLibrary0(Runtime.java:749)
	at java.lang.System.loadLibrary(System.java:820)
	at gnu.gnome.Gnome.<clinit>(Gnome.java:35)
	at CroMagnon.main(CroMagnon.java:253)
Process exited with exit code 1.

RE: [Java-gnome-developer] GnomeCanvasPoints

[Jeffrey M. <Jef...@Br...>]

You are correct in your thoughts that double* is represented
as an array of doubles.  As I worked my way through the widgets
there probably was a place where gtk or gnome was passing a pointer
to an array of doubles and so I made that type.  Your are also
correct in that the gnome function gnome_color_picker_get_d does
expect pointers to a double.  The method for the GnomeColorPicker
as generated will not work.  There are several ways to remedy this
problem.  You could create a new type in the JNIProps file
of "Double" and use that as you suggested below.   This approach
would seem to move away for the common usage of the Java.  Another
approach would be to manually write the methods like the following:

double getGreen();
double getRed();
etc...

This approach is in the JavaBean fashion and would be easier for
developers coming from a Java background.  In the implementation
for each of these methods you would call the gnome_color_picker_get_d 
method but would only return the requested value.  This is more
work than having the generator create the code for us but in
the end makes the bindings more user friendly.

-Jeff

> 
> Thanks for the quick reply.
> I started my attemp at implementing the GnomeCanvas* methods/functions
> but I have a couple questions.
> First:
> I started by studying the src/gnome.defs file and saw that in cases
> where the gnome C api stated things such as:
> 
> void gnome_color_picker_get_d 	(GnomeColorPicker *cp,
>                                  gdouble *r,
>                                  gdouble *g,
>                                  gdouble *b,
>                                  gdouble *a);
> 
> There were corresponding function definitions in src/gnome.defs like:
> 
> (define-func gnome_color_picker_get_d
>   none
>   ((GnomeColorPicker cp)
>    (double* r)
>    (double* g)
>    (double* b)
>    (double* a)))
> 
> and the src/tools/JNIProps.txt file the double*.javaType 
> definition is:
> 
> double*.javaType:     double[]
> double*.nativeType:   jdoubleArray
> double*.nativeUnwrap:                        \
>     gdouble *$TO =                           \
> 	.
> 	.
> 	.
> 
> This leads me to believe that double* is converted to an array of
> doubles, but I thought the in C when the statement "gdouble *r" ment a
> pointer to a thing that is of type gdouble. I realize that's 
> the values
> to this function will also hold the results, but to my understanding
> there not arrays being passed in (at least not in the C api). 
>  Now as I
> understand it in Java things like int, double, etc... are not real
> Objects so they are passed by value rather than by reference therefore
> they will not to hold the return values.  So I was wondering 
> if instead
> of the corresponding arguments in Java for methods/functions like this
> shouldn't be:
> 
> void getD(Double r, Double g, Double b, Double a)
> 
> where "Double r, Double g,..." are the Object types of these value
> intstead of:
> 
> void getD(double[] r, double[] g, double[] b, double[] a)
> 
> where they are arrays of the simple variable types.  (Are 
> they arrays to
> turn them into Objects so that they can be passed by value 
> and hence get
> the return value?)
> 
> Let me know if I'm completely off base here, and point me to 
> the proper
> documentation if so.  The next thing is (much simpler question),
> assuming I'm wrong about the above stuff, all I need to do for the
> GnomeCavas* methods/functions is something like this in the
> src/gnome.defs file:
> 
> (define-func gnome_canvas_get_scroll_region
>   none
>   ((GnomeCanvas canvas)
>    (double* x1)
>    (double* y1)
>    (double* x2)
>    (double* y2)))
> 
> where the C api looks like:
> 
> void        gnome_canvas_get_scroll_region  (GnomeCanvas *canvas,
>                                              double *x1,
>                                              double *y1,
>                                              double *x2,
>                                              double *y2);
> 

[Java-gnome-developer] **LOW COST SOFTWARE DEVELOPMENT**

[BrainCoders.com <mai...@br...>]

Dear Internet User,

The eBusiness is changing the software applications and 
services landcape in a way that has not been seen 
earlier. Companies worldwide are waking up to the fact 
that the difference between just having an Online 
Presence and using the web as a strategic medium can mean 
all the difference to success. 

What this also means is that you need technology 
providers who understand the business implications of 
technology and can make sure that the solutions work with 
your exisiting business processes as also enable you to 
integrate new processes without massive investments in 
changing the whole Application Architecture. 

BrainCoders.com is a software company dedicated to 
designing and developing the highest-quality software to 
provide our clients with workable, maintainable and 
leading-edge solutions. We are specializing in IT 
services and software outsourcing. 

Our prices are one of the lowest on the market. We charge 
our customers from $8 to $15 per working hour depending 
on the length and complexity of the project.

Our leading principle is to consistently deliver on time 
and on budget. 
Our most value asset is our team of most committed and 
capable people. 

This dedication to high degrees of professionalism 
translates to innovative and cost effective solutions. 
The bottom line is that we help our clients gain 
competitive advantage and maintain their leading 
positions in their respective industries.

BrainCoders.com' software development services may be of 
special interest to the following groups of potential 
customers: 

Software houses that wish to reduce their development 
costs by means of outsourcing.

Companies not directly involved in software development, 
but which have or need their proprietary software 
business applications and wish to delegate the 
development, upgrades and support of these applications 
to a software company.

For more information please visit our web site by 
clicking the following link:

http://www.braincoders.com

If you are interested in our services, I would be happy 
to provide you with any information you may request.

I am looking forward to hearing from you.

BestRegards,

Vesselin Sladkov
BrainCoders.com
E-mail: sl...@br...

_________________________________________________________
This mailing is done only to people who have requested 
info from one of our sites, or downloaded
our Software. If you have recieved this email in error 
and you wish to be removed from future 
mailings, please reply with the subject "Remove" and our 
software will automatically block you 
from their future mailings.
_________________________________________________________

RE: [Java-gnome-developer] GnomeCanvasPoints

[Brad B. <br...@co...>]

Thanks for the quick reply.
I started my attemp at implementing the GnomeCanvas* methods/functions
but I have a couple questions.
First:
I started by studying the src/gnome.defs file and saw that in cases
where the gnome C api stated things such as:

void gnome_color_picker_get_d 	(GnomeColorPicker *cp,
                                 gdouble *r,
                                 gdouble *g,
                                 gdouble *b,
                                 gdouble *a);

There were corresponding function definitions in src/gnome.defs like:

(define-func gnome_color_picker_get_d
  none
  ((GnomeColorPicker cp)
   (double* r)
   (double* g)
   (double* b)
   (double* a)))

and the src/tools/JNIProps.txt file the double*.javaType definition is:

double*.javaType:     double[]
double*.nativeType:   jdoubleArray
double*.nativeUnwrap:                        \
    gdouble *$TO =                           \
	.
	.
	.

This leads me to believe that double* is converted to an array of
doubles, but I thought the in C when the statement "gdouble *r" ment a
pointer to a thing that is of type gdouble. I realize that's the values
to this function will also hold the results, but to my understanding
there not arrays being passed in (at least not in the C api).  Now as I
understand it in Java things like int, double, etc... are not real
Objects so they are passed by value rather than by reference therefore
they will not to hold the return values.  So I was wondering if instead
of the corresponding arguments in Java for methods/functions like this
shouldn't be:

void getD(Double r, Double g, Double b, Double a)

where "Double r, Double g,..." are the Object types of these value
intstead of:

void getD(double[] r, double[] g, double[] b, double[] a)

where they are arrays of the simple variable types.  (Are they arrays to
turn them into Objects so that they can be passed by value and hence get
the return value?)

Let me know if I'm completely off base here, and point me to the proper
documentation if so.  The next thing is (much simpler question),
assuming I'm wrong about the above stuff, all I need to do for the
GnomeCavas* methods/functions is something like this in the
src/gnome.defs file:

(define-func gnome_canvas_get_scroll_region
  none
  ((GnomeCanvas canvas)
   (double* x1)
   (double* y1)
   (double* x2)
   (double* y2)))

where the C api looks like:

void        gnome_canvas_get_scroll_region  (GnomeCanvas *canvas,
                                             double *x1,
                                             double *y1,
                                             double *x2,
                                             double *y2);

Brad

On Tue, 2001-08-28 at 05:49, Jeffrey Morgan wrote:
> Brad,
> 
> Here are some pointers to help you get started.  The bindings
> can be extended in four ways.  The are:
> 
> 1) The first is adding entries to the defs files located 
> in src/defs directory.  The entries in these files drive 
> what the code generator creates.  
> 
> 2) The next way to extend the bindings is to make new 
> entries in the src/tools/JNIProps.txt file.  This file 
> helps determine how the code is generated.  You can 
> define new types in this file and then use them in 
> the defs files.  
> 
> 3) The third way to extend the bindings is to write 
> the code by hand.  This is necessary when you run into 
> a situation that the generator cannot handle even by 
> extending the bindings with the first two techniques.  
> You add manual code to generated classes by adding 
> files into the src/code/jni directories.  The code
> in the java directory is added to the end of the generated
> java files and the code in the glue directory is added
> to the end of the generated native code.
> 
> 4) The final way to extend the bindings is to write
> new classes and native code which are not a part of the
> code generation process.  These files are placed in the
> src/other directory and must be added to the Makefile
> to ensure they are part of the build.
> 
> Any help you could provide would be greatly appreciated.
> 
> -Jeff
> 
> > 
> > Priority? No, not really.  It just seems that they are some very nice
> > gui tools that can accomplish some cool things. I'll download the
> > lastest cvs snapshot and see if I can help work on them.  
> > Thanks for the
> > timely reply.
> > 
> > Brad
> > 
> > On Mon, 2001-08-27 at 05:51, Jeffrey Morgan wrote:
> > > I am sorry to say that the Canvas classes are incomplete.
> > > If this is a priority for you then I can possibly place
> > > it on my schedule to work on after I release 0.7.0 in
> > > about two weeks.
> > > 
> > > -Jeff
> > > 
> > > > 
> > > > Hi,
> > > > Does anyone know what to use the GnomeCanasePoints class? Are the
> > > > various canvas classes fully implemented yet?  I've just 
> > > > starting to use
> > > > the java-gnome stuff and so far it's seem to work great (I 
> > > > went through
> > > > the tutorials).  I'm also interest in the gnome-canvas 
> > class but can't
> > > > seem to get them to work.  I've been trying to convert a 
> > tutorial I
> > > > found at IBM to java-gnome, but I can't figure out how to use the
> > > > GnomeCanvasPoints stuff.  If I get the program going I'll 
> > > > post it here.
> > > > (Every little bit helps right?)
> > > > 
> > > > You guys are doing some great work here.
> > > > 
> > > > Thanks
> > > > Brad
> > > > 
> > > > 
> > > > _______________________________________________
> > > > java-gnome-developer mailing list
> > > > jav...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > > > 
> > 
> > 

RE: [Java-gnome-developer] Aboiut ZvtTerm

[Damien <da...@ca...>]

No, sorry, I had problem with fetchmail and I didn't see your mail ...

On 27 Aug 2001 11:49:11 -0400, Jeffrey Morgan wrote:
> Did you add the two entries to the src/Makefile?
> 
> > 
> > Hi
> > 
> > I'm unable to use ZvtTerm. I get an "unresolved symbol
> > zvt_term_new_with_size". I looked in src/code/jni/glue/ and 
> > in ZvtTerm.c
> > the function is called 
> > Java_gnu_gnome_ZvtTerm_zvt_1term_1new_1with_1size
> > , the same thing in ZvtTerm.h . I tried removing the 1s and recompling
> > but I get the following error:
> > 
> > Exception in thread "main" java.lang.UnsatisfiedLinkError:
> > zvt_term_new_with_size
> > 	at gnu.gnome.ZvtTerm.zvt_term_new_with_size(Native Method)
> > 	at gnu.gnome.ZvtTerm.<init>(ZvtTerm.java:44)
> > 	at MultiShell.<init>(MultiShell.java:17)
> > 	at MultiShell.main(MultiShell.java:29)
> > 
> > Any idea what's wrong ?
> > 
> > Dam
> > 
> > 
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > http://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> >