Thread: [java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk/src/java/org/gnu/gtk BindingSet.j
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Mark H. <mh...@ca...> - 2003-12-30 14:10:24
|
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...
|
|
From: Luca De R. <pie...@li...> - 2003-12-30 21:55:42
|
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...>
|
|
From: Mark H. <mh...@ca...> - 2004-01-03 19:01:21
|
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...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X