java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 130)
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-16 19:22:04
|
fuck! I know that my English is really bad so if at any time you don't understand my questions please don't hesitate to mail me and I will try to explain better or kill my teacher :). Thanks and sorry again. |
From: Rubio Jr. <ser...@hi...> - 2002-08-16 19:06:40
|
Hi guys! I'm working on the GdkColor class now. what would happen if a new java-gnome developer looks through the code and finds something like this? (In the Color class) public bolean equals(Color c){ ... } Which class will the newbie should use?, java.awt.Color or org.gnu.gdk.Color? see what I mean? I think that the class names without the Gdk,... prefix can make the code a bit complex. I want to hear you opinions. Thanks guys. |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-16 18:44:08
|
That sounds fine to me. -Jeff > Hi! > > I've seen all the work in the cvs, great. > > What do you think about releasing all the gdk events in a > org.gnu.gdk.event package? > > Thanks. > > > Rubio Jr. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > |
From: Rubio Jr. <ser...@hi...> - 2002-08-16 17:44:19
|
Hi! I've seen all the work in the cvs, great. What do you think about releasing all the gdk events in a org.gnu.gdk.event package? Thanks. Rubio Jr. |
From: Mark H. <mh...@ti...> - 2002-08-16 15:02:48
|
I have added a constructor to GObject with the handle as it's parameter. This was taken from Widget.=20 It is needed for pango.AttrList Label.getAttributes; and probably a few other methods too. - Would it be possible to rename the Statusbar Widget to StatusBar? This will probably require an exception to be added to the code which generates the java file.=20 - On Fri, 2002-08-16 at 13:22, Jeffrey Morgan wrote: > Another possibility might be to enhance the StockName object > that exists in the gtk package. It already contains a static > member for each of the #defines in gtkstock.h. You could add > a constructor that will take a parameter that is one if its'=20 > static members and assign it to a value. Then you could create=20 > a constructor for the Button widget that takes a StockName object. > We could also reuse the StockName object for all methods that > take a string that represents a stock id. I have done this. --=20 +----------------------------------------------+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.com tildemh.com mh@ | +----------------------------------------------+ |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-16 13:47:30
|
GSpawnError is in cvs now. > > Jeff & Mark, > > At some point, I will need the GSpawnError enumeration defined so that > org.gnu.gnome.Url can report appropriate errors from the > .show method. > This isn't a top priority item. > > Thanks, > -- > Philip A. Chapman > |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-16 12:22:45
|
> I will also work on example apps using these widgets. Is > there any plan > of what example apps should be produced? Do we just follow > the previous > versions, or write whatever would be useful. IMHO, it would be a good > idea to create a java clone of the c gtk-demo program. I believe this > demonstrates all of the gtk widgets with a useful interface which also > displays a description and source for each. If this is done, the many > smaller example apps may not be required (of course, there > would have to > be some for gnome, etc.) I think it would be a good idea to present this example. I do not thing we should consider this as a replacement for the small examples. gtk-demo (like test-gtk before it) is a large example and for a beginner it could be overwhelming. I think small examples that demonstrate one widget or a set of related widgets are very useful for somebody trying to learn the API. > Issues > ------ > ** Button Constructors: > There are four possible constructors for button: > - no arguments > - a label > - a label containing Mnemonic characters (keyboard accelerators) > - a stock item ID (string) > I have been having trouble deciding how to best implement this. > Currently, my best idea has been to have > Button() > Button(String caption) > Button(String caption, boolean hasMnemonic) > Stockbutton(String stockID) > This would require creating a StockButton Class, which is the same as > the Button class except that it uses a different constructor. > The other methods in button allow the 'type' of button to be changed, > e.g. make a stock button into a normal button. > > Are there any other ideas for this? or should I implement the above > suggestion Another possibility might be to enhance the StockName object that exists in the gtk package. It already contains a static member for each of the #defines in gtkstock.h. You could add a constructor that will take a parameter that is one if its' static members and assign it to a value. Then you could create a constructor for the Button widget that takes a StockName object. We could also reuse the StockName object for all methods that take a string that represents a stock id. > ** Naming convention > I have been trying to make the names more consistent (e.g. > using column > all the time instead of a mixture of column and col) > The Gtk Button has two very strangly named methods - get/set > UseUnderline. From the gtk reference, it seems that these > should really > be called get/set useMnemonic. I will change these unless > there are any > objections. There is no need for the public interface to emulate the native methods. Our goal is to make a higher-level OO class library that should be easier to use than the native C libraries. Feel free to define method names and parameter lists that simplify access to the native peers. Also, there are many methods in the native libs that were not intended for public use. Often you will find this documented in the docs. We should not provide access to these methods. Finally, there are many methods that are either redundant or are so obscure that they will probably never be used if we make them available. Feel free to excluded these types of methods as well. Use your judgment to make a public interface that is clear, concise, and easy to use. > > ** get_type > These native methods seem to be present in most classes. What > are their > purpose? The get_type methods and the GType object are the glib method for runtime identification of objects and types. Java already provides this ability and I am not completely sure we need to implement these methods at this time. Hopefully this will become clearer as we move forward. For the time being there is no need to implement a method to access type information. > ** Enum > for many of the enums, e.g.ReliefStyle, the methods and, or, xor, etc. > don't seem to have any use. Also, the test method would, > IMHO, be better > named equals. Enums are frequently bitwise combined in the native libs. For example, the AttachOptions parameters for the attach method of Table can provide several options. It is quit common to combine both the EXPAND and FILL options. For this you need the 'or' method. The equals method doesn't work simply because you can combine several of the enum values. If the AttachOptions enum has both EXPAND and FILL and you call equals on FILL what should it return? > ** Box > I am confused about how the query child packing should work > native static final protected void > gtk_box_query_child_packing (int box, > int child, boolean[] > expand, boolean[] fill, int [] padding, int [] packType); > native static final protected void gtk_box_set_child_packing (int box, > int child, boolean > expand, boolean fill, int padding, int packType); > Could someone with more experience of gtk please tell me why the > parameters are all arrays? (what do they return?) In java it is not possible to pass primitives as references. If there is a native method gtk_widget_get_pointer(int *x, int *y) there is no way to wrap this passing ints. Arrays are always passed by reference. The correct way to wrap the get_pointer method is to do the following: static protected gtk_widget_get_pointer(int handle, int [] width, int [] height); public Point getPointer() { int [] x = new int[1]; int [] y = new int[1]; gtk_widget_get_pointer(handle, x, y); return new Point(x[0], y[0]); } I would not provide a public interface to the gtk_box_query_child_packing method. The purpose of this method is to return the packing values that were used when a widget was added to the box. I have worked with java for 5 years and have never had to query a layout manager to determine how a widget was packed after the fact. > **Documentation > How much javadoc documentation should we provide? As an > example, in the > Label widget, I copied most of the gtk documentation to the > source file. > This may seem a little excessive; however if the user is expected to > look only at the java-gnome api docs, they may want such a level of > detail. There is no such thing as too much documentation. There is only too little documentation. What we are build is intended for other developers to use. It is only useful if developers can understand how to use it. -Jeff |
From: Mark H. <mh...@ti...> - 2002-08-16 11:09:47
|
hi, I've been looking at the Enums again (e.g. ButtonBoxStyle).=20 They are now making much more sense :) I still don't see the point of the boolean methods, however. Also, I think the integers should be set as private (or possibly not used at all). They look confusing in the documentation (especially since the 'beginning of generated code' is interpreted as a javadoc comment.) How should we go about documenting the Enums? Is it enough to list everything in the class header (in a <dl>), or does something need to be done so that we can add comments to each of the static final instantiations? --=20 +----------------------------------------------+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.com tildemh.com mh@ | +----------------------------------------------+ |
From: Mark H. <mh...@ti...> - 2002-08-16 09:38:52
|
Hello everyone!=20 Sorry for not responding sooner - I had to go away for the day yesterday. =20 So far, I have been working on the following gtk classes:=20 Box=20 VBox=20 HBox=20 Table=20 Button=20 ButtonBox=20 VButtonBox=20 HButtonBox=20 Label (just started) Added a build-doc target to the build.xml file=20 I guess I should also work on all subclasses of the above:=20 Combo, Statusbar, ColorSelection, FontSelection, GammaCurve OptionMenu, ToggleButton, CheckButton, RadioButton I will also work on example apps using these widgets. Is there any plan of what example apps should be produced? Do we just follow the previous versions, or write whatever would be useful. IMHO, it would be a good idea to create a java clone of the c gtk-demo program. I believe this demonstrates all of the gtk widgets with a useful interface which also displays a description and source for each. If this is done, the many smaller example apps may not be required (of course, there would have to be some for gnome, etc.) Issues=20 ------ ** Button Constructors: There are four possible constructors for button: - no arguments - a label - a label containing Mnemonic characters (keyboard accelerators) - a stock item ID (string) I have been having trouble deciding how to best implement this. Currently, my best idea has been to have Button() Button(String caption) Button(String caption, boolean hasMnemonic) Stockbutton(String stockID) This would require creating a StockButton Class, which is the same as the Button class except that it uses a different constructor.=20 The other methods in button allow the 'type' of button to be changed, e.g. make a stock button into a normal button. Are there any other ideas for this? or should I implement the above suggestion ** Naming convention I have been trying to make the names more consistent (e.g. using column all the time instead of a mixture of column and col) The Gtk Button has two very strangly named methods - get/set UseUnderline. From the gtk reference, it seems that these should really be called get/set useMnemonic. I will change these unless there are any objections.=20 ** get_type=20 These native methods seem to be present in most classes. What are their purpose? ** Enum=20 for many of the enums, e.g.ReliefStyle, the methods and, or, xor, etc. don't seem to have any use. Also, the test method would, IMHO, be better named equals. ** Box=20 I am confused about how the query child packing should work native static final protected void gtk_box_query_child_packing (int box, int child, boolean[]=20 expand, boolean[] fill, int [] padding, int [] packType); native static final protected void gtk_box_set_child_packing (int box, int child, boolean=20 expand, boolean fill, int padding, int packType); Could someone with more experience of gtk please tell me why the parameters are all arrays? (what do they return?) **Documentation=20 How much javadoc documentation should we provide? As an example, in the Label widget, I copied most of the gtk documentation to the source file. This may seem a little excessive; however if the user is expected to look only at the java-gnome api docs, they may want such a level of detail.=20 --=20 +----------------------------------------------+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.com tildemh.com mh@ | +----------------------------------------------+ --=20 +----------------------------------------------+ | Mark Howard cam.ac.uk mh344@ | | http://www.tildemh.com tildemh.com mh@ | +----------------------------------------------+ |
From: Philip A. C. <pc...@td...> - 2002-08-16 01:39:13
|
Jeff & Mark, At some point, I will need the GSpawnError enumeration defined so that org.gnu.gnome.Url can report appropriate errors from the .show method.=20 This isn't a top priority item. Thanks, --=20 Philip A. Chapman |
From: Philip A. C. <pc...@td...> - 2002-08-15 18:30:24
|
Jeff, I really like what you did with making findListener more generic so that any subclass can use it. This is much better than my idea of subclassing Vector and makes a lot more sense. Anyway, I just checked in a small change to Widget. I added code in findListenr that checks for the parameter listener =3D=3D null. If listener =3D=3D null, -1 is returned. This keeps from having a invalid use of null in the method. > I have gone with the second approach. Check out the > latest code in cvs. =20 >=20 > -Jeff --=20 Philip A. Chapman |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-15 18:20:21
|
I like eclipse. We use it at work and I do some java-gnome development with it. I have checked a few of the meta files used by eclipse into cvs. -Jeff > Hi again. > > Anyone use the eclipse dev platform here? > Is it a good tool for java devel? > Is it available for linux in ppc? > How pretty is swt(I know it is build on top of gtk in linux xDDDD)?. > > I just want to hear your comments, if any. > > thanks. > > > Rubio Jr. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > |
From: Rubio Jr. <ser...@hi...> - 2002-08-15 18:03:19
|
Hi again. Anyone use the eclipse dev platform here? Is it a good tool for java devel? Is it available for linux in ppc? How pretty is swt(I know it is build on top of gtk in linux xDDDD)?. I just want to hear your comments, if any. thanks. Rubio Jr. |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-15 17:51:41
|
> I will not go into it any further as I'm sure everyone on > this list are > aware of Swing's Adapter classes. I just wanted to point out > how we may > be able to bypass what I see as a problem in Swing and, in so doing, > make our APIs easier to use. I have gone with the second approach. Check out the latest code in cvs. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-15 17:44:32
|
I agree. In addition, it makes coding the listener a little easier. If you are only wanting to listen for a key being pressed, you do not have to implement an empty keyReleased(Event e) method, you simply implement the keyEvent(Event e) method and test to see if the event is a keypress. Again, this doesn't seem like a big deal in this example, but can mean a big difference if there are a lot of different types of a kind of event. MouseEvents for example. You might have MouseMoved, MouseClick, MouseDoubleClick, MouseDrag, etc. You may only want to listen for a click, why implement the others if you don't need them? AWT and Swing have that kind of problem, for which Sun introduced the Adaptor classes. MouseAdapter, for instance implements all of the 5 event methods of MouseListener with empty methods. I will not go into it any further as I'm sure everyone on this list are aware of Swing's Adapter classes. I just wanted to point out how we may be able to bypass what I see as a problem in Swing and, in so doing, make our APIs easier to use. On Thu, 2002-08-15 at 10:30, Rubio Jr. wrote: > Umm, I like the second aproach. The event should be an object, it is > something that can be represented by an abstract data type. It is not a > behavior of an object. >=20 >=20 >=20 > Rubio Jr. >=20 >=20 > On Thu, 2002-08-15 at 16:55, Jeffrey Morgan wrote: > > I would like to get everybody's opinion on something. > > Is it better to define a method on a listener interface > > for each type of event or is it better to define one > > method and have the event class specify the type. For > > example: > >=20 > > Option 1: A method for each type of event > >=20 > > public interface KeyListener { > > public void keyPressed(KeyEvent event); > > public void keyReleased(KeyEvent event); > > }; > >=20 > >=20 > > Option 2: A single method with the KeyEvent > > specifying the actual event. > >=20 > > public interface KeyListener { > > public void keyEvent(KeyEvent event); > > }; > >=20 > > if (event.getId() =3D=3D KeyEvent.PRESSED) > > ... > >=20 > > Let me know what your thoughts. > >=20 > > -Jeff >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers --=20 Philip A. Chapman |
From: Rubio Jr. <ser...@hi...> - 2002-08-15 15:23:02
|
Umm, I like the second aproach. The event should be an object, it is something that can be represented by an abstract data type. It is not a behavior of an object. Rubio Jr. On Thu, 2002-08-15 at 16:55, Jeffrey Morgan wrote: > I would like to get everybody's opinion on something. > Is it better to define a method on a listener interface > for each type of event or is it better to define one > method and have the event class specify the type. For > example: > > Option 1: A method for each type of event > > public interface KeyListener { > public void keyPressed(KeyEvent event); > public void keyReleased(KeyEvent event); > }; > > > Option 2: A single method with the KeyEvent > specifying the actual event. > > public interface KeyListener { > public void keyEvent(KeyEvent event); > }; > > if (event.getId() == KeyEvent.PRESSED) > ... > > Let me know what your thoughts. > > -Jeff |
From: Rubio Jr. <ser...@hi...> - 2002-08-15 15:22:19
|
Hi Mark! Welcome. and hi everyone. Ok I have the clases that you said already implemented. In a few moments I will release them to the cvs. I have been thinking in the gdk event model and I think it would be better to continue with the gtk events idea. I'm going to create a gdk.event subpackage with a GdkEvent base class. KeyboardEvent would inherit from the GdkEvent class, or maybe from an InputEvent class. What do you think about this? GdkEvent | InputEvent | KeyboardEvent Or GdkEvent | KeyboardEvent thank you guys. PD. Just one more thing, why did you choose to remove de Gdk,Gtk... prefix from the classes? I think than it makes the code more eye candy if you work with more frameworks. Anyway, just a silly thing. |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-15 15:02:24
|
> JUnit would probably be nice for this, but we > don't have it set up yet and I do not know how. I did check in a couple of base classes for the testing framework. I will continue to enhance this as we go forward. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-15 14:55:29
|
On Thu, 2002-08-15 at 08:54, Jeffrey Morgan wrote: > We have a new developer on the team. Please join > me in welcoming Mark Howard. I am quite excited > to have each of you join the team. For the past > two years I have, for the most part, worked on this > project alone. Now that we have several people > working on the project coordination is critical. We > need to make sure we are not working on the same code. > Philip is primarily focusing on the gnome package. > Rubio is primarily focusing on the gdk package. Mark, > you and I need to coordinate our efforts for the gtk > and pango packages. Welcome Mark! Right now is an exciting time to be involved with the java-gnome project. > I hope to complete the approach for event handling=20 > today. I then hope we can implement this approach > throughout all of the widgets. Please take a look > at what exists in gtk.Widget and let me know what > you think. Once I complete this I hope to implement > the event handling in gtk.Widget and gtk.Window. After > I complete this I wanted to continue with the additional > Window classes (gtk.Dialog, gtk.MessageDialog, gtk.WindowGroup, > etc.). There are still a few container classes that I > wish to address (HPanned, VPanned, Layout, and Notebook). So far, gtkWidget looks very good to me. Kudos. A status report on where I am. I was not able to work on the gnome classes last night. The night before, I did a lot of looking at what Jeff had done with gtk.Widget to that point and poking around in general. Starting tonight, I think I will start building the gnome classes and modifiying the testgnome example to use the new API. My first mission is to get the gnome classes to the the point where I can get the testgnome example running. I can add gnome classes from there, maybe working through all the examples, modifying the examples and completing out the gnome classes as I go. If this approach is not structured enough, I could simply go through each class at a time trying to make them as feature rich as possible. I would still have to get testgnome running so that I can test functionallity as I go. JUnit would probably be nice for this, but we don't have it set up yet and I do not know how. --=20 Philip A. Chapman |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-15 14:55:24
|
I would like to get everybody's opinion on something. Is it better to define a method on a listener interface for each type of event or is it better to define one method and have the event class specify the type. For example: Option 1: A method for each type of event public interface KeyListener { public void keyPressed(KeyEvent event); public void keyReleased(KeyEvent event); }; Option 2: A single method with the KeyEvent specifying the actual event. public interface KeyListener { public void keyEvent(KeyEvent event); }; if (event.getId() == KeyEvent.PRESSED) ... Let me know what your thoughts. -Jeff |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-15 13:54:27
|
We have a new developer on the team. Please join me in welcoming Mark Howard. I am quite excited to have each of you join the team. For the past two years I have, for the most part, worked on this project alone. Now that we have several people working on the project coordination is critical. We need to make sure we are not working on the same code. Philip is primarily focusing on the gnome package. Rubio is primarily focusing on the gdk package. Mark, you and I need to coordinate our efforts for the gtk and pango packages. I hope to complete the approach for event handling today. I then hope we can implement this approach throughout all of the widgets. Please take a look at what exists in gtk.Widget and let me know what you think. Once I complete this I hope to implement the event handling in gtk.Widget and gtk.Window. After I complete this I wanted to continue with the additional Window classes (gtk.Dialog, gtk.MessageDialog, gtk.WindowGroup, etc.). There are still a few container classes that I wish to address (HPanned, VPanned, Layout, and Notebook). -Jeff |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-14 13:33:29
|
I have been busy on Widget, Window, GtkObject and several related event classes. I hope to release all of this code into cvs sometime this evening. Rubio, I have ran into a few classes that I need from gdk. Can you please look at and possible work on the following: Rectangle, Colormap, Point - Just provide a simple public interface to set and get the values and also be able to initialize an object if a handle is returned from a method. Keystroke representation - we need to be able to represent/identify a keystroke. This will be used by the KeyEvent and other widgets that need to identify what key was pressed. There are several classes in the gdk layer that are on topic. Can you design this implementation? Thanks -Jeff |
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-14 13:29:45
|
> I've managed to generate .java files from gnome2.defs using the > following: > > $java -cp $CLASSPATH:/home/wyvern/src/java-gnome/src/tools > DefsProcessor --out-dir=/home/wyvern/tmp/java-gnome > defs/gnome2.defs > > ~/output.txt 2>&1 There is a script in the src directory that should do this for you. > As I work through the gnome classes, should I put them in > java-gnome/src/java/org/gnu/gnome (over-writing what's > already there)? > Do the generated .c and .h files need to replace the ones in > /src/jni? > I think I'm right here, but want to be *sure* before I start > clobbering > files. Think of it as more of a merge. You need to make sure you don't overwrite any manually code that has been added in the src/java or src/jni directory. The generator is now just a development tool that generates the binding code for us. For example, I just changed the signature of a method in the gtk2.defs file and ran the generator. Once finished I just copy/paste the method from the java and c file into the equivalent files in src/java and src/c. Hope this helps. I am still out of the office on a family issue. I will have minimal access to email until late tonight. I hope to catch up with you then. -Jeff |
From: Philip A. C. <pc...@td...> - 2002-08-14 03:32:55
|
Jeff, I've managed to generate .java files from gnome2.defs using the following: $java -cp $CLASSPATH:/home/wyvern/src/java-gnome/src/tools DefsProcessor --out-dir=3D/home/wyvern/tmp/java-gnome defs/gnome2.defs > ~/output.txt 2>&1 As I work through the gnome classes, should I put them in java-gnome/src/java/org/gnu/gnome (over-writing what's already there)?=20 Do the generated .c and .h files need to replace the ones in /src/jni?=20 I think I'm right here, but want to be *sure* before I start clobbering files. On Tue, 2002-08-13 at 21:25, Philip A. Chapman wrote: > Jeff, >=20 > I remember you saying something about taking the automatic generation of > the .java files from the .defs files out of the build process. Sure > enough, my org.gnu.gnome .java files do not show changes I've made > lately. What command should I use to rebuild the files? >=20 > Thanks, > --=20 > Philip A. Chapman --=20 Philip A. Chapman |
From: Jeffrey M. <ku...@zo...> - 2002-08-13 18:11:15
|
I like the idea. I want to create a new package to contain the interfaces and the event classes. Perhaps org.gnu.gtk.event. I will create this package, create the event class, update the Widget class and add a few additional events. I will check this updated code in sometime this evening. I need to check off for now. I should be back online late tonight. -Jeff On Tue, 2002-08-13 at 12:16, Philip A. Chapman wrote: > 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() == FocusEventType.GOT_FOCUS()) { > // Do Something > > else if (FocusEvent.getType() == 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. > 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. > |