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

Re: [Java-gnome-developer] Problems to install java-gnome-0.8

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

Although  this is not a help request list, I think you must end up with 
lib/gtk-0.8.0.jar, lib/gnome-0.8.0.jar, lib/glade-0.8.0.jar. The
Makefile was amended few days ago by me and by Dan Pilone, as well as
the spec file. They work perfectly for me now, and it's strange you have
had such results. I don't know if you have rpm on Gentoo, however if you
have it, you better use the spec file.
Luca.

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

[Java-gnome-developer] Re: TextView enhancements

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

Hi,
I'm a java/java-gnome/gtk newbie, I've managed to port gnome-postal to
java-gnome-0.8/gtk2 with success. I have done that in the process of
learning java-gnome but the app is not much useful because of the many
callbacks left unimplemented. Integrating all of the original Postal
functions is beyond my scope, because basically I haven't written any
app in my life and Postal is quite a big project. However I can submit
the patches for this if you are interested.

Mark Howard wrote:
>Is anybody
>on the list interested in taking on one of these sections? Any
>Java-Gnome newbies? If you do, I promise to review any patches sent to
>this list, offer help where I can and fix bugs when I get time. 

Well, as I said, I am a newbie and maybe I can help on this while
learning. Which are exactly the sections that need to be worked on?
Are you talking about the TextBuffer example exclusively?

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

[Java-gnome-developer] Problems to install java-gnome-0.8

[Darko O. <dob...@gm...>]

Hi all,

I have massive problems trying to get java-gnome installed. First I =20
tried the 0.8-package, which failed because of some make-targets, which =20
obviously are fixed in CVS. So I continued there. :)

Of course there arised a new problem: it claims my gcj is not 3.0.0 or =20
higher, although the 0.8-configure detected it correctly, and it indeed =20
is 3.3.1. First line output of `gcj --version` is:

darko@giant java-gnome $ gcj --version
gcj (GCC) 3.3.1 20030916 (Gentoo Linux 3.3.1-r4, propolice)

Tried to move on without gcj-compile now, ran into the next problem =20
when coming to "make install":

root@giant java-gnome # make install
src/tools/mkinstalldirs /usr/local/lib /usr/local/share/java-gnome/ /=20
usr/local/share/doc/java-gnome-0.8.0 /usr/local/share/java-gnome/test /=20
usr/local/share/java-gnome/examples/tutorial /usr/local/share/java-=20
gnome/examples/gtk /usr/local/share/java-gnome/examples/gnome /usr/=20
local/share/java-gnome/examples/glade /usr/local/share/java-gnome/=20
examples/glade-gnome
mkdir /usr/local/share/java-gnome
mkdir /usr/local/share/doc/java-gnome-0.8.0
mkdir /usr/local/share/java-gnome/test
mkdir /usr/local/share/java-gnome/examples
mkdir /usr/local/share/java-gnome/examples/tutorial
mkdir /usr/local/share/java-gnome/examples/gtk
mkdir /usr/local/share/java-gnome/examples/gnome
mkdir /usr/local/share/java-gnome/examples/glade
mkdir /usr/local/share/java-gnome/examples/glade-gnome
/bin/install -c -m644 lib/libGTKJava.so.0.8.0 /usr/local/lib
/bin/install -c -m644 lib/libGNOMEJava.so.0.8.0 /usr/local/lib
/bin/install -c -m644 lib/gtk-0.8.0.jar /usr/local/share/java-gnome
/bin/install: Aufruf von stat f=FCr ,,lib/gtk-0.8.0.jar" nicht m=F6glich: =
=20
Datei oder Verzeichnis nicht gefunden
make: *** [gnome_install] Fehler 1

There's some german in it, saying that the jar-file doesn't exist. And =20
it really doesn't, although some jar-files do:

root@giant java-gnome # find -name '*.jar'
=2E/lib/glade.jar
=2E/src/gnome.jar
=2E/src/gtk.jar
=2E/apps/gnome-postal/lib/activation.jar
=2E/apps/gnome-postal/lib/pop3.jar
=2E/apps/gnome-postal/lib/mail.jar
=2E/test/junit.jar

That's pretty frustrating, as I don't have any idea what might cause =20
all this. Any hints are welcome.

bye,

Darko Obradovic

[Java-gnome-developer] [ java-gnome-Bugs-817005 ] glib.GStringArray does not work

[SourceForge.net <no...@so...>]

Bugs item #817005, was opened at 2003-10-03 04:12
Message generated for change (Settings changed) made by kuzman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=817005&group_id=1522

Category: other
Group: defect
Status: Open
Resolution: None
Priority: 7
Submitted By: Mark Howard (howama)
>Assigned to: Jeffrey S. Morgan (kuzman)
Summary: glib.GStringArray does not work

Initial Comment:

Look at gnome About boxes for an example. It doesn't
crash any more, but it still isn't doing what it should.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=817005&group_id=1522

[Java-gnome-developer] [ java-gnome-Bugs-823976 ] CustomEvents initialization

[SourceForge.net <no...@so...>]

Bugs item #823976, was opened at 2003-10-15 09:52
Message generated for change (Comment added) made by howama
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=823976&group_id=1522

Category: other
Group: defect
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonas Berlin (xkr47)
Assigned to: Nobody/Anonymous (nobody)
Summary: CustomEvents initialization

Initial Comment:
If the CustomWidgets event handler is not activated before Gtk.
main(), then it gets activated only after some other event arrives.

Thus, if your program starts adding CustomEvents to the queue 
before clicking even one button, then the events aren't handled until 
some other event gets processed.

The quick-hack solution is to put

CustomEvents.addEvent(new Runnable() { public void run() { }});

before Gtk.main() but a better solution would be to either

a) always initialize the CustomEvents component before Gtk.main(), 
automatically, without user internvention, or

b) require the user to call some method, for example CustomEvents.
initialize() before Gtk.main().

Case a) could probably be implemented as a part of the java and/or 
native code of Gtk.main(). Or then maybe Gtk.init().

What do you think?


----------------------------------------------------------------------

>Comment By: Mark Howard (howama)
Date: 2003-10-15 15:18

Message:
Logged In: YES 
user_id=189107

Why would CustomEvents be added before gtk.main is called? 
I don't understand.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=823976&group_id=1522

[Java-gnome-developer] [ java-gnome-Bugs-823976 ] CustomEvents initialization

[SourceForge.net <no...@so...>]

Bugs item #823976, was opened at 2003-10-15 11:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=823976&group_id=1522

Category: other
Group: defect
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonas Berlin (xkr47)
Assigned to: Nobody/Anonymous (nobody)
Summary: CustomEvents initialization

Initial Comment:
If the CustomWidgets event handler is not activated before Gtk.
main(), then it gets activated only after some other event arrives.

Thus, if your program starts adding CustomEvents to the queue 
before clicking even one button, then the events aren't handled until 
some other event gets processed.

The quick-hack solution is to put

CustomEvents.addEvent(new Runnable() { public void run() { }});

before Gtk.main() but a better solution would be to either

a) always initialize the CustomEvents component before Gtk.main(), 
automatically, without user internvention, or

b) require the user to call some method, for example CustomEvents.
initialize() before Gtk.main().

Case a) could probably be implemented as a part of the java and/or 
native code of Gtk.main(). Or then maybe Gtk.init().

What do you think?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101522&aid=823976&group_id=1522

Re: [Java-gnome-developer] cvs and bug tracking..

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

On Tue, Oct 14, 2003 at 10:53:06PM +0300, Jonas Berlin wrote:
> It seems more and more likely that the anonymous cvs is one or a few days 
> behind the developer version.. A few times when you have said in a mail 
> "now committed to cvs", I have found nothing, and later when I updated 
> they were there, with check-in dates before your mail..

Sourceforge have been promising to improve cvs for months. Their first
improvement was to move anonymous cvs to a different server. This made
developer access much better, which is good, but makes anonymous access
a little out of date. I think they have plans to improve the situation
though.

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

[Java-gnome-developer] cvs and bug tracking..

[Jonas B. <jb...@ni...>]

On Tue, 14 Oct 2003 19:59:49 +0100, Mark Howard <mh...@ca...> wrote:

>> As it seems nobody is ever commenting on the bugs in the database, nor
>> applying the patches I send there, I post my patch here as well, in th=
e
>> hope it would get committed to cvs before it becomes obsolete =3D)
> I committed this one just a few minutes ago! Guess you were writing the
> email at the same time.

It seems more and more likely that the anonymous cvs is one or a few days=
=20
behind the developer version.. A few times when you have said in a mail=20
"now committed to cvs", I have found nothing, and later when I updated=20
they were there, with check-in dates before your mail..

> I've modified the sourceforge trackers so that they send emails to this
> list so this sort of thing shouldn't happen again in future.

Oh! Very nice! Hope it works.. Maybe I'll find a bug soon so I can test i=
t=20
out :D

- xkr47

Re: [Java-gnome-developer] Bug [ 819640 ] minor memory leak fix for GObject native code

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

On Tue, Oct 14, 2003 at 09:27:21PM +0300, Jonas Berlin wrote:
> As it seems nobody is ever commenting on the bugs in the database, nor 
> applying the patches I send there, I post my patch here as well, in the 
> hope it would get committed to cvs before it becomes obsolete =)
I committed this one just a few minutes ago! Guess you were writing the
email at the same time.

> As heard elsewhere, memory handling is not currently a top priority of 
> java-gnome, but I thought, why not nail some of them down, at least when 
> they are this trivial.
We welcome thoughts like these.  Thanks. 

I've modified the sourceforge trackers so that they send emails to this
list so this sort of thing shouldn't happen again in future. 

Jeff - some of the trackers were set to mail you on new submissions. sf
only allows a single email address entry, so you won't get them at that
account any more (although you're subscribed here so it doesn't matter). 

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

Re: [Java-gnome-developer] Bug [ 819631 ] LibGlade field removed -> runtime error

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

On Tue, Oct 14, 2003 at 09:08:04PM +0300, Jonas Berlin wrote:
> I post the patch here since there seems to be no activity in the "bugs" 
> database. Hope someone applies it sometimes =)

applied.

Sorry for the delay. 
sf bugs database is really bad; I don't like it. Does anyone know how to
subscribe to new items?

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

Re: [Java-gnome-developer] GTK_WIDGET_xxxx macro access

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

On Tue, Oct 14, 2003 at 08:53:22PM +0300, Jonas Berlin wrote:
> Did that, here is the patch:

Thanks. Applied to cvs.
I think the javadoc comments could be done better (what does sensitive
mean anyway? is what newbies might think), but that's a more general
java-gnome problem than just this patch.

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

[Java-gnome-developer] Bug [ 819640 ] minor memory leak fix for GObject native code

[Jonas B. <jb...@ni...>]

As it seems nobody is ever commenting on the bugs in the database, nor=20
applying the patches I send there, I post my patch here as well, in the=20
hope it would get committed to cvs before it becomes obsolete =3D)

--
=09
I spotted a minor memory leak - some strings allocated by g_malloc()
were never g_free():d.. The function was used in two places. In the
other place, there was actually code in place to do call g_free() but it
was never triggered.

http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031008-3-gobjec=
t-memleak.diff

--

As heard elsewhere, memory handling is not currently a top priority of=20
java-gnome, but I thought, why not nail some of them down, at least when=20
they are this trivial.

- xkr47

[Java-gnome-developer] Bug [ 819631 ] LibGlade field removed -> runtime error

[Jonas B. <jb...@ni...>]

I posted a bugreport regarding the following problem with the most recent=
=20
cvs:

Exception in thread "main" java.lang.NoSuchFieldError: gladeHandle
at org.gnu.glade.LibGlade.initIDs(Native Method)
at org.gnu.glade.LibGlade.<clinit>(LibGlade.java:216)

I post the patch here since there seems to be no activity in the "bugs"=20
database. Hope someone applies it sometimes =3D)

Here goes:
http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031014-5-LibGla=
de-gladeHandle.diff

- xkr47

Re: [Java-gnome-developer] GTK_WIDGET_xxxx macro access

[Jonas B. <jb...@ni...>]

On Wed, 8 Oct 2003 08:25:20 -0400, Jeffrey Morgan=20
<Jef...@Br...> wrote:

>> macros? For my current project, I'd need to run the
>> GTK_WIDGET_SENSITIVE(widget) macro to find out if the widget
>> is sensitive
>> or not. Of course I can keep the info somewhere until this gets fixed.
>
> I would suggest implementing this as a method on the widget class
> and making a native call to retrieve this value.  The problem with
> using a instance variable to hold this information is that sometimes
> your value could be out of sync with the native state if the state is
> changed internally.  Adding this method would be quite simple.

Did that, here is the patch:

http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031014-4-widget=
-getSensitive.diff

- xkr47

RE: [Java-gnome-developer] spec file

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

Feel free to apply as you wish.

> On Tue, 2003-10-14 at 09:22, Luca De Rugeriis wrote:
> > First I would like to thank you for continuing this project.
> > I've made a spec file that I want to share: it's somewhat Redhat
> > specific, however it's here.
> 
> Nice work.  Anyone mind if I apply this?  I had made changes 
> to the spec
> file to support the Eclipse plugin but these are more correct. -- Dan
> 

[Java-gnome-developer] Eclipse plugins....

[Dan P. <pi...@sl...>]

All,
  Since I'm taking forever to get the website up, here is the first
crack at the Eclipse plugins.  Sorry for the delay (seeing a valid spec
file go by spurred me on..)
  They will be available (with source and all) as soon as I can.  The
pages are being put together by someone beyond my control.  Anyway,
attached is a zip of the compiled version.  Simply unzip this into your
"eclipse" directory.  Note that this is built/tested against Eclipse
3.0M2 but I don't think I do anything that would cause problems with
earlier versions.
  Once you've unzipped it when you select "File-New" you'll see Gnome
Wizards that will create a new basic gnome app or glade app.  The only
requirement is having the full (JavaGlade too) JavaGnome bindings
installed.  You can run the newly generated app immediately by selecting
the project, choosing "Run As Java Application" and adding
-Djava.library.path=/usr/lib to the VM arguments section of the run
dialog.
  I think that's everything.  My next step is to add more options and
better customization to the wizard itself.  It took me a little while to
get everything working.  
  Comments are welcome!  Like I said, I'll have the source up soon,
hopefully today. -- Dan

Re: [Java-gnome-developer] spec file

[Dan P. <pi...@sl...>]

On Tue, 2003-10-14 at 09:22, Luca De Rugeriis wrote:
> First I would like to thank you for continuing this project.
> I've made a spec file that I want to share: it's somewhat Redhat
> specific, however it's here.

Nice work.  Anyone mind if I apply this?  I had made changes to the spec
file to support the Eclipse plugin but these are more correct. -- Dan

[Java-gnome-developer] spec file

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

First I would like to thank you for continuing this project.
I've made a spec file that I want to share: it's somewhat Redhat
specific, however it's here.
Luca
-- 
Luca De Rugeriis <pie...@li...>

[Java-gnome-developer] License question autoconf macros

[Christian B. <fla...@we...>]

Hi,

I'm currently developing a wrapper of a library for Java. I've long been
searching for nice autoconf macros for Java. Well yours are the best
I've seen until now.
I'd like to adapt them to my situation. The only problem I have right
now is a little license issue:
I have to use the MIT License for my project.
The standard autoconf macros are like yours licensed under GPL, but with
the addendum, that a configure file based on those macros doesn't have
to be licensed under GPL.
Could you please tell me if that addendum is also true for your macros,
or if I may use them under the terms of the MIT License.

Thanks in advance
Christian

-- 
North American Terror Organization
Bringing war to the world since the 1950s!

RE: [Java-gnome-developer] GTK_WIDGET_xxxx macro access

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

> Is there a way to access the data available through the 
> GTK_WIDGET_xxxx 
> macros? For my current project, I'd need to run the 
> GTK_WIDGET_SENSITIVE(widget) macro to find out if the widget 
> is sensitive 
> or not. Of course I can keep the info somewhere until this gets fixed.
> 
> The C interface provides the gtk_widget_set_sensitive() for 
> setting the 
> value, but for getting there's only the above macro (afaik).
> 
> The setSensitive() method is implemented in the Widget class, 
> so maybe we 
> could take a java-like approach and add a getSensitive() 
> method that then 
> somehow runs the macro (or something).

I would suggest implementing this as a method on the widget class
and making a native call to retrieve this value.  The problem with
using a instance variable to hold this information is that sometimes
your value could be out of sync with the native state if the state is
changed internally.  Adding this method would be quite simple.

-Jeff

RE: [Java-gnome-developer] OptionMenu events etc..

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

I would like to see us get some sort of testing framework in
place but I haven't had the time to implement this.  We do
us JUnit at my work and I think it is the right way to go.
Do you have any ideas on how this could be implemented?

> > Do you in general have plans to write some unit testing or 
> similar on the 
> > components? JUnit could be one way, but with java-gnome, 
> it's quite easy 
> > to pull together even the simplest test application, in 
> fact so easy that 
> > i find myself rather writing a gui for it than some text output =)
> See the tests directory in cvs. I think Jeff started work on 
> it. Again,
> priorities have been to work on implementing features and 
> fixing visible
> bugs rather than work on this, although I agree it is important.

Re: [Java-gnome-developer] OptionMenu events etc..

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

On Wed, Oct 08, 2003 at 12:43:34AM +0300, Jonas Berlin wrote:
> I do. =) And some test code also.. I put a textview test already there, 
> looks like a tricky one (unless my test is faulty somehow).. But I can 
> make the java process grow just as well by "just" creating 100000 (or some 
> insane number) labels and then letting the garbage collector pick them 
> up.. Even if I call Widget.destroy() on them, the native code seems to 
> keep memory references somewhere.. I haven't tested any other components 
> yet, or even looked at how the objects are handled in the native code part 
> of java-gnome..
I haven't looked in detail, but I think the problems are most likely
caused by us not clearing up strings after passing them to gtk, rather
than not destroying the widgets. Gtk/Glib should destroy them when they
are no longer used (unless there has been a g_object_ref call). There is
still probably work to do in this area. My main focus so far has been to
get things working, then work on improving them. Performance and memory
usage haven't been an issue in the large apps I've written so far, so I
was hoping there weren't any major problems.

> Generally I don't know how to handle data allocated by native code when 
> the object gets garbage collected.. is the only way to implement a native 
> void finalize() method that is then called when the object is garbage 
> collected, or is there a better way? I have heard implementing finalize() 
> methods in classes slows down execution, so hopefully there's some other 
> way to do it without the performance degradation..
We don't want to destroy native objects when java objects get GCd. Glib
will sort these out at the right time. It is common to create an object,
add it to a form and then remove all java references to it - the native
widget must still exist.

> Do you in general have plans to write some unit testing or similar on the 
> components? JUnit could be one way, but with java-gnome, it's quite easy 
> to pull together even the simplest test application, in fact so easy that 
> i find myself rather writing a gui for it than some text output =)
See the tests directory in cvs. I think Jeff started work on it. Again,
priorities have been to work on implementing features and fixing visible
bugs rather than work on this, although I agree it is important.

> Nice nice.. Your comment regarding putting an comment there (and maybe a 
> commented out method body for easier grepping).. I agree, that would have 
> been better.
I think one of the items in Effective Java (a useful book) is about
this.

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

Re: [Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

On Tue, 7 Oct 2003 17:27:04 +0100, Mark Howard <mh...@ca...> wrote:

> Looks good apart from one mistake:
> +	public boolean isOfType(OptionMenuEvent.Type type){
> +		return (type.getID() =3D=3D type.getID());
> +	}

Oh gosh.. I originally worked on the 0.8.0 source and then switched over=20
to making the patches compatible with cvs.. in 0.8.0 the code was=20
this.type.getID() =3D=3D type.getID() and in cvs, at first glance, it loo=
ked=20
like the "this" had just been removed (didn't really look into what it wa=
s=20
doing, even if it was that simple).. So I removed the "this" in front and=
=20
though "great, now it looks like the others", but then again, not.. Very=20
nice catch there, sorry that it slipped.. I'll try to be more careful in=20
the future.

> My quick search shows that the other classes look ok. If you copied thi=
s
> code, could you please check this.

I checked the other classes (while pondering on how that could have=20
slipped) and they seemed ok.. Some classes had slightly differing naming=20
convetions there (calling the method argument test instead of aType), but=
=20
otherwise the same.

> I've fixed and applied to cvs.

Cool =3D)

> Fell free to write more patches :)

I do. =3D) And some test code also.. I put a textview test already there,=
=20
looks like a tricky one (unless my test is faulty somehow).. But I can=20
make the java process grow just as well by "just" creating 100000 (or som=
e=20
insane number) labels and then letting the garbage collector pick them=20
up.. Even if I call Widget.destroy() on them, the native code seems to=20
keep memory references somewhere.. I haven't tested any other components=20
yet, or even looked at how the objects are handled in the native code par=
t=20
of java-gnome..

Generally I don't know how to handle data allocated by native code when=20
the object gets garbage collected.. is the only way to implement a native=
=20
void finalize() method that is then called when the object is garbage=20
collected, or is there a better way? I have heard implementing finalize()=
=20
methods in classes slows down execution, so hopefully there's some other=20
way to do it without the performance degradation..

Do you in general have plans to write some unit testing or similar on the=
=20
components? JUnit could be one way, but with java-gnome, it's quite easy=20
to pull together even the simplest test application, in fact so easy that=
=20
i find myself rather writing a gui for it than some text output =3D)

> (BTW: I also applied the previous patch; forget to say that in the repl=
y
> email).

Nice nice.. Your comment regarding putting an comment there (and maybe a=20
commented out method body for easier grepping).. I agree, that would have=
=20
been better.

- xkr47

Re: [Java-gnome-developer] OptionMenu events etc..

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

On Sun, Oct 05, 2003 at 01:14:07PM +0300, Jonas Berlin wrote:
>   http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031005-1-OptionMenuEvent.diff

Looks good apart from one mistake:
+	public boolean isOfType(OptionMenuEvent.Type type){
+		return (type.getID() == type.getID());
+	}

My quick search shows that the other classes look ok. If you copied this
code, could you please check this.

I've fixed and applied to cvs.
Fell free to write more patches :)

(BTW: I also applied the previous patch; forget to say that in the reply
email).

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

Re: [Java-gnome-developer] OptionMenu events etc..

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

On Sun, Oct 05, 2003 at 12:16:37PM +0300, Jonas Berlin wrote:
>   http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031005-2-initializeEvent-addEvents.diff

Thanks.
This looks good. I've tested on my large app and everything seems to
work fine. Did you go through every single widget? Or is there more
still to be done. Also, did you take a look at the gnome widgets?

> The sourceforge cvs was inoperational, or at least I could not log in to 
> in sourceforge yesterday evening.
Were you using anonymous cvs? The developer one where you have to login
requires special cvs privilidges. In any case, sourceforge is generally
rubbish at cvs; trying again a few minutes later often helps.

>  - some classes had addEvents() methods that only called 
> <superclass>.addEvents(), which after my modification (2.) became empty, 
> so I removed those methods (and unnecessary EventMap imports that became 
> unnecessary) altogether.
I'd have prefered to eave them with a comment saying they do anything.
This shows that you've actually thought about it, rather than it being
mistakenly missed out. Not important though. Leave things as they are
now.

>  - some classes didn't have an addEvents() method at all, instead they did 
> what addEvents() used to do directly in the static { ... } block. I 
> thought consistency is bliss, created new addEvents() methods and moved 
> the code there.
I can't remember exactly when add events was implemented. I think Tom
did it all when working on the glade support. Probably just missed a few
classes.

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