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

RE: [java-gnome-hackers] symlink

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

> On Sat, Jan 03, 2004 at 03:46:37PM -0500, Joe Marcus Clarke wrote:
> > --- gtk/Makefile.in.in.orig	Sat Jan  3 15:37:23 2004
> > +++ gtk/Makefile.in.in	Sat Jan  3 15:42:30 2004
> > @@ -13,6 +13,7 @@
> >  	-$(INSTALL) -d $(DESTDIR)$(datadir)/doc/java-gnome-$(apiversion)
> >  	-$(INSTALL) -d $(DESTDIR)$(libdir)/
> >  	$(INSTALL) -m644 
> lib/libgtkjava$(gtkapiversion).so.$(gtkversion) $(DESTDIR)$(libdir)/
> > +	@ln -s 
> $(DESTDIR)$(libdir)/libgtkjava$(gtkapiversion).so.$(gtkversion
> ) $(DESTDIR)$(libdir)/libgtkjava$(apiversion).so

Is this correct or should it read:

	ln -s
$(DESTDIR)$(libdir)/libgtkjava$(gtkapiversion).so.$(gtkversion)
$(DESTDIR)$(libdir)/libgtkjava$(gtkapiversion).so


-Jeff

RE: [java-gnome-hackers] symlink

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

The release is already out and the announcement has been sent.
Do you think we should wait until the next release (in two weeks)?

-Jeff

> Jeff-
>   I've just noticed that I accidentally removed the symlink lines for
> the java so files when sorting out the make system. I'm not able to
> change this at the moment, could you possibly do it before releasing
> 2.5.2?
> 
> It requires a patch like the one below for the install target of each
> module/Makefile.in.in 
>   
> On Sat, Jan 03, 2004 at 03:46:37PM -0500, Joe Marcus Clarke wrote:
> > --- gtk/Makefile.in.in.orig	Sat Jan  3 15:37:23 2004
> > +++ gtk/Makefile.in.in	Sat Jan  3 15:42:30 2004
> > @@ -13,6 +13,7 @@
> >  	-$(INSTALL) -d $(DESTDIR)$(datadir)/doc/java-gnome-$(apiversion)
> >  	-$(INSTALL) -d $(DESTDIR)$(libdir)/
> >  	$(INSTALL) -m644 
> lib/libgtkjava$(gtkapiversion).so.$(gtkversion) $(DESTDIR)$(libdir)/
> > +	@ln -s 
> $(DESTDIR)$(libdir)/libgtkjava$(gtkapiversion).so.$(gtkversion
> ) $(DESTDIR)$(libdir)/libgtkjava$(apiversion).so
> >  	$(INSTALL) -m644 
> lib/gtk$(gtkapiversion)-$(gtkversion).jar 
> $(DESTDIR)$(datadir)/java-gnome
> >  	@ln -s gtk$(gtkapiversion)-$(gtkversion).jar 
> $(DESTDIR)$(datadir)/java-gnome/gtk$(gtkapiversion).jar
> >  	-for f in $(DOCUMENTS); do $(INSTALL) -m644 
> $(JG_DOC_DIR)/$$f 
> $(DESTDIR)$(datadir)/doc/java-gnome-$(apiversion); done
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 

[java-gnome-hackers] symlink

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

Jeff-
  I've just noticed that I accidentally removed the symlink lines for
the java so files when sorting out the make system. I'm not able to
change this at the moment, could you possibly do it before releasing
2.5.2?

It requires a patch like the one below for the install target of each
module/Makefile.in.in=20
 =20
On Sat, Jan 03, 2004 at 03:46:37PM -0500, Joe Marcus Clarke wrote:
> --- gtk/Makefile.in.in.orig	Sat Jan  3 15:37:23 2004
> +++ gtk/Makefile.in.in	Sat Jan  3 15:42:30 2004
> @@ -13,6 +13,7 @@
>  	-$(INSTALL) -d $(DESTDIR)$(datadir)/doc/java-gnome-$(apiversion)
>  	-$(INSTALL) -d $(DESTDIR)$(libdir)/
>  	$(INSTALL) -m644 lib/libgtkjava$(gtkapiversion).so.$(gtkversion) $(DEST=
DIR)$(libdir)/
> +	@ln -s $(DESTDIR)$(libdir)/libgtkjava$(gtkapiversion).so.$(gtkversion) =
$(DESTDIR)$(libdir)/libgtkjava$(apiversion).so
>  	$(INSTALL) -m644 lib/gtk$(gtkapiversion)-$(gtkversion).jar $(DESTDIR)$(=
datadir)/java-gnome
>  	@ln -s gtk$(gtkapiversion)-$(gtkversion).jar $(DESTDIR)$(datadir)/java-=
gnome/gtk$(gtkapiversion).jar
>  	-for f in $(DOCUMENTS); do $(INSTALL) -m644 $(JG_DOC_DIR)/$$f $(DESTDIR=
)$(datadir)/doc/java-gnome-$(apiversion); done

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

RE: [java-gnome-hackers] Ready for 2.5.2?

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

> I'm a little busy at the moment, but if somebody will check 
> it all into
> cvs, I will take over maintenance of the news section of the website,
> update these changes and notify the translators. We need to keep the
> most up to date info on the site. 
> 
> The gnome release set hasn't added us to their website yet - 
> do you know
> who to contact about this?

Just made the release.  The gconf module is still not building
due to the fact that the GCONF_FLAGS are not being set.

-Jeff

RE: [java-gnome-hackers] API freeze - reality

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

Il lun, 2004-01-05 alle 13:20, Jeffrey Morgan ha scritto:
> >   I am becoming increasingly worried that we may not be able 
> > to meet the
> > API freeze. There is an awful lot of work to be done.
> 
> I agree that there is an awful lot of work to be done but
> I am still optimistic that we can meet the API freeze date
> of Feb 16th.  The past few weeks have been holiday time and
> things have moved slowly.  Now that is behind us and I
> expect to have a lot of time to work on the bindings.
> 
> > 
> > IMHO, the release schedule with an API freeze is wrong for a language
> > binding - most of our time is spent modifying api. The reason for
> > freezes are so that the other parts of the project can catch up - ui,
> > translations, bug testing, etc. 
> > With the current schedule, we will probably have very little 
> > work to do
> > between the start of the api freeze and the start of mass 
> > development of
> > the next major version. However, we will be very busy the rest of the
> > time.
> 
> Perhaps we can use this time to fix bugs, enhance examples, and
> write documentation.

> > To make our plans more realistic, I would like to propose that we now
> > concentrate on designing an API rather than implementation 
> > and then add
> > the implementation either at the same time or just after designing the
> > api. We may then spend the time after the freeze implementing our api
> > (as well as documenting, translating and creating example apps).
> > 
> > For example, I would like to add this java api to TreeSelection now:
> > public TreeRow[] getRows(){}
> > and then spend a long time doing the complicated 
> > implementation (based on
> > a function which returns a GList *) once all the api has been 
> > added for
> > gtk 2.4
> > 
> > Does anybody disagree strongly with this?
> 
> I agree with this approach.
It seems a good solution. In fact I was always thinking what we are
supposed to do between the api freeze and the final release.
I know that one of the major reasons is to not break api/abi for
applications developers, so at the moment it doesn't really apply to us
since there are few j-g apps around.
Anyhow we can use post-freeze time to fix bugs, write docs... too.

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

Re: [java-gnome-hackers] Ready for 2.5.2?

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

On Mon, Jan 05, 2004 at 07:26:58AM -0500, Jeffrey Morgan wrote:
> > When you upload the files, could you possibly send an announcement to
> > jav...@li... please? I think we should 
> > use this for
> > both stable and developmental releases. We should probably send it to
> > gno...@li... too (gtkmm does).
> 
> We also need to update the web site.  There still is no mention of the
> 0.8.2 release or any of the latest happenings with the gnome bindings
> release. Who can author these items and contact the web site authors?
I'm a little busy at the moment, but if somebody will check it all into
cvs, I will take over maintenance of the news section of the website,
update these changes and notify the translators. We need to keep the
most up to date info on the site. 

The gnome release set hasn't added us to their website yet - do you know
who to contact about this?

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

Re: [java-gnome-hackers] Ready for 2.5.2?

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

On Mon, Jan 05, 2004 at 07:26:58AM -0500, Jeffrey Morgan wrote:
> What error are you getting?  I am working on the ComboBox widget now.

The constructor changed between gtk 2.3.0 and 2.3.1. Your code is most
probably correct. I had the same problems when trying to build galeon
cvs recently. I will update my garnome on sunday when I'm back at uni.

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

RE: [java-gnome-hackers] Ready for 2.5.2?

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

> Jeff - I think the date for 2.5.2 is on Monday. Are you ok to make the
> tarballs on Monday? 

I hope to do this around 1:00 PM EST today.  This will give
me time to finish some work I have in progress now.  This will
also give other developers time to commit any changes they have 
for this release.

> When you upload the files, could you possibly send an announcement to
> jav...@li... please? I think we should 
> use this for
> both stable and developmental releases. We should probably send it to
> gno...@li... too (gtkmm does).

We also need to update the web site.  There still is no mention of the
0.8.2 release or any of the latest happenings with the gnome bindings
release. Who can author these items and contact the web site authors?


> Please remove the (not yet released) comment from common/NEWS before
> making the tarballs (as well as checking that the news file is up to
> date). 

Will do!

> Unfortunately I am unable to build java-gnome at the moment - ComboBox
> is failing to compile. I think this is probably because I am running
> gtk 2.3.0 rather than 2.3.1. I will not be able to upgrade until I get
> back to uni next week (not enough bandwidth at home).

What error are you getting?  I am working on the ComboBox widget now.


-Jeff

RE: [java-gnome-hackers] API freeze - reality

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

>   I am becoming increasingly worried that we may not be able 
> to meet the
> API freeze. There is an awful lot of work to be done.

I agree that there is an awful lot of work to be done but
I am still optimistic that we can meet the API freeze date
of Feb 16th.  The past few weeks have been holiday time and
things have moved slowly.  Now that is behind us and I
expect to have a lot of time to work on the bindings.

> 
> IMHO, the release schedule with an API freeze is wrong for a language
> binding - most of our time is spent modifying api. The reason for
> freezes are so that the other parts of the project can catch up - ui,
> translations, bug testing, etc. 
> With the current schedule, we will probably have very little 
> work to do
> between the start of the api freeze and the start of mass 
> development of
> the next major version. However, we will be very busy the rest of the
> time.

Perhaps we can use this time to fix bugs, enhance examples, and
write documentation.


> To make our plans more realistic, I would like to propose that we now
> concentrate on designing an API rather than implementation 
> and then add
> the implementation either at the same time or just after designing the
> api. We may then spend the time after the freeze implementing our api
> (as well as documenting, translating and creating example apps).
> 
> For example, I would like to add this java api to TreeSelection now:
> public TreeRow[] getRows(){}
> and then spend a long time doing the complicated 
> implementation (based on
> a function which returns a GList *) once all the api has been 
> added for
> gtk 2.4
> 
> Does anybody disagree strongly with this?

I agree with this approach.

-Jeff

RE: [java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnom e/gtk/src/java/org/gnu/gtk BindingSet.java,1.3,1.4 ColorSelectionDialog.j ava,1.7,1.8

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

> Hi,
>   Thanks for adding the javadoc.
> 
> On Mon, Dec 29, 2003 at 06:45:35PM -0800, Luca De Rugeriis wrote:
> > + 	 * @param keyval The key value for the BindingSet. It 
> must be a member of {@link org.gnu.gdk.KeySymbol}
> >   	public boolean activateBindings(int keyval, 
> ModifierType modifier) {
> 
> This seems wrong. We should not be passing around integers for things
> like this - it is not very good Java style. Instead, we should pass
> KeySymbol objects, from which the integers can be obtained. This means
> changing the KeySymbol class into an Enum subclass (it should be
> possible to do this quickly with a little automation - let me know if
> you want me to do it); and also modifying these methods to take
> KeySymbols instead of integers, passing keySymbol.getValue() to the
> native method.
> This is what we do for most similar parts of java-gnome, for example
> ModifierType.

You are correct.  This should be our consistent approach.

> The Java-Gnome project does not have the aim to simply bind the
> gtk/gnome libraries. If we did, we could probably do this 
> automatically.
> Instead, we are trying to write an intuitive 
> object-orientated api for a
> flat library. To make things worse, these libraries include api for
> functions which are useful to the end user and also many 
> functions which
> are either only useful internally by the library, or were 
> written in the
> hope that they would be useful, but in reality are not useful.
> Deciphering between these is not easy - so we don't want to make
> java-gnome users have to do this; we will just provide useful methods.
> The main way we do this is to think of situations where each method we
> write may be used. If we cannot think of such a situation for 
> a method,
> then perhaps it should not be included in java-gnome - at 
> this point we
> ask for other opinions on the mailing lists, or just don't 
> include it in
> the public api, preferably giving an explanation in a comment in the
> source file.
> 
> 
> Your work on that is done now - I'm sure it will be useful at 
> some point
> and certainly is much appreciated. Those comments above were 
> supposed to
> be just helpful hints - sorry if they come across wrong, I'm not the
> best person at writing that sort of thing. 
> 
> Your work on java-gnome is very impressive - I think it took 
> me quite a
> bit longer to get to the stage you're at now. I look forward to seeing
> many more cvs commits :)

I agree.  Please keep up the good work!!

[java-gnome-hackers] Ready for 2.5.2?

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

Jeff - I think the date for 2.5.2 is on Monday. Are you ok to make the
tarballs on Monday? 
When you upload the files, could you possibly send an announcement to
jav...@li... please? I think we should use this for
both stable and developmental releases. We should probably send it to
gno...@li... too (gtkmm does).

Please remove the (not yet released) comment from common/NEWS before
making the tarballs (as well as checking that the news file is up to
date). 

Unfortunately I am unable to build java-gnome at the moment - ComboBox
is failing to compile. I think this is probably because I am running
gtk 2.3.0 rather than 2.3.1. I will not be able to upgrade until I get
back to uni next week (not enough bandwidth at home).

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

[java-gnome-hackers] mksrcdir.sh; TODO.gtk

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

Hi,
  I've created a little mksrcdir.sh script to create a src symlink tree
which is hopefully a lot easier to navigate when editing the source.

I've also added a TODO.gtk file to gtk/. This is based on the NEWS file
of 2.3.0. 
We still have an awful lot to do. We must keep working very hard if we
are to make the deadline for the api freeze. We have a new release in a
few days following the schedule - A lot has been done since the last
release. Please check that your changes are included in the common/NEWS
file. 

I have been looking at some of the smaller changes on the TODO.gtk file.
Unfortunately my uni work means that I have little time to work on
java-gnome and so have not been able to work on any of the new classes. 

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

Re: [java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk/src/java/org/gnu/gtk BindingSet.java,1.3,1.4 ColorSelectionDialog.java,1.7,1.8

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

On Tue, Dec 30, 2003 at 10:54:50PM +0100, Luca De Rugeriis wrote:
> > On Mon, Dec 29, 2003 at 06:45:35PM -0800, Luca De Rugeriis wrote:
> > > + 	 * @param keyval The key value for the BindingSet. It must be a member of {@link org.gnu.gdk.KeySymbol}
> > >   	public boolean activateBindings(int keyval, ModifierType modifier) {
...
> This was the cause of doing so. However if you have a chance, please
> make those changes, cause it's a more correct way of doing things ;)
I think these are now done. 

> > KeySymbols instead of integers, passing keySymbol.getValue() to the
> > native method.
> I'll do this after you've commited the above changes.

> above all the importance of not breaking api/abi . However I was
> assuming that our head branch was the right place to add new classes,
> until we are going to do an api freeze.
That's correct. I was just questioning whether that class needed to be
added at all. 
> So what we need to do before api freeze? (apart from fixing known bugs?)
Add the new classes and add the new methods to existing classes. I've
now added gtk/TODO.gtk, which details exactly what we have to do. 

> They came across right ;) After all open discussion is what open source
> development is all about :)
> At this point I could easily remove those classes. We'll have no problem
> merging from a previous version when we'll decide they're are ready to
> fit in. (let me know)
No, leave them in. I think we have lots of other classes in gdk and
possibly pango which are never used too. (e.g. KeySymbol until a short
time ago)

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

[java-gnome-hackers] Possible memory leaks

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

Hi,
  I've been updating the text and and tree widgets. I've noticed some of
the functions return gchar *'s then we return a new java string based on
this. We don't free the gchar *'s. This is probably a mistake in most
cases. 

Although if I'm right, this is a big bug, we should wait until after api
freeze to look into it. 

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

[java-gnome-hackers] API freeze - reality

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

Hi,
  I am becoming increasingly worried that we may not be able to meet the
API freeze. There is an awful lot of work to be done.

IMHO, the release schedule with an API freeze is wrong for a language
binding - most of our time is spent modifying api. The reason for
freezes are so that the other parts of the project can catch up - ui,
translations, bug testing, etc. 
With the current schedule, we will probably have very little work to do
between the start of the api freeze and the start of mass development of
the next major version. However, we will be very busy the rest of the
time.

To make our plans more realistic, I would like to propose that we now
concentrate on designing an API rather than implementation and then add
the implementation either at the same time or just after designing the
api. We may then spend the time after the freeze implementing our api
(as well as documenting, translating and creating example apps).

For example, I would like to add this java api to TreeSelection now:
public TreeRow[] getRows(){}
and then spend a long time doing the complicated implementation (based on
a function which returns a GList *) once all the api has been added for
gtk 2.4

Does anybody disagree strongly with this?

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

[java-gnome-hackers] cvs revision number

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

How about incrementing the major revision number for all the files in
cvs? Since we have icremented our project major version, changing the
cvs one would be coherent.

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

Re: [java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk/src/java/org/gnu/gtk BindingSet.java,1.3,1.4 ColorSelectionDialog.java,1.7,1.8

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

Il mar, 2003-12-30 alle 11:53, Mark Howard ha scritto:
> Hi,
>   Thanks for adding the javadoc.
> 
> On Mon, Dec 29, 2003 at 06:45:35PM -0800, Luca De Rugeriis wrote:
> > + 	 * @param keyval The key value for the BindingSet. It must be a member of {@link org.gnu.gdk.KeySymbol}
> >   	public boolean activateBindings(int keyval, ModifierType modifier) {
> 
> This seems wrong. We should not be passing around integers for things
> like this - it is not very good Java style. Instead, we should pass
> KeySymbol objects, from which the integers can be obtained. This means
> changing the KeySymbol class into an Enum subclass (it should be
> possible to do this quickly with a little automation - let me know if
> you want me to do it);
I talked to Jeff and he suggested: "The method should take an integer
and the user would type something like KeySymbol.F12.  Just
make sure that the javadoc clearly states that
the int is one of the public members of KeySymbol."
This was the cause of doing so. However if you have a chance, please
make those changes, cause it's a more correct way of doing things ;)

>  and also modifying these methods to take
> KeySymbols instead of integers, passing keySymbol.getValue() to the
> native method.
I'll do this after you've commited the above changes.

> Luca, for your other comments about not knowing when a class may be
> instantiated - 
> Perhaps it would have been better to wait until we knew these things
> before writing the java-gnome api for the class. 
> When we write public API, it is very difficult to change after people
> start using it. Therefore, it is best if we can get it done right first
> time. I am worried that we may find ourselves in the situation that e.g.
> gtk (or, even worse, swing) is in - they have api that they designed a
> long time ago that is now deprecated (they have found better ways of
> doing it, or just don't like the feel of the old api), but they cannot
> change it since so many applications are using it. 
> 
> The Java-Gnome project does not have the aim to simply bind the
> gtk/gnome libraries. If we did, we could probably do this automatically.
> Instead, we are trying to write an intuitive object-orientated api for a
> flat library. To make things worse, these libraries include api for
> functions which are useful to the end user and also many functions which
> are either only useful internally by the library, or were written in the
> hope that they would be useful, but in reality are not useful.
> Deciphering between these is not easy - so we don't want to make
> java-gnome users have to do this; we will just provide useful methods.
> The main way we do this is to think of situations where each method we
> write may be used. If we cannot think of such a situation for a method,
> then perhaps it should not be included in java-gnome - at this point we
> ask for other opinions on the mailing lists, or just don't include it in
> the public api, preferably giving an explanation in a comment in the
> source file.
I totally agree with you and I feel the importance of the public api and
above all the importance of not breaking api/abi . However I was
assuming that our head branch was the right place to add new classes,
until we are going to do an api freeze.
Since Jeff's todo list includes writing a bunch of public apis, I was
thinking this was the best moment to add new stuff. When we'll have the
api frozen, we cannot do that , definately.
So what we need to do before api freeze? (apart from fixing known bugs?)

> Your work on that is done now - I'm sure it will be useful at some point
> and certainly is much appreciated. Those comments above were supposed to
> be just helpful hints - sorry if they come across wrong, I'm not the
> best person at writing that sort of thing. 
They came across right ;) After all open discussion is what open source
development is all about :)
At this point I could easily remove those classes. We'll have no problem
merging from a previous version when we'll decide they're are ready to
fit in. (let me know)

> Your work on java-gnome is very impressive - I think it took me quite a
> bit longer to get to the stage you're at now. I look forward to seeing
> many more cvs commits :)
Thanks, I'm taking this as a compliment considered that I'm a uni
student and that it's really few days that I'm looking into j-g source,
and of course there will be many more commits;)


Happy new year.
-- 
Luca De Rugeriis <pie...@li...>

[java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk/src/java/org/gnu/gtk BindingSet.java,1.3,1.4 ColorSelectionDialog.java,1.7,1.8

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

Hi,
  Thanks for adding the javadoc.

On Mon, Dec 29, 2003 at 06:45:35PM -0800, Luca De Rugeriis wrote:
> + 	 * @param keyval The key value for the BindingSet. It must be a member of {@link org.gnu.gdk.KeySymbol}
>   	public boolean activateBindings(int keyval, ModifierType modifier) {

This seems wrong. We should not be passing around integers for things
like this - it is not very good Java style. Instead, we should pass
KeySymbol objects, from which the integers can be obtained. This means
changing the KeySymbol class into an Enum subclass (it should be
possible to do this quickly with a little automation - let me know if
you want me to do it); and also modifying these methods to take
KeySymbols instead of integers, passing keySymbol.getValue() to the
native method.
This is what we do for most similar parts of java-gnome, for example
ModifierType.


Luca, for your other comments about not knowing when a class may be
instantiated - 
Perhaps it would have been better to wait until we knew these things
before writing the java-gnome api for the class. 
When we write public API, it is very difficult to change after people
start using it. Therefore, it is best if we can get it done right first
time. I am worried that we may find ourselves in the situation that e.g.
gtk (or, even worse, swing) is in - they have api that they designed a
long time ago that is now deprecated (they have found better ways of
doing it, or just don't like the feel of the old api), but they cannot
change it since so many applications are using it. 

The Java-Gnome project does not have the aim to simply bind the
gtk/gnome libraries. If we did, we could probably do this automatically.
Instead, we are trying to write an intuitive object-orientated api for a
flat library. To make things worse, these libraries include api for
functions which are useful to the end user and also many functions which
are either only useful internally by the library, or were written in the
hope that they would be useful, but in reality are not useful.
Deciphering between these is not easy - so we don't want to make
java-gnome users have to do this; we will just provide useful methods.
The main way we do this is to think of situations where each method we
write may be used. If we cannot think of such a situation for a method,
then perhaps it should not be included in java-gnome - at this point we
ask for other opinions on the mailing lists, or just don't include it in
the public api, preferably giving an explanation in a comment in the
source file.


Your work on that is done now - I'm sure it will be useful at some point
and certainly is much appreciated. Those comments above were supposed to
be just helpful hints - sorry if they come across wrong, I'm not the
best person at writing that sort of thing. 

Your work on java-gnome is very impressive - I think it took me quite a
bit longer to get to the stage you're at now. I look forward to seeing
many more cvs commits :)

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

Re: [java-gnome-hackers] new team member

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

Il mer, 2003-12-24 alle 10:46, Mark Howard ha scritto:
> (hmmm - We could do with keeping track of who these translators are,
> which languages and translation status. Perhaps we should have a page on
> the website giving details of java-gnome team members and what they do)
This would be great. Maybe, at this point, I could look into mantaining
the site even if I'm not a webmaster. However adding such a page or
keeping the news page updated shouldn't be too hard.
Mark, a page with java-gnome memebers' details will be very useful.
Also we should keep track on translations (site translation and docs
translation), like many projects I've seen do.(With a nice web
interface...)
Eventually I could even write the Italian one, in the future ;)

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

Re: [java-gnome-hackers] org.gnu.gtk.Action

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

Il sab, 2003-12-27 alle 13:57, Mark Howard ha scritto:
> Hi, 
>   Documenting these new classes would be *really* useful - especially
> for those of us who have never used the c versions.
> 
> On Sat, Dec 27, 2003 at 01:12:54AM +0100, Luca De Rugeriis wrote:
> > I'm unsure about the constructor; Should it be: 
> > 	public Action(int handle) {
> > 		super(handle);
> 
> This should probably not be public. Methods which take an int handle
> should be used only internally by java-gnome - our users should not need
> to know about handles and other c things (e.g. memory management). In
> some cases, they have to be public (where they are constructed by other
> packages, e.g. pango objects being constructed internally from within
> gtk package. If this is the case, the javadoc must say that this method
> should only be used internally by java-gnome.
Totally agreed.

> This is probably a case of documentation... but where would you get an
> Action object from? 
The GtkAction struct contains only private members and should not be
accessed directly. (from gtk docs)
I think it means private etc. but I don't know how these objects are
created, if I don't understand the C source I can't figure it out well.
There is no action_new method, or something.

I'll integrate documentation in these new classes asap.
		
-- 
Luca De Rugeriis <pie...@li...>

Re: [java-gnome-hackers] BindingSet (was: Update)

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

Il sab, 2003-12-27 alle 13:17, Jeffrey Morgan ha scritto:
> This looks fine to me.  
> 
> -Jeff
> 
> On Fri, 2003-12-26 at 22:59, Luca De Rugeriis wrote:
> > This is the finished class (javadocs apart):
> > 
> > /*
> >  * Java-Gnome Bindings Library
> >  *
> >  * Copyright 1998-2002 the Java-Gnome Team, all rights reserved.
> >  *
> >  * The Java-Gnome bindings library is free software distributed under
> >  * the terms of the GNU Library General Public License version 2.
> >  */
> > package org.gnu.gtk;
> > 
> > import org.gnu.gdk.ModifierType;
> > import org.gnu.glib.Boxed;
> > 
> > /**
> >  * Key bindings for individual widgets
> >  */
> > public class BindingSet extends Boxed {
> > 	
> > 	/**
> > 	 * Construct a new BindingSet using a handle to a native resource.
> > 	 */
> > 	public BindingSet(int handle) {
> > 		this.handle = handle;
> > 	}
> > 	
> > 	/**
> > 	 * Construct a new BindingSet object.
> > 	 * @param setName
> > 	 */
> > 	public BindingSet(String setName) {
> > 		handle = gtk_binding_set_new(setName);
> > 	}
> > 	
> > 	static public BindingSet findBindingSet(String setName) {
> > 		return new BindingSet(gtk_binding_set_find(setName));
> > 	}
> > 	
> > 	public boolean activateBindings(int keyval, ModifierType modifier) {
> >         return gtk_bindings_activate(handle, keyval, modifier.getValue());
> > 	}
> > 	
> > 	public boolean activateBindingSet(int keyval, ModifierType modifier) {
> > 		return gtk_binding_set_activate(handle, keyval, modifier.getValue(), handle);
> > 	}
> > 	
> > 	public void clearEntry(int keyval, ModifierType modifier) {
> > 		gtk_binding_entry_clear(handle, keyval, modifier.getValue());
> > 	}
> > 	
> > 	public void addPath(PathType pathType, String pathPattern, PathPriorityType priority) {
> > 		gtk_binding_set_add_path(handle, pathType.getValue(), pathPattern, priority.getValue());
> > 	}
> > 	
> > 	
> > 	/****************************************
> > 	 * BEGINNING OF JNI CODE
> > 	 ****************************************/
> > 	native static final protected int gtk_binding_set_new(String setName);
> > 	native static final protected int gtk_binding_set_find(String setName);
> > 	native static final protected boolean gtk_bindings_activate(int object, int keyval, int modifier);
> > 	native static final protected boolean gtk_binding_set_activate(int bindingSet, int keyval, int modifier, int object);
> > 	native static final protected void gtk_binding_entry_clear(int bindingSet, int keyval, int modifier);
> > 	native static final protected void gtk_binding_set_add_path(int bindingSet, int pathType, String pathPattern, int priority);
> > 	/****************************************
> > 	 * END OF JNI CODE
> > 	 ****************************************/
> > }
This looks fine to me.  
> 
> -Jeff

I've commited it, but consider the activateBindingSet and the
activateBindings methods: where it asks for an int (named object) I've
passed the handle. I doubt this could work.

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

Re: [java-gnome-hackers] org.gnu.gtk.Action

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

Hi, 
  Documenting these new classes would be *really* useful - especially
for those of us who have never used the c versions.

On Sat, Dec 27, 2003 at 01:12:54AM +0100, Luca De Rugeriis wrote:
> I'm unsure about the constructor; Should it be: 
> 	public Action(int handle) {
> 		super(handle);

This should probably not be public. Methods which take an int handle
should be used only internally by java-gnome - our users should not need
to know about handles and other c things (e.g. memory management). In
some cases, they have to be public (where they are constructed by other
packages, e.g. pango objects being constructed internally from within
gtk package. If this is the case, the javadoc must say that this method
should only be used internally by java-gnome. 

This is probably a case of documentation... but where would you get an
Action object from? 

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

Re: [java-gnome-hackers] BindingSet (was: Update)

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

Il sab, 2003-12-27 alle 15:46, Luca De Rugeriis ha scritto:
> Il sab, 2003-12-27 alle 13:21, Jeffrey Morgan ha scritto:
> > On Sat, 2003-12-27 at 06:41, Mark Howard wrote:
> > > On Sat, Dec 27, 2003 at 04:59:07AM +0100, Luca De Rugeriis wrote:
> > > > 	public BindingSet(int handle) {
> > > > 		this.handle = handle;
> > > 
> > > Does this really need to be public? It should only be used internally by java-gnome.
> > 
> > I agree with you Mark that we should limit access as much as possible.
> > The only problem I see is with limiting access to this method is when
> > another class needs to create a BindingSet object from a handle returned
> > from a native call.  In that case the Constructor would need to be
> > public.  We can start with this method as private and change it if
> > we need further access.
I'm agree, information hiding is essential.
I have leave the construtor public cause I've seen other classess do so,
but I was asking why there is the need fot it to be public.
This e-mail clears the thing, thanks.

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

Re: [java-gnome-hackers] BindingSet (was: Update)

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

Il sab, 2003-12-27 alle 13:21, Jeffrey Morgan ha scritto:
> On Sat, 2003-12-27 at 06:41, Mark Howard wrote:
> > On Sat, Dec 27, 2003 at 04:59:07AM +0100, Luca De Rugeriis wrote:
> > > 	public BindingSet(int handle) {
> > > 		this.handle = handle;
> > 
> > Does this really need to be public? It should only be used internally by java-gnome.
> 
> I agree with you Mark that we should limit access as much as possible.
> The only problem I see is with limiting access to this method is when
> another class needs to create a BindingSet object from a handle returned
> from a native call.  In that case the Constructor would need to be
> public.  We can start with this method as private and change it if
> we need further access.
I'll commit the changes asap.

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

Re: [java-gnome-hackers] BindingSet (was: Update)

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

On Sat, 2003-12-27 at 06:41, Mark Howard wrote:
> On Sat, Dec 27, 2003 at 04:59:07AM +0100, Luca De Rugeriis wrote:
> > 	public BindingSet(int handle) {
> > 		this.handle = handle;
> 
> Does this really need to be public? It should only be used internally by java-gnome.

I agree with you Mark that we should limit access as much as possible.
The only problem I see is with limiting access to this method is when
another class needs to create a BindingSet object from a handle returned
from a native call.  In that case the Constructor would need to be
public.  We can start with this method as private and change it if
we need further access.

-Jeff