java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] build problems

[Jeffrey M. <ku...@zo...>]

During the gnome build it is also trying to link with
gtkjava2.5.

On Tue, 2003-12-23 at 09:30, Jeffrey Morgan wrote:
> There still are some build problems.  Please see the
> developers list for a report of a problem.  I am also
> failing during the linking of the vte lib because
> it is trying to link with gtkjava0.11.  Mark, can you
> take a look at this.
> 
> -Jeff
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] build problems

[Jeffrey M. <ku...@zo...>]

There still are some build problems.  Please see the
developers list for a report of a problem.  I am also
failing during the linking of the vte lib because
it is trying to link with gtkjava0.11.  Mark, can you
take a look at this.

-Jeff

[java-gnome-hackers] Update

[Jeffrey M. <ku...@zo...>]

For the build yesterday I did the following:

Added new classes from GTK 2.3:
	ColorButton
	ComboBox
	ComboBoxEntry
	EntryCompletion
	FileChooserAction (needed for FileChooser)
	FileChooserError (needed for FileChooser)
	BindingSet

Added two new methods to Entry to utilize the
EntryCompletion class.

I deprecated the following classes:
	gtk.Combo (replaced by ComboBox)
	gnome.Entry
	gnome.ColorPicker (replaced by ColorButton)


Since the build I have done the following:

Added the following new classes:
	Action (glue code)
	ActionGroup (glue code)
	Expander (glue code and JNI)


The following items need to be completed.  Please
let the list know if you intend to work on one of
these items so we do not duplicate work.

1) Javadoc comments need to be added to ComboBox,
ComboBoxEntry, ColorButton, EntryCompletion and
the two new methods for Entry.

2) Complete the public interface for BindingSet

3) Complete the JNI code for Action and ActionGroup
(I will do this)

4) Write the public interface for Action, ActionGroup
and Expander.

5) Update the examples with these new classes.

There are many additional classes that we will need
to add in order to support the latest gtk but I think
we should complete these first.  Let me know what you
think.

-Jeff

Re: [java-gnome-hackers] Language-Bindings

[Jeffrey M. <ku...@zo...>]

> Well guys, it seems our (yours) work it's been really appreciated, and
> that's great ;) !! It's a great news for Christmas, and while I'm at it
> I want to say best wishes to you all ;)

Happy Holidays to all.  

After looking at all of the changes for the new GTK I can
say that we have much work ahead.  Several have stated that
they do not like the UIInfo class.  Don't wory.  This has
been replaced and we have a chance to rework this.

We can only be successfull if we work together as a team.
I really look forward to working with each of you.

-Jeff

Re: [java-gnome-hackers] Version numbers

[Luca De R. <pie...@li...>]

Il sab, 2003-12-20 alle 11:59, Mark Howard ha scritto:
> Hi,
>   I've made changes to the source so that most modules are created
> version 2.5.1, except gtk and libgconf which are 2.3.1 and libvte is
> 0.11. The all-in-one tarball is 2.5.1. 
>  The only upstream version numbers we don't copy now are atk (1.5) and
> pango (1.3). This is acceptable since gtk is the main component of that
> tarball, so we should be using gtk versions.
Great, this is the best solution we can find for our versioning needs.

 
> I only have internet access for a few more hours, so please try to find
> bugs in these changes now rather than later.
I'm afraid I couldn't do nothing until tomorrow, sorry ;)

-- 
Luca De Rugeriis <pie...@li...>

[java-gnome-hackers] Help needed

[Jeffrey M. <ku...@zo...>]

So far I have added the jni and glue code for the following new 
objects to the gtk packages from gtk2.3.1:

ColorButton
ComboBox
ComboBoxEntry
EntryCompletion
BindingSet

I also added a couple of new methods to Entry.

I plan to add the jni and glue code for:

FileChooser
FileChooserDialog
FileChooserWidget

Our 2.5.1 tarballs are due on December 22nd.  This means that I
will be creating them in about 48 hours from now.  The question
I have is who is able to work on the public interface to the
above classes?  I would like to see as many of them completed by
the 22nd as possible.

-Jeff

[java-gnome-hackers] Version numbers

[Mark H. <mh...@ca...>]

Hi,
  I've made changes to the source so that most modules are created
version 2.5.1, except gtk and libgconf which are 2.3.1 and libvte is
0.11. The all-in-one tarball is 2.5.1. 
 The only upstream version numbers we don't copy now are atk (1.5) and
pango (1.3). This is acceptable since gtk is the main component of that
tarball, so we should be using gtk versions.

I only have internet access for a few more hours, so please try to find
bugs in these changes now rather than later.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] Re: [Java-gnome-announce] ChessBrain: World Record!

[Mark H. <mh...@ca...>]

Jeff- 
 could you please change the java-gnome announce mailing list to
moderated posting only. It looks really bad to have more spam emails
than real ones. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] Process for next release

[Luca De R. <pie...@li...>]

Il ven, 2003-12-19 alle 17:35, Mark Howard ha scritto:
> On Fri, Dec 19, 2003 at 10:58:53AM -0500, Jeffrey Morgan wrote:
> > Please let me know what you think of this process.  Also, please let me know
> > if you
> > wish to work on the JNI or interface.  I will be working on the JNI.
> 
> Excellent. I think we should try to focus on getting a lot of the jni
> code done first, then make details available to java-gnome developer.
> There are a number of java programmers interested in helping who know
> nothing of gtk and little of jni.
I'm one of them, but I know a little of gtk but nothig of C.
I was trying to write the java class for PasswordDialog but first I need
to learn how it works: I haven't had the time to understand how the
constructor works, I hope I could learn something maybe from the
BindingSet class.
However on next Monday I'll have access to a good pc for about ten days,
so I'll try to contribute some code. (Until now I haven't had a chance
to make a nice build and to try the renewed library yet, sorry!)

I would like, after vacations, to begin to write the basis of
java-gnome-demo and to create a new Sf project for Cromagnon.

-- 
Luca De Rugeriis <pie...@li...>

RE: [java-gnome-hackers] Process for next release

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

> Excellent. I think we should try to focus on getting a lot of the jni
> code done first, then make details available to java-gnome developer.
> There are a number of java programmers interested in helping who know
> nothing of gtk and little of jni. They could easily help write the
> public api and send patches for us to review. If they do 
> this, they are
> also likely to help writing example apps. 

Let's see how this works.  I just committed the JNI and glue code
for the new objects ComboBox, ComboBoxEntry and EntryCompletion.  
I also added two new methods to the Entry widget that utilize the
EntryCompletion object.  Please post to the list prior to starting
on the classes.

-Jeff

Re: [java-gnome-hackers] ChangeLog

[Mark H. <mh...@ca...>]

On Fri, Dec 19, 2003 at 11:01:48AM -0500, Jeffrey Morgan wrote:
> We really need to keep a ChangeLog for our project.  Also, we need
> to create and maintain a NEWS file.  Thoughts?

cvs2cl, or something else automated for the changelog. NEWS file is a
good idea, if we all remember to update it when we make any changes.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] Process for next release

[Mark H. <mh...@ca...>]

On Fri, Dec 19, 2003 at 10:58:53AM -0500, Jeffrey Morgan wrote:
> Please let me know what you think of this process.  Also, please let me know
> if you
> wish to work on the JNI or interface.  I will be working on the JNI.

Excellent. I think we should try to focus on getting a lot of the jni
code done first, then make details available to java-gnome developer.
There are a number of java programmers interested in helping who know
nothing of gtk and little of jni. They could easily help write the
public api and send patches for us to review. If they do this, they are
also likely to help writing example apps. 

Just as a reminder, we should be making good use of the javadoc @since
and @deprecated tags.

I'm going away for a while so don't know what I'll be able to do at the
moment. I also have a uni project to be doing but I should have some
time for programming. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] ChangeLog

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

We really need to keep a ChangeLog for our project.  Also, we need
to create and maintain a NEWS file.  Thoughts?

-Jeff

[java-gnome-hackers] RE: Process for next release

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

Correction.  Where I mention the PasswordDialog below I really
mean the BindingSet in the gtk package.

> We need to workout our process for the next release.  After
> reviewing the latest gtk I see that there are many objects that
> have been added that we should support.  Here is a list of
> header files that contain new objects:
> 
> < gtkaction.h
> < gtkactiongroup.h
> < gtkcelllayout.h
> < gtkcolorbutton.h
> < gtkcombobox.h
> < gtkcomboboxentry.h
> < gtkentrycompletion.h
> < gtkexpander.h
> < gtkfilechooser.h
> < gtkfilechooserdialog.h
> < gtkfilechooserwidget.h
> < gtkfilefilter.h
> < gtkfilesystem.h
> < gtkfontbutton.h
> < gtkicontheme.h
> < gtkradioaction.h
> < gtkradiotoolbutton.h
> < gtkseparatortoolitem.h
> < gtktoggleaction.h
> < gtktoggletoolbutton.h
> < gtktoolbutton.h
> < gtktoolitem.h
> < gtktreemodelfilter.h
> < gtkuimanager.h
> 
> For each object we will need to write the glue code (the 
> protected java methods
> that make the calls to the JNI C code), the JNI code, the 
> public iterface, and any
> example apps to demonstrate how it is used.  We also need to 
> deprecate the old
> widgets.
> 
> I propose that we do the following:
> 
> 1) Those who know JNI well can write the glue and jni code 
> for each object.  Once
> this is complete they will check it into cvs and inform this 
> list.  To see an example
> of the state of the java class at this time please look at 
> the new PasswordDialog object
> in the gnome package.  The glue code is inside of the 
> comments at the bottom of the
> file.  Also, this developer will be responsible for any 
> additional Enum or Flag classes
> needed to support the new Object.
> 2) Another developer that wishes to write the public 
> interface for this object will notify
> the list so we don't have more than one person working on the 
> same code.  To see and
> example of the public interface please look at the 
> PasswordDialog constructor.  The
> public interface should be as complete as possible and 
> contain useful javadocs.  If the
> new object is replacing an old object the developer should 
> deprecate the old widget once
> the new one is complete.  Also, the developer should consider 
> writing an example to
> test the widget and to also demonstrate its' usage.
> 
> Please let me know what you think of this process.  Also, 
> please let me know if you
> wish to work on the JNI or interface.  I will be working on the JNI.
> 
> -Jeff

[java-gnome-hackers] Process for next release

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

We need to workout our process for the next release.  After
reviewing the latest gtk I see that there are many objects that
have been added that we should support.  Here is a list of
header files that contain new objects:

< gtkaction.h
< gtkactiongroup.h
< gtkcelllayout.h
< gtkcolorbutton.h
< gtkcombobox.h
< gtkcomboboxentry.h
< gtkentrycompletion.h
< gtkexpander.h
< gtkfilechooser.h
< gtkfilechooserdialog.h
< gtkfilechooserwidget.h
< gtkfilefilter.h
< gtkfilesystem.h
< gtkfontbutton.h
< gtkicontheme.h
< gtkradioaction.h
< gtkradiotoolbutton.h
< gtkseparatortoolitem.h
< gtktoggleaction.h
< gtktoggletoolbutton.h
< gtktoolbutton.h
< gtktoolitem.h
< gtktreemodelfilter.h
< gtkuimanager.h

For each object we will need to write the glue code (the protected java
methods
that make the calls to the JNI C code), the JNI code, the public iterface,
and any
example apps to demonstrate how it is used.  We also need to deprecate the
old
widgets.

I propose that we do the following:

1) Those who know JNI well can write the glue and jni code for each object.
Once
this is complete they will check it into cvs and inform this list.  To see
an example
of the state of the java class at this time please look at the new
PasswordDialog object
in the gnome package.  The glue code is inside of the comments at the bottom
of the
file.  Also, this developer will be responsible for any additional Enum or
Flag classes
needed to support the new Object.
2) Another developer that wishes to write the public interface for this
object will notify
the list so we don't have more than one person working on the same code.  To
see and
example of the public interface please look at the PasswordDialog
constructor.  The
public interface should be as complete as possible and contain useful
javadocs.  If the
new object is replacing an old object the developer should deprecate the old
widget once
the new one is complete.  Also, the developer should consider writing an
example to
test the widget and to also demonstrate its' usage.

Please let me know what you think of this process.  Also, please let me know
if you
wish to work on the JNI or interface.  I will be working on the JNI.

-Jeff

[java-gnome-hackers] cvs branch

[Mark H. <mh...@ca...>]

I've just created a maint-0_8 branch of the java-gnome/java-gnome module
in cvs. This can be used if we need to fix any bugs and make releases of
0.8 (for gnome 2.2) before Java-Gnome 1.0 is released next year. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] setting library path - garnome

[Luca De R. <pie...@li...>]

Il mar, 2003-12-16 alle 20:33, Mark Howard ha scritto:
> I've looked more, but not found a solution. Even if the garnome path is
> searched first, gcc will find the headers in the system path for the
> gnomeui widgets which have been removed. 
> 
> gcc has an option -nostdinc to make it stop searching standard include
> paths. Unfortunately it then can't find lots of other things it does
> need, which aren't in garnome.
I' ve found:

> Also, what's the correct way to install garnome in /usr like gnome1 
> (or where ever gnome1 is installed). Do I just make the build prefix 
> /usr (currently I build garnome in /opt).

I haven't done that and it hasn't stopped me from using gnome-2 
exclusively for use *and* development for quite some time.  Though you'd 
just have to change some values in gar.conf.mk
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Uhm... you should post your question there (garnome-list) if it hasn't
be done already.

-- 
Luca De Rugeriis <pie...@li...>

Re: [java-gnome-hackers] setting library path - garnome

[Mark H. <mh...@ca...>]

I've looked more, but not found a solution. Even if the garnome path is
searched first, gcc will find the headers in the system path for the
gnomeui widgets which have been removed. 

gcc has an option -nostdinc to make it stop searching standard include
paths. Unfortunately it then can't find lots of other things it does
need, which aren't in garnome.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] setting library path - garnome

[Mark H. <mh...@ca...>]

On Tue, Dec 16, 2003 at 04:32:24PM +0100, Luca De Rugeriis wrote:
> Il mar, 2003-12-16 alle 12:12, Mark Howard ha scritto:
> > I've now got garnome installed, but haven't managed to compile
> > java-gnome against it. The configure script picks up the directories
> > from garnome, but also includes the system directories - java-gnome uses
> > these and compiles against the old libraries. Can anyone advise how to
> > tell the build system to use garnome libraries instead?
> Is it solved? I was thinking: just put garnome libs directory before
> system libs dir in LD_LIBRARY_PATH? However I guess there will be a lot
> of pointers about developing with garnome, after all it's intended for
> developers ;)

Not yet. I've also found surprisingly little documentation about
developing under garnome.
garnome sets LD_LIBRARY_PATH anyway, so that hasn't fixed the problem.
I don't think configure uses LD_LIBRARY_PATH anyway.

Looking at it more closely, the problem seems to be that gcc is passed
-I/usr/include/ before the -I/...GAR...

This is part of the CFLAGS variable, so perhaps moving $(CFLAGS) to the
end of the .c.o target in common/src-Makefile.in.common will fix it.

Unfortunately this means changing a make files once again, so everything
will be recompiled. It's still compiling so I don't know if it's worked
or not. Slow computer.

...
no, that didn't work - java-gnome still compiles fine.

Does anyone have any other suggestions?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] setting library path - garnome

[Luca De R. <pie...@li...>]

Il mar, 2003-12-16 alle 12:12, Mark Howard ha scritto:
> I've now got garnome installed, but haven't managed to compile
> java-gnome against it. The configure script picks up the directories
> from garnome, but also includes the system directories - java-gnome uses
> these and compiles against the old libraries. Can anyone advise how to
> tell the build system to use garnome libraries instead?
Is it solved? I was thinking: just put garnome libs directory before
system libs dir in LD_LIBRARY_PATH? However I guess there will be a lot
of pointers about developing with garnome, after all it's intended for
developers ;)

-- 
Luca De Rugeriis <pie...@li...>

Re: [java-gnome-hackers] setting library path - garnome

[Luca De R. <pie...@li...>]

Il mar, 2003-12-16 alle 12:12, Mark Howard ha scritto:
> I've now got garnome installed, but haven't managed to compile
> java-gnome against it. The configure script picks up the directories
> from garnome, but also includes the system directories - java-gnome uses
> these and compiles against the old libraries. Can anyone advise how to
> tell the build system to use garnome libraries instead?
Uhm, I could only think: remove Gnome, then install Garnome in $PREFIX
(pheeewww ;)

-- 
Luca De Rugeriis <pie...@li...>

[java-gnome-hackers] setting library path - garnome

[Mark H. <mh...@ca...>]

I've now got garnome installed, but haven't managed to compile
java-gnome against it. The configure script picks up the directories
from garnome, but also includes the system directories - java-gnome uses
these and compiles against the old libraries. Can anyone advise how to
tell the build system to use garnome libraries instead?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

RE: [java-gnome-hackers] Upgrades to gtk+2.3.0 - automation possi ble?

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

>   I've installed garnome and stated looking at the gtk todo lists. It
> seems we are actually ahead of gtk2.0 at the moment, but I'm not sure
> exactly where. At least that means we might just be able to check and
> tick off many of the items at the lower end of the todo. 

I believe we are pretty close to gtk2.2.

> Jeff-
>   Would it be possible to use the code generator to find the 
> differences
> between our code and the latest upstream code, then generate the code
> for the individual functions? We could then modify and insert the code
> into the java-gnome source. Do the defs files exist for the 
> latest gtk?

I am not sure if the def files do exist for the latest gtk.  Also,
the def files were changing and the generator was not changed to
the latest format.  Unfortunately I believe this is going to be a
manual process.  

It is not necessary (nor desirable) to match each and every method
in the native lib with a method in java-gnome.  What is important is that
we provide all of the core functionality that is not already provided for
in Java.  For this release we should look for new widgets that we currently 
do not support or new capabilities that were added to existing widgets 
that we do not support.

[java-gnome-hackers] Upgrades to gtk+2.3.0 - automation possible?

[Mark H. <mh...@ca...>]

Hi,
  I've installed garnome and stated looking at the gtk todo lists. It
seems we are actually ahead of gtk2.0 at the moment, but I'm not sure
exactly where. At least that means we might just be able to check and
tick off many of the items at the lower end of the todo. 

Jeff-
  Would it be possible to use the code generator to find the differences
between our code and the latest upstream code, then generate the code
for the individual functions? We could then modify and insert the code
into the java-gnome source. Do the defs files exist for the latest gtk?

Or, do you have any other suggestions on how we can make the task a
little easier?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] FW: A GNOME Bindings release set?

[Mark H. <mh...@ti...>]

Another message that bounced, thanks to freeserve spam avoidance (they
eat all emails going through the network - I'm not even using their smtp
servers). I think my emails should be working right now.

> On Wed, Dec 03, 2003 at 03:44:34PM +0100, Luca De Rugeriis wrote:
> > Il mer, 2003-12-03 alle 15:20, Mark Howard ha scritto:
> > > On Wed, Dec 03, 2003 at 02:15:42PM +0100, Luca De Rugeriis wrote:
> > > > in Fedora. The only question is: how distributions could cope with a
> > > > package the requires a JDK to compile? 
> > > > Mark, Debian community thoughts on this?
> > > 
> > > Java-gnome is already in Debian -- I maintain the packages myself.
> > > Compilation is done with jikes and other free tools. (I also have a
> > > wrapper script for the ant parts, but few distributions consider ant to
> > > be non-free)
> > Thanks, it means that I have to end up with an Ant, Jikes and Java-Gnome
> > package proposal. I don't know what Fedora's guys think aobut Ant, I
> > have to ask. AFAIK we can't compile without Ant, right?
> Ant depends on sun jvm per default. A few ppl have made it work with
> free tools, but the debian packages haven't done so and hence it isn't
> in debian main. I'm using a little script to replace the ant
> functionality - it's quite simple.
> 
> > Does Java-gnome compiles with Jikes out of the box?
> yes.
> 
> If you want to take a look at the debian packaging scripts I'm using,
> they're available at packages.debian.org (java-gnome package, diff.gz
> file). This site is unfortunately down atm though.
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca...