java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 119)
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination
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: Mark H. <mh...@ti...> - 2003-03-24 05:34:22
|
Hi,
I'm having trouble with the Timer object. The following method:
private static Fireable f;
public static void invokeLater(Runnable run){
Timer timer;
final Runnable runner = run;
f = new Fireable(){
public boolean fire(){
runner.run();
return false;
}
};
timer = new Timer(1, f);
timer.start();
}
always results in
java.lang.NullPointerException
at org.gnu.gtk.Gtk.gtk_main(Gtk.java:native)
at org.gnu.gtk.Gtk.main(Gtk.java:54)
at com.tildemh.debbuggtk.BugWatcher.main(BugWatcher.java:454)
Any ideas why this is happening?
Also, I think this method would be added to the main code - where should
it go?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Mark H. <mh...@ti...> - 2003-03-24 01:52:00
|
Hi,
As discussed at the start of the year,
I'd like to make some big changes to the way we handle passing of
strings. The current code has major issues on some (non-Sun) Java
environments (when working with zero length strings) and also does not
take into account charset encoding.
These changes:
* use (*env)->GetStringUTFChars rather than
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
* Also call (*env)->ReleaseStringUTFChars(env, str, str_g);
- As far as I can see, the old code is wrong in that it should have
been calling ReleaseByteArrayElements when done
- please let me know if you don't agree with this.
The attached files demonstrate the changes I propose. Test.c shows both
the current and proposed methods
They can be executed using
gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker
--no-undefined
javac TestClass.java
LD_LIBRARY_PATH=. java TestClass
In my tests, the new code always also has improved performance (Java
1.4.1)
The changes would require regenerating all the generated code and
(hopefully semi-automatically) changing all calls to these.
Any comments?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Jeffrey M. <ku...@zo...> - 2003-03-23 21:48:58
|
I have completed the glib, gdk, atk, and pango packages. -Jeff On Sun, 2003-03-23 at 11:52, Mark Howard wrote: > On Fri, 2003-03-21 at 15:29, Jeffrey Morgan wrote: > > I will work on the glib and gdk packages. > > -----Original Message----- > > From: Mark Howard [mailto:mh...@ti...] > > I'd like to start with gtk Label, Frame and Tree widgets. > > Sorry, I should have said I included glib.Value and Type as part of > this. > I've also done some of the other gtk widgets. > > I'd now like to start looking at the gnome widgets as I have a strong > suspicion that this string issue is what's been causing so many problems > for me. -- Jeffrey Morgan <ku...@zo...> |
|
From: Mark H. <mh...@ti...> - 2003-03-23 16:53:03
|
On Fri, 2003-03-21 at 15:29, Jeffrey Morgan wrote: > I will work on the glib and gdk packages. > -----Original Message----- > From: Mark Howard [mailto:mh...@ti...] > I'd like to start with gtk Label, Frame and Tree widgets. Sorry, I should have said I included glib.Value and Type as part of this. I've also done some of the other gtk widgets. I'd now like to start looking at the gnome widgets as I have a strong suspicion that this string issue is what's been causing so many problems for me. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Mark H. <mh...@ti...> - 2003-03-22 14:30:43
|
Hi,
One of the commits since last night has started to produce exceptions
in the Timer related code. This occurs any time I start a timer.
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4C3F69A0
Function=(null)+0x4C3F69A0
Library=/home/mark/dev/java-gnome/lib/libGTKJava.so.0.8.0
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
at org.gnu.glib.GObject.addEventHandler(Native Method)
at org.gnu.glib.EventMap.initialize(EventMap.java:66)
at org.gnu.gtk.Container.initializeEventHandlers(Container.java:191)
at org.gnu.gtk.Dialog.initializeEventHandlers(Dialog.java:251)
at org.gnu.gtk.MessageDialog.<init>(MessageDialog.java:53)
at
com.tildemh.debbuggtk.ListingReport.showError(ListingReport.java:277)
at
com.tildemh.debbuggtk.ListingConstructor$1.run(ListingConstructor.java:126)
at com.tildemh.debbuggtk.Utils$1.fire(Utils.java:28)
at org.gnu.gtk.Gtk.gtk_main(Native Method)
at org.gnu.gtk.Gtk.main(Gtk.java:54)
at com.tildemh.debbuggtk.BugWatcher.main(BugWatcher.java:246)
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Mark H. <mh...@ti...> - 2003-03-22 13:19:21
|
Hi,
ListStore and TreeStore (TreeModels) are the model part of the tree
and list widget MVC pattern.
At the moment, they are constructed in the form:
new ListStore( new Type[] {Type.STRING(), Type.INT() ...} );
and used:
listStore.(set|get)Value( iter, 2, 5 );
(2 is the dataBlock of the store; 5 is the value)
(these methods are overloaded for each possible type)
There are two big disadvantages with this:
- It is not easy to keep track of which dataBlock (aka column) relates
to which set of data - methods require an integer argument corresponding
to the order in which the Types were passed to the TreeModel
constructor.
- No type checking is performed. I've found this quite problematic
recently when I had forgotten to call toString() on an object.
I think a good way to solve these problems would be to create new
classes:
Abstract class dataBlock;
dataBlockInt extends dataBlock
dataBlockString
dataBlockObject
dataBlockBoolean
They would then be used in the following way:
private dataBlockString taskName = new dataBlockString();
private dataBlockInt hours = new dataBlockInt();
private dataBlockInt remaining = new dataBlockInt();
private dataBlockString person = new dataBlockString();
...
new ListStore( new dataBlock[] { taskName, hours, remaining, person } );
setValue( iter, taskName, "fix bugs" );
- type checking would be performed on this.
I have used the term dataBlock where gtk usually says column. This is
because I was confused when learning about these widgets as you also
need TreeViewColumns, which are used by the views. I would prefer to
keep calling these dataBlocks in the hope that the bindings will be
easier to learn. But I could probably be convinced otherwise...
Any comments?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Mark H. <mh...@ti...> - 2003-03-22 13:19:19
|
On Fri, 2003-03-21 at 21:02, Tom Ball wrote: > Any objections? Looks fine. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Tom B. <Tom...@Su...> - 2003-03-21 21:13:34
|
Here's a heads-up that I am changing the format of those native methods
which are being upgraded to support strings properly. The code
generator initializes a stack variable for each type conversion; my own
experience is that this makes the code more verbose and harder to read.
Then there's the question as to whether you can trust the compiler to
optimize all of this extra stuff away (I never learned to trust C
compilers' optimizers).
As a result, you'll see code like this:
JNIEXPORT jboolean JNICALL
Java_org_gnu_gtk_TextIter_gtk_1text_1iter_1backward_1search (JNIEnv
*env, jclass cls, jint iter, jbyteArray str, jint flags,
jint matchStart, jint matchEnd, jint limit)
{
GtkTextIter *iter_g = (GtkTextIter *)iter;
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
GtkTextSearchFlags flags_g = (GtkTextSearchFlags) flags;
GtkTextIter *matchStart_g = (GtkTextIter *)matchStart;
GtkTextIter *matchEnd_g = (GtkTextIter *)matchEnd;
GtkTextIter *limit_g = (GtkTextIter *)limit;
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
{
jboolean result_j = (jboolean) (gtk_text_iter_backward_search
(iter_g, str_g, flags_g,
matchStart_g, matchEnd_g, limit_g));
return result_j;
}
}
be putback as this:
JNIEXPORT jboolean JNICALL
Java_org_gnu_gtk_TextIter_gtk_1text_1iter_1backward_1search (JNIEnv
*env, jclass cls, jint iter, jstring str, jint flags,
jint matchStart, jint matchEnd, jint limit)
{
const char *str_utf = (*env)->GetStringUTFChars(env, str, NULL);
jboolean result_j = (jboolean) gtk_text_iter_backward_search (
(GtkTextIter*)iter,
(gchar*)str_utf,
(GtkTextSearchFlags)flags,
(GtkTextIter*)matchStart,
(GtkTextIter*)matchEnd,
(GtkTextIter*)limit);
(*env)->ReleaseStringUTFChars(env, str, str_utf);
return result_j;
}
If a parameter is cast the same way twice I keep the temporary variable,
again to make things as legible as possible.
Any objections?
Tom
|
|
From: Tom B. <Tom...@Su...> - 2003-03-21 19:36:47
|
I'll finish up the GTK text widgets. I was holding back because Mark had recently made them functional (didn't want to step on his good work), but was shocked to find that the generator downcasts the returned gunichar from gtk_text_iter_get_char() as a jbyte. We might as well post a sign saying that only customers whose customer sets can be defined in seven bits need bother with our library! Oh, the horror... Tom |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-21 15:54:08
|
I will work on the glib and gdk packages. -Jeff -----Original Message----- From: Mark Howard [mailto:mh...@ti...] Sent: Friday, March 21, 2003 7:29 AM To: jav...@li... Subject: RE: [java-gnome-hackers] String changes On Thu, 2003-03-20 at 22:22, Jeffrey Morgan wrote: > The manual approach does seem to be the least intrusive. I > vote for this approach. I've created a file src/jni/TODO containing the names of the files which still need to be done. Please delete names from it when you've fixed them. I think just sending a mail to this list before you start work on a set of files would be the best way to avoid duplication. I'd like to start with gtk Label, Frame and Tree widgets. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Mark H. <mh...@ti...> - 2003-03-21 12:29:40
|
On Thu, 2003-03-20 at 22:22, Jeffrey Morgan wrote: > The manual approach does seem to be the least intrusive. I > vote for this approach. I've created a file src/jni/TODO containing the names of the files which still need to be done. Please delete names from it when you've fixed them. I think just sending a mail to this list before you start work on a set of files would be the best way to avoid duplication. I'd like to start with gtk Label, Frame and Tree widgets. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 22:36:19
|
The changes were to remove warnings and bad casts that were in the generated C code. I probably changed about one third of the classes. It was much easier to do this than to get the generator to produce accurate code in each instance. -Jeff -----Original Message----- From: Mark Howard [mailto:mh...@ti...] Sent: Thursday, March 20, 2003 10:40 AM To: jav...@li... Subject: RE: [java-gnome-hackers] String changes On Thu, 2003-03-20 at 12:17, Jeffrey Morgan wrote: > My only concern is that this is a very significant change. > It will not be as simple as just regenerating the generated > code since I have made changes and optimizations to many > of the generated classes. Still, I think this is the right > thing to do. Perhaps we should divide this activity up > between several people to expedite the process. Yes, it is a significant change, but one I believe is worth it. In particular, it allows java-gnome to be used with many free JVM's, which I believe should be a goal of the project. Dividing the activity is a good idea, if people are able to. I think, however, that much of the work can be partially automated - most of the java calls to strings are done using getBytes() - we could do a big find & replace (with manual verification for each). Any other changes then required should show up as compile errors. By optimisations, do you mean changes in the BEGINNING OF GENERATED CODE section? If so, can you remember what you've changed (or could we regenerate the current code and test for changes?) The only such changes I've made is adding comments to the constants in some of the classes converted from enums. Enums won't be changed by this proposal, so we can ignore those in the update. We should also decide if there are any other changes which should be made to the code generator before going ahead. I can only think of two minor ones: - add a space in the comment for the start/end of generated code (so it doesn't confuse javadoc) - change generated enum integer constants to private (I have done this on the current code using a simple find/replace) Are there any changes in Gtk2.2 which might be worth looking at at this stage? I know it's API compatible with 2.0, but are there any additional functions? -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 22:22:39
|
The manual approach does seem to be the least intrusive. I vote for this approach. -Jeff -----Original Message----- From: Tom Ball [mailto:Tom...@Su...] Sent: Thursday, March 20, 2003 12:17 PM To: java-gnome-hackers Subject: Re: [java-gnome-hackers] String changes The way strings are handled has been bothering me as well, most recently in finding that repeatedly calling TextBuffer.setText leaks native memory in a manner I haven't figured out yet. To clean it up, I modified the code in the same manner Mark described. Your point about not supporting charset encoding is an excellent one -- GNOME more than many projects is sensitive to internationalization issues, so we can't ignore this problem and stay in step with GNOME. Since Java and GTK already share the same internal String format, we will reduce the code overhead and improve compatibility with this change. At JavaSoft we used to call that sort of enhancement request a "no-brainer", in that it was a change even a clueless exec would approve. :-) Like Jeffrey, I'm nervous about regenerating the existing source files. By all means update the generator so that new files are created correctly, but most of your conversion impacts native code rather than the generated Java code. Since most of the conversion has to be done by hand any way, let's do it all by hand so each class can be converted individually to minimize breakage. Doing it piecemeal keeps the source base functional without anyone having to pull an all-nighter. To avoid duplication of effort, how about if we notify others before converting any major classes? I have TextBuffer half-done already, so unless there are objections, I'll finish it and put it back today. Tom On Wed, 2003-03-19 at 13:22, Mark Howard wrote: > Hi, > As discussed at the start of the year, > I'd like to make some big changes to the way we handle passing of > strings. The current code has major issues on some (non-Sun) Java > environments (when working with zero length strings) and also does not > take into account charset encoding. > > These changes: > * use (*env)->GetStringUTFChars rather than > jint str_len = (*env)->GetArrayLength(env, str); > gchar* str_g = (gchar*)g_malloc(str_len + 1); > (*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g); > str_g[str_len] = 0; > * Also call (*env)->ReleaseStringUTFChars(env, str, str_g); > - As far as I can see, the old code is wrong in that it should have > been calling ReleaseByteArrayElements when done > - please let me know if you don't agree with this. > > > The attached files demonstrate the changes I propose. Test.c shows both > the current and proposed methods > They can be executed using > gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > > gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl > -lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker > --no-undefined > > javac TestClass.java > LD_LIBRARY_PATH=. java TestClass > > In my tests, the new code always also has improved performance (Java > 1.4.1) > > The changes would require regenerating all the generated code and > (hopefully semi-automatically) changing all calls to these. > > Any comments? -- Tom Ball <Tom...@Su...> ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Tom B. <Tom...@Su...> - 2003-03-20 17:17:09
|
The way strings are handled has been bothering me as well, most recently in finding that repeatedly calling TextBuffer.setText leaks native memory in a manner I haven't figured out yet. To clean it up, I modified the code in the same manner Mark described. Your point about not supporting charset encoding is an excellent one -- GNOME more than many projects is sensitive to internationalization issues, so we can't ignore this problem and stay in step with GNOME. Since Java and GTK already share the same internal String format, we will reduce the code overhead and improve compatibility with this change. At JavaSoft we used to call that sort of enhancement request a "no-brainer", in that it was a change even a clueless exec would approve. :-) Like Jeffrey, I'm nervous about regenerating the existing source files. By all means update the generator so that new files are created correctly, but most of your conversion impacts native code rather than the generated Java code. Since most of the conversion has to be done by hand any way, let's do it all by hand so each class can be converted individually to minimize breakage. Doing it piecemeal keeps the source base functional without anyone having to pull an all-nighter. To avoid duplication of effort, how about if we notify others before converting any major classes? I have TextBuffer half-done already, so unless there are objections, I'll finish it and put it back today. Tom On Wed, 2003-03-19 at 13:22, Mark Howard wrote: > Hi, > As discussed at the start of the year, > I'd like to make some big changes to the way we handle passing of > strings. The current code has major issues on some (non-Sun) Java > environments (when working with zero length strings) and also does not > take into account charset encoding. > > These changes: > * use (*env)->GetStringUTFChars rather than > jint str_len = (*env)->GetArrayLength(env, str); > gchar* str_g = (gchar*)g_malloc(str_len + 1); > (*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g); > str_g[str_len] = 0; > * Also call (*env)->ReleaseStringUTFChars(env, str, str_g); > - As far as I can see, the old code is wrong in that it should have > been calling ReleaseByteArrayElements when done > - please let me know if you don't agree with this. > > > The attached files demonstrate the changes I propose. Test.c shows both > the current and proposed methods > They can be executed using > gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > > gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl > -lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker > --no-undefined > > javac TestClass.java > LD_LIBRARY_PATH=. java TestClass > > In my tests, the new code always also has improved performance (Java > 1.4.1) > > The changes would require regenerating all the generated code and > (hopefully semi-automatically) changing all calls to these. > > Any comments? -- Tom Ball <Tom...@Su...> |
|
From: Mark H. <mh...@ti...> - 2003-03-20 15:40:46
|
On Fri, 2003-03-07 at 21:45, Tom Ball wrote: > I have a Label whose background I'd like to be the same color as the > background of other text widgets (white, on my system). What's the > simplest way to set it? > > I've tried setBackgroundColor, setTextColor, and setBaseColor (all for > all standard states) without any effect. I was even considering a Pango > markup string, but realized that it would only change the background of > the text, not the whole widget. The widget is defined by a Glade file, > but I can't find how to set the color there, either. Sorry, I don't know how this would be achieved, if it's possible. If you know of any gtk applications which do this anywhere (I can't think of any at the moment), then try looking at the source code to see how they do it. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Mark H. <mh...@ti...> - 2003-03-20 15:40:39
|
On Thu, 2003-03-20 at 12:17, Jeffrey Morgan wrote: > My only concern is that this is a very significant change. > It will not be as simple as just regenerating the generated > code since I have made changes and optimizations to many > of the generated classes. Still, I think this is the right > thing to do. Perhaps we should divide this activity up > between several people to expedite the process. Yes, it is a significant change, but one I believe is worth it. In particular, it allows java-gnome to be used with many free JVM's, which I believe should be a goal of the project. Dividing the activity is a good idea, if people are able to. I think, however, that much of the work can be partially automated - most of the java calls to strings are done using getBytes() - we could do a big find & replace (with manual verification for each). Any other changes then required should show up as compile errors. By optimisations, do you mean changes in the BEGINNING OF GENERATED CODE section? If so, can you remember what you've changed (or could we regenerate the current code and test for changes?) The only such changes I've made is adding comments to the constants in some of the classes converted from enums. Enums won't be changed by this proposal, so we can ignore those in the update. We should also decide if there are any other changes which should be made to the code generator before going ahead. I can only think of two minor ones: - add a space in the comment for the start/end of generated code (so it doesn't confuse javadoc) - change generated enum integer constants to private (I have done this on the current code using a simple find/replace) Are there any changes in Gtk2.2 which might be worth looking at at this stage? I know it's API compatible with 2.0, but are there any additional functions? -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 12:43:10
|
My only concern is that this is a very significant change.
It will not be as simple as just regenerating the generated
code since I have made changes and optimizations to many
of the generated classes. Still, I think this is the right
thing to do. Perhaps we should divide this activity up
between several people to expedite the process.
-Jeff
-----Original Message-----
From: Mark Howard [mailto:mh...@ti...]
Sent: Wednesday, March 19, 2003 4:22 PM
To: jav...@li...
Subject: [java-gnome-hackers] String changes
Hi,
As discussed at the start of the year,
I'd like to make some big changes to the way we handle passing of
strings. The current code has major issues on some (non-Sun) Java
environments (when working with zero length strings) and also does not
take into account charset encoding.
These changes:
* use (*env)->GetStringUTFChars rather than
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
* Also call (*env)->ReleaseStringUTFChars(env, str, str_g);
- As far as I can see, the old code is wrong in that it should have
been calling ReleaseByteArrayElements when done
- please let me know if you don't agree with this.
The attached files demonstrate the changes I propose. Test.c shows both
the current and proposed methods
They can be executed using
gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker
--no-undefined
javac TestClass.java
LD_LIBRARY_PATH=. java TestClass
In my tests, the new code always also has improved performance (Java
1.4.1)
The changes would require regenerating all the generated code and
(hopefully semi-automatically) changing all calls to these.
Any comments?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Tom B. <Tom...@Su...> - 2003-03-19 21:37:01
|
On Wed, 2003-03-19 at 13:22, Mark Howard wrote: > java.lang.NullPointerException > at org.gnu.gtk.Gtk.gtk_main(Gtk.java:native) > at org.gnu.gtk.Gtk.main(Gtk.java:54) > at com.tildemh.debbuggtk.BugWatcher.main(BugWatcher.java:454) > > Any ideas why this is happening? No, but I'll look into it. I had almost identical code in my VPN client, but removed it when hitting the same bug. Still, that should work. > Also, I think this method would be added to the main code - where should > it go? I asked that question last month without any responses. My suggestion was to create a GLib.java which held untyped GLib routines, much as Gtk.java and Gnome.java do. If no one has objections, that's where I'll put it. BTW, I don't think Timer is the right way to implement invokeLater (although I used the same approach). My limited understanding of GLib suggests that it's worth the extra work to support creating a new event source (perhaps using g_main_context_add_poll()). My suspicion is that we'll be needing to define other event types over time. Tom |
|
From: Mark H. <mh...@ti...> - 2003-03-19 21:24:19
|
Hi,
As discussed at the start of the year,
I'd like to make some big changes to the way we handle passing of
strings. The current code has major issues on some (non-Sun) Java
environments (when working with zero length strings) and also does not
take into account charset encoding.
These changes:
* use (*env)->GetStringUTFChars rather than
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
* Also call (*env)->ReleaseStringUTFChars(env, str, str_g);
- As far as I can see, the old code is wrong in that it should have
been calling ReleaseByteArrayElements when done
- please let me know if you don't agree with this.
The attached files demonstrate the changes I propose. Test.c shows both
the current and proposed methods
They can be executed using
gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker
--no-undefined
javac TestClass.java
LD_LIBRARY_PATH=. java TestClass
In my tests, the new code always also has improved performance (Java
1.4.1)
The changes would require regenerating all the generated code and
(hopefully semi-automatically) changing all calls to these.
Any comments?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Mark H. <mh...@ti...> - 2003-03-19 21:24:03
|
Hi,
I'm having trouble with the Timer object. The following method:
private static Fireable f;
public static void invokeLater(Runnable run){
Timer timer;
final Runnable runner = run;
f = new Fireable(){
public boolean fire(){
runner.run();
return false;
}
};
timer = new Timer(1, f);
timer.start();
}
always results in
java.lang.NullPointerException
at org.gnu.gtk.Gtk.gtk_main(Gtk.java:native)
at org.gnu.gtk.Gtk.main(Gtk.java:54)
at com.tildemh.debbuggtk.BugWatcher.main(BugWatcher.java:454)
Any ideas why this is happening?
Also, I think this method would be added to the main code - where should
it go?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Mark H. <mh...@ti...> - 2003-03-19 21:19:26
|
Hi, I'm trying to create a Button which uses an icon from a StockItem, but has different text. I've not been able to work out how to do this by looking through the docs. Can anyone point me in the direction of some code which does this? (either Java-gnome or C) All the places I've looked so far use libglade, so aren't much use. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Mark H. <mh...@ca...> - 2003-03-12 12:34:50
|
On Thu, 2003-02-27 at 22:39, Tom Ball wrote: > The various GNOME error and warning messages that get displayed to the > console were bothering me, so I implemented log handlers for the > libraries we use. These handlers throw a RuntimeException with the > error message inside. > > Is something like this of interest to you folks? Regardless of what > gets designed, we need some sort of error reporting strategy. I like > using RuntimeExceptions because they are easier for an application > writer to manage than log handlers (just add a catch block). Another > option is some sort of Error event and listener, but then errors would > get reported after the offending method invocation, rather than during > it. This sounds very interesting. In most cases, these problems are only minor, so should not stop the program from continuing. I think it would be useful to print a stack trace when such an error occurs (in addition to the gtk message) and also possibly add this exception to a list of such exeptions. The user could be notified of additions to this list with a event so that they can do logging or give an error message. Using this scheme, it should also be possible to have an option for whether the exception should also be raised when called, then we can cater for whatever the application writer wants. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Tom B. <Tom...@Su...> - 2003-03-07 21:47:36
|
I have a Label whose background I'd like to be the same color as the background of other text widgets (white, on my system). What's the simplest way to set it? I've tried setBackgroundColor, setTextColor, and setBaseColor (all for all standard states) without any effect. I was even considering a Pango markup string, but realized that it would only change the background of the text, not the whole widget. The widget is defined by a Glade file, but I can't find how to set the color there, either. Any help would be appreciated. I can't use a read-only TextView because TextBuffer.setText leaks Strings and char arrays and I haven't figured out why. Tom |
|
From: Mark H. <mh...@ca...> - 2003-03-04 20:04:44
|
On Tue, 2003-03-04 at 17:18, Tom Ball wrote:
> I'd like to modify the org.gnu.glib.Timer API before more people start
> using it.
>
> public interface Fireable {
> boolean fire();
> }
looks good.
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Tom B. <Tom...@Su...> - 2003-03-04 17:19:34
|
I'd like to modify the org.gnu.glib.Timer API before more people start
using it. The problem is that it uses the Runnable interface which
defines a void method, while GLib's timeout facility uses a function
that returns a boolean. This boolean return makes it very easy to
define a one-shot timer, and for a timeout function to stop itself
cleanly -- just return false instead of true. With a Runnable
interface, one has to jump through hoops to achieve the same result.
Since you can't overload a method's return value and since timers are
traditionally thought to fire rather than run anyway, I'd like to define
the following to replace Timer's use of Runnable:
package org.gnu.glib;
public interface Fireable {
/**
* This method executes when "fired" by a subsystem, such as by
* a timer.
*
* @return true if the timer should continue executing, or false
* if this is the last invocation of this method.
*/
boolean fire();
}
One option is to make Fireable an inner interface of Timer. Timer's
constructor would change to:
public Timer(int interval, Fireable target) {}
and Timer._run() can then be deleted.
Any objections? One nice side-benefit is that an invokeLater method
becomes trivial to implement by using a one-shot timer.
Tom
|
34 messages has been excluded from this view by a project administrator.
