java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 131)
Brought to you by:
afcowie
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(102) |
Sep
(43) |
Oct
(32) |
Nov
(43) |
Dec
(51) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(6) |
Feb
(19) |
Mar
(39) |
Apr
(22) |
May
|
Jun
(11) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(73) |
2004 |
Jan
(88) |
Feb
(141) |
Mar
(116) |
Apr
(69) |
May
(199) |
Jun
(53) |
Jul
(90) |
Aug
(23) |
Sep
(11) |
Oct
(212) |
Nov
(57) |
Dec
(61) |
2005 |
Jan
(88) |
Feb
(17) |
Mar
(21) |
Apr
(50) |
May
(44) |
Jun
(33) |
Jul
(21) |
Aug
(37) |
Sep
(39) |
Oct
(43) |
Nov
(40) |
Dec
(15) |
2006 |
Jan
(21) |
Feb
(69) |
Mar
(23) |
Apr
(6) |
May
(29) |
Jun
(19) |
Jul
(17) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(9) |
Dec
(7) |
2007 |
Jan
(30) |
Feb
(39) |
Mar
(1) |
Apr
(12) |
May
(53) |
Jun
(30) |
Jul
(39) |
Aug
(75) |
Sep
(16) |
Oct
(13) |
Nov
(20) |
Dec
(5) |
2008 |
Jan
(8) |
Feb
(14) |
Mar
(33) |
Apr
(7) |
May
(22) |
Jun
(23) |
Jul
(17) |
Aug
(9) |
Sep
(9) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
2009 |
Jan
(20) |
Feb
(38) |
Mar
(9) |
Apr
(15) |
May
(30) |
Jun
(35) |
Jul
(22) |
Aug
(10) |
Sep
(7) |
Oct
(23) |
Nov
(6) |
Dec
(8) |
2010 |
Jan
(5) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(15) |
Sep
(14) |
Oct
(26) |
Nov
(11) |
Dec
(14) |
2011 |
Jan
(10) |
Feb
(8) |
Mar
(6) |
Apr
(7) |
May
(18) |
Jun
(17) |
Jul
(6) |
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(10) |
2012 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(5) |
Aug
(14) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Rubio Jr. <ser...@hi...> - 2002-08-13 16:37:34
|
I like it more. This will make easy to add future focus events, more swing like. Anyway it's just my silly opinion. El mar, 13-08-2002 a las 18:16, Philip A. Chapman escribi=F3: > Jeff, >=20 > Thanks for this reference implementation. >=20 > I do not belive the removeFocusListener will work because a > WeakReference was added into the Vector, but a listener is being > removed. I've checked in a few changes that should take care of this > issue. However, the code changes I've made *should* work as well. I > like the idea of using Vector rather than WeakHashMap as the Vector > should be thread-safe without extra work Perhaps we need a WeakVector > (subclass of Vector) so that the findFocusListener code does not have to > be implemented for every single listener Vector we use? >=20 > What do you think of creating a FocusEvent with a type property. That > way, the listener could implement a single method and tell what kind of > focus event it received by the type property of the FocusEvent. >=20 > interface FocusListener > { > public void focusEventFired(FocusEvent event); > } >=20 > class MyFocusListener > extends FocusListener > { > public void focusEventFired(FocusEvent event) > { > if (FocusEvent.getType() =3D=3D FocusEventType.GOT_FOCUS()) { > // Do Something >=20 > else if (FocusEvent.getType() =3D=3D FocusEventType.LOST_FOCUS()) { > // Do Something different >=20 > } // Else, I don't want to handle it. > } > } >=20 > For this example, it doesn't change much; maybe it even huts some.=20 > However, for a "class" of events which have a lot of different types, > this may be easier to work with than a lot of different method calls. >=20 > On Tue, 2002-08-13 at 10:07, Jeffrey Morgan wrote: > > I have just checked very basic code for event handling > > into cvs. If you check the gtk.Widget class you can > > see very simple handling for the focus events. This > > can serve the basis of our dicussion. > >=20 > > -Jeff > --=20 > Philip A. Chapman |
From: Philip A. C. <pc...@td...> - 2002-08-13 16:14:05
|
Jeff, Thanks for this reference implementation. I do not belive the removeFocusListener will work because a WeakReference was added into the Vector, but a listener is being removed. I've checked in a few changes that should take care of this issue. However, the code changes I've made *should* work as well. I like the idea of using Vector rather than WeakHashMap as the Vector should be thread-safe without extra work Perhaps we need a WeakVector (subclass of Vector) so that the findFocusListener code does not have to be implemented for every single listener Vector we use? What do you think of creating a FocusEvent with a type property. That way, the listener could implement a single method and tell what kind of focus event it received by the type property of the FocusEvent. interface FocusListener { public void focusEventFired(FocusEvent event); } class MyFocusListener extends FocusListener { public void focusEventFired(FocusEvent event) { if (FocusEvent.getType() =3D=3D FocusEventType.GOT_FOCUS()) { // Do Something else if (FocusEvent.getType() =3D=3D FocusEventType.LOST_FOCUS()) { // Do Something different } // Else, I don't want to handle it. } } For this example, it doesn't change much; maybe it even huts some.=20 However, for a "class" of events which have a lot of different types, this may be easier to work with than a lot of different method calls. On Tue, 2002-08-13 at 10:07, Jeffrey Morgan wrote: > I have just checked very basic code for event handling > into cvs. If you check the gtk.Widget class you can > see very simple handling for the focus events. This > can serve the basis of our dicussion. >=20 > -Jeff --=20 Philip A. Chapman |
From: Rubio Jr. <ser...@hi...> - 2002-08-13 15:29:48
|
Umm, I like it. Another thing, what about adding a setHandler method to GObject? Isn't it a good way of building a new empty object and asing it the native handler? Rubio Jr. El mar, 13-08-2002 a las 17:07, Jeffrey Morgan escribi=F3: > I have just checked very basic code for event handling > into cvs. If you check the gtk.Widget class you can > see very simple handling for the focus events. This > can serve the basis of our dicussion. >=20 > -Jeff |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-13 15:08:09
|
I have just checked very basic code for event handling into cvs. If you check the gtk.Widget class you can see very simple handling for the focus events. This can serve the basis of our dicussion. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-13 13:27:52
|
On Tue, 2002-08-13 at 07:29, Jeffrey Morgan wrote: > Sorry for taking so long replying to the list. I had a=20 > family emergency Friday night that has occupied all of=20 > my time until now. I think using a container of=20 > WeakReferences is a good idea.=20 I hope everything is OK now. Thanks for your vote of confidence on using WeakReferences. > I think we should try to model our events after the standard > java event model. We need to be careful with the events > we expose. For example, for GtkWidget there are over 50 > signals/events. This could easily create a very complex > implementation. My suggestion is to only expose the events > that a user of the bindings might be interested in. Also, > if there are related events combine the notification into > a single method passing an indicator to identify which event > has occurred. I agree. As you say, we could probably lump a lot of similar events into a single method for the listener interface. With this many events, it's probably not a good idea to create a parent event and subclass it for each individual type. We could probably get away with a type property in the event and an enumeration of what those types can be.=20 The downside is that the event model would get very "chatty" as the listener will be called many different times for many different events types when it only wants a particular type. May I suggest that each event have a type field whos value is a long.=20 The enumeration would be bitflags. When the listener registers, it indicates which specific event types it wants to listen to in the form of a long value. That way the notifier will only call the event for listeners which request it. Thanks, > To server as an example of this I hope to complete gtk.Widget > today. >=20 > -Jeff --=20 Philip A. Chapman |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-13 12:30:06
|
Sorry for taking so long replying to the list. I had a family emergency Friday night that has occupied all of my time until now. I think using a container of WeakReferences is a good idea. I think we should try to model our events after the standard java event model. We need to be careful with the events we expose. For example, for GtkWidget there are over 50 signals/events. This could easily create a very complex implementation. My suggestion is to only expose the events that a user of the bindings might be interested in. Also, if there are related events combine the notification into a single method passing an indicator to identify which event has occurred. To server as an example of this I hope to complete gtk.Widget today. -Jeff > Shesh, All that typing, and I didn't attach the file.... > > I haven't compiled or run this code. I hacked it from another project > I'm working on where I use weak references for listeners. I > just wanted > to give you something to look at. > > On Fri, 2002-08-09 at 13:49, Philip A. Chapman wrote: > > Everyone, > > > > As we are working on the new API for java-gnome, we should > think about > > how events will be treated. Should we use the > event/listener model used > > by swing and so familiar to most Java developers? The > obvious reason to > > use it is simply because it is so familiar to Java developers. The > > down-side is that (a) it can be slow if you have a lot of > listeners or a > > lot of different levels though which events must pass and > (b) developers > > do not always unregister listeners when its usefullness has expired; > > causing memory leaks. > > > > The problem with memory leaks can be solved for the most > part using weak > > references. I'm attaching an example from one of my other > projects. > > Because this example runs in a thread and WeakHashMap is not > > syncronized, garbage collected listeners' WeakReferences are not > > removed. This is not a perfect example. I'm trading a small memory > > leak for a potential larger one. There are other methods. We could > > wrap the WeakHashMap and make is serializable. We could use also do > > some things with the ReferenceQueue as well. > > > > Anyway, just a few thoughts. A good reference is > > > > http://www.javaworld.com/javatips/jw-javatip79_p.html > > > > > > Thanks, > > -- > > Philip A. Chapman > -- > Philip A. Chapman > |
From: Philip A. C. <pc...@td...> - 2002-08-12 21:22:53
|
For the archives: -----Forwarded Message----- > From: Jeffrey Morgan <ku...@zo...> > To: Philip A. Chapman <pc...@td...> > Subject: Re: [Java-gnome-hackers] Quick question on the generator's capab= ilities > Date: 12 Aug 2002 03:19:29 -0400 >=20 > The correct definition for gnome_url_show should be: >=20 > (define-func gnome_url_show > bool > ((string url) > (GError* error))) >=20 > Using this approach you will be able to retrieve the > value from the GError. As you state below, you will need > to parse the value of GError. Perhaps I can think of a > way to enhance GError to make this simpler. >=20 > -Jeff >=20 > On Sat, 2002-08-10 at 09:46, Philip A. Chapman wrote: > > Jeffrey (or anyone else who knows), > >=20 > > Can the generator deal with pointers to pointers? I'm looking at the > > gnome2.defs function define line for gnome_url_show. It doesn't appear > > as though it can. This is slightly problematic in that a java program > > calling this function will need to parse the value of GError to > > determine why the function call didn't work. > >=20 > > Thanks, > > --=20 > > Philip A. Chapman >=20 >=20 --=20 Philip A. Chapman |
From: Philip A. C. <pc...@td...> - 2002-08-12 21:22:13
|
For the lists's archives: -----Forwarded Message----- > From: Jeffrey Morgan <ku...@zo...> > To: Philip A. Chapman <pc...@td...> > Subject: Re: [Java-gnome-hackers] Gnome2.defs > Date: 12 Aug 2002 03:22:17 -0400 >=20 > On Sat, 2002-08-10 at 11:40, Philip A. Chapman wrote: > > Everyone, > >=20 > > Jeffrey, do we have an "official" understanding on what to do when > > gdk/gtk/gnome provides the same non-gui functionality which is provided > > by standard Java APIs? Often, we may need to provide the gdk/gtk/gnome > > method because gui code depend on it, but what about stuff like > > gnome_util_user_home? I realize, or course, that gnome is an > > environment and more than gui. I just need to know where we draw the > > line. > >=20 >=20 > My view is that if a capability is already provided by the Java class > library we shouldn't provide that capability in java-gnome. I am sure > there are exceptions to this but I can't think of any at this time. >=20 > -Jeff >=20 --=20 Philip A. Chapman |
From: Rubio Jr. <ser...@hi...> - 2002-08-10 18:55:24
|
Hi! I keep on playing with the bindings. One question: When I have a method that returns an integer that is suposed to be the Object's returned handle, is it correct to build a new empty object, asign it the handle returned by the method and then return this brand new object? see what I mean: public class Drawable extends GObject{ ..... ... public Colormap getColormap(){ ColorMap cmap=new Colormap(); cmap.handle=Drawable.gdk_get_colormap(handle); return cmap; } native static final protected int gdk_drawable_get_colormap (int drawable); ..... ... } thanks. Rubio Jr. |
From: Philip A. C. <pc...@td...> - 2002-08-10 15:44:18
|
Everyone, I have completed my first pass of gnome2.defs. Everything compiles.=20 Later today, I will start working with the java classes to see what works and what doesn't. While looking through the gnome2.defs, I saw that we have the gnome_util_user_home function defined. This seems redundant to me since Java already provides a way to determine the user's home directory through the use of java.lang.System.getProperty("user.home"). Thoughts anyone? Jeffrey, do we have an "official" understanding on what to do when gdk/gtk/gnome provides the same non-gui functionality which is provided by standard Java APIs? Often, we may need to provide the gdk/gtk/gnome method because gui code depend on it, but what about stuff like gnome_util_user_home? I realize, or course, that gnome is an environment and more than gui. I just need to know where we draw the line. Thanks, --=20 Philip A. Chapman |
From: Philip A. C. <pc...@td...> - 2002-08-10 13:49:20
|
Jeffrey (or anyone else who knows), Can the generator deal with pointers to pointers? I'm looking at the gnome2.defs function define line for gnome_url_show. It doesn't appear as though it can. This is slightly problematic in that a java program calling this function will need to parse the value of GError to determine why the function call didn't work. Thanks, --=20 Philip A. Chapman |
From: Philip A. C. <pc...@td...> - 2002-08-09 19:28:38
|
Shesh, All that typing, and I didn't attach the file.... I haven't compiled or run this code. I hacked it from another project I'm working on where I use weak references for listeners. I just wanted to give you something to look at. On Fri, 2002-08-09 at 13:49, Philip A. Chapman wrote: > Everyone, > > As we are working on the new API for java-gnome, we should think about > how events will be treated. Should we use the event/listener model used > by swing and so familiar to most Java developers? The obvious reason to > use it is simply because it is so familiar to Java developers. The > down-side is that (a) it can be slow if you have a lot of listeners or a > lot of different levels though which events must pass and (b) developers > do not always unregister listeners when its usefullness has expired; > causing memory leaks. > > The problem with memory leaks can be solved for the most part using weak > references. I'm attaching an example from one of my other projects. > Because this example runs in a thread and WeakHashMap is not > syncronized, garbage collected listeners' WeakReferences are not > removed. This is not a perfect example. I'm trading a small memory > leak for a potential larger one. There are other methods. We could > wrap the WeakHashMap and make is serializable. We could use also do > some things with the ReferenceQueue as well. > > Anyway, just a few thoughts. A good reference is > > http://www.javaworld.com/javatips/jw-javatip79_p.html > > > Thanks, > -- > Philip A. Chapman -- Philip A. Chapman |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-09 19:14:35
|
Good news. You can now build the bindings and run the examples/gtk/base example and see a GTK window. I am about to go drink a few beers with a couple friends. I will be online this evening and plan to respond to your emails. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-09 18:47:45
|
Everyone, As we are working on the new API for java-gnome, we should think about how events will be treated. Should we use the event/listener model used by swing and so familiar to most Java developers? The obvious reason to use it is simply because it is so familiar to Java developers. The down-side is that (a) it can be slow if you have a lot of listeners or a lot of different levels though which events must pass and (b) developers do not always unregister listeners when its usefullness has expired; causing memory leaks. The problem with memory leaks can be solved for the most part using weak references. I'm attaching an example from one of my other projects.=20 Because this example runs in a thread and WeakHashMap is not syncronized, garbage collected listeners' WeakReferences are not removed. This is not a perfect example. I'm trading a small memory leak for a potential larger one. There are other methods. We could wrap the WeakHashMap and make is serializable. We could use also do some things with the ReferenceQueue as well. Anyway, just a few thoughts. A good reference is=20 http://www.javaworld.com/javatips/jw-javatip79_p.html Thanks, --=20 Philip A. Chapman |
From: Rubio Jr. <ser...@hi...> - 2002-08-09 17:32:12
|
Ups! sorry this is the correct class. |
From: Rubio Jr. <ser...@hi...> - 2002-08-09 17:27:55
|
Hi folks. I was impatient, so I started to write something. I opened the shortest class I found trying to get the idea. The class is attached to the mail. Is that the way that I must follow? Just one more thing. If you think that I am wasting your time and I have to wait till you write the paper, just let me know. Thanks! |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-09 13:45:33
|
> First of all,this is my first message to the list, so hi everyone. > My name is Sergio Rubio and I am a computer engineer student > from Spain. > These project, makes me dream and it lets me play with my > favorite toys > nowadays, java and linux programming, so thanks guys! Welcome to the team. > I would like to take the UML part, so if everyone agree I > would like to > start working on it too. Feel free to take the UML part. I started to create the diagram in poseidon. It is located in the docs/object_model directory. If you wish to use another tool feel free. I just want to make sure that the tool used is free. -Jeff |
From: Rubio Jr. <ser...@hi...> - 2002-08-09 13:03:48
|
First of all,this is my first message to the list, so hi everyone. My name is Sergio Rubio and I am a computer engineer student from Spain. These project, makes me dream and it lets me play with my favorite toys nowadays, java and linux programming, so thanks guys! I would like to take the UML part, so if everyone agree I would like to start working on it too. see you guys! |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-09 12:41:57
|
The project will compile cleanly (although I still do not have "make clean" updated). In order to build the project you will need ant. If you don't already have it installed you can get it here: http://jakarta.apache.org/builds/jakarta-ant/release/v1.5/bin/ You just need to put the <install-dir>/bin directory in you path. I have added a couple of methods to Gtk.java, Widget.java and Window.java in order to get an example working. These classes are far from complete. I just wanted to get something working since there has been so many changes. I updated the examples/gtk/base example. The bad news is that I am getting an error reported from the natives that is causing a crash. Hopefully I will be able to find this problem and fix it today. Once I get this working my plans are to complete the three classes mentioned above. I then hope to write this paper I keep talking about and working with each of you to help you get fully productive. Below I also list a couple of TODOs that I would like to incorporate into the project at some time in the near future. If either of you want to take one of these TODOs please feel free. TODOs: 1) Implement a testing framework. At my work we have implemented a test-first approach to our software development using the JUnit automated testing tool. We have seen remarkable improvement in the quality of our software since we incorporated this approach. I also have worked quite a bit on the SWT project and they have a similar approach using JUnit. If either of you have experience with this tool and want to take this task please go ahead. Otherwise I will probably do this next week. 2) Maintain UML diagrams. Many developers like to see diagrams as it helps with their understanding. I have a beginning of these diagrams in cvs. I would like to find somebody that has a passion for UML that wishes to take this task. I would envision a page (or possibly several pages) on the website that would have images of these models. One other thing I want to do is find somebody to take over the maintenance of the website. I have done a very poor job at this and don't have the time to make it any better. I will probably post out to the developers list later today asking for help with the website and UML diagrams. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-09 03:24:43
|
I did some more work on gnome2.defs tonight. Most of the defs I checked tonight did not need changes. I'm a little over two-thirds of the way through it now. I would go at it a little longer, but my eyes are getting blurry at this point. :-) --=20 Philip A. Chapman |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-08 18:11:06
|
That was fast. > -----Original Message----- > From: Philip A. Chapman [mailto:pc...@td...] > Sent: Thursday, August 08, 2002 2:06 PM > To: java gnome hackers > Subject: [Java-gnome-hackers] Mailing list is going > > > Welcome everyone to java-gnome-hackers! > -- > Philip A. Chapman > |
From: Philip A. C. <pc...@td...> - 2002-08-08 18:03:33
|
Welcome everyone to java-gnome-hackers! --=20 Philip A. Chapman |