java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 3)
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: Guillaume M. <res...@gm...> - 2012-02-03 00:22:02
|
2012/2/2 Andrew Cowie <an...@op...>: > Guillaume has hit an interesting engineering problem. I did :) > There is a signal which returns an array of GFile. That doesn't seem > like a problem, except that on the C side of the signal marshaling code > we don't have anything to handle arrays. To get the JNI signature, to call the right method, a C function is called for each argument of the method returning the correct string. We currently handle a various number of cases (integer, strings, objects etc...) but we do not handle array. The called C function is "bindings_java_typeToSignature". So the problem is to know if a gpointer is actually an array. We can't do that with our current "switch...case" (I don't think so). So we should probably do something else. > My best guess is to write a custom handler C side that takes the > gpointer and turns it into a GList* of GFile. But we would still need > code to handle that in the signal marshaller. A custom handler could be the beginning of a fix but we will still need to handle arrays or lists. We could use a G_TYPE_STRV which is an array of strings but in the marshaller this type would be G_TYPE_BOXED so we will be hiting another problem. How can we know that a G_TYPE_BOXED is actually a G_TYPE_STRV? GList* would be tricky, I never saw any signal using a GList* as parameter. > Guillaume could give more detail, I'm sure. I hope I was understandable enough ;) -- Guillaume Mazoyer - http://respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2012-02-02 05:19:31
|
Guillaume has hit an interesting engineering problem. There is a signal which returns an array of GFile. That doesn't seem like a problem, except that on the C side of the signal marshaling code we don't have anything to handle arrays. The situation is complicated by the fact that the actual signature in the signal is "gpointer files". Last I checked that was a typedef for void*, but that doesn't help us because we need to detect it and turn it into an [] of org.gnome.glib.File. We can't even special case it, because all we have to work from in the signal marshaling code is the GType and it is G_TYPE_POINTER. So I'm at a bit of a loss. The primary engineering question is "how do we get arrays as arguments in signals. The secondary problem is "how can we figure out what to do when all we have is G_TYPE_POINTER as a type." My best guess is to write a custom handler C side that takes the gpointer and turns it into a GList* of GFile. But we would still need code to handle that in the signal marshaller. Guillaume could give more detail, I'm sure. AfC Sydney |
|
From: cyber p. <cyb...@gm...> - 2012-02-01 14:27:00
|
Hello, I have just added coverage for style scheme use in GtkSourceView. In the attachment, you will find the associated patch. Best regards, Georgios Migdos. |
|
From: Andrew C. <an...@op...> - 2012-01-15 23:57:22
|
On Mon, 2012-01-16 at 00:20 +0100, Guillaume Mazoyer wrote: > > We're missing something obvious. TONS of other code paths in java-gnome > > handle arrays, GLists, etc of GObjects without any problem. > Yes. But we do not handle arrays for signals. Yes, I see now. I just arrived at that conclusion last night. We're on the same page now. > Apparently, I'm the > first one who wants to use them. For all things there is a first time :) > And moreover it seems hard (to me) to handle them when generating our > methods signatures. I' > For example, when I want "[J" I have got "JI", I seem to recall that code just uses single letters as codes, not as actual JNI signatures. I think "all" we have to do is add a(nother) [special] case for arrays. Looking more today. AfC Ballarat |
|
From: Guillaume M. <res...@gm...> - 2012-01-15 23:20:33
|
> We're missing something obvious. TONS of other code paths in java-gnome > handle arrays, GLists, etc of GObjects without any problem. Yes. But we do not handle arrays for signals. See all our code we actually have no signal which use arrays yet. Apparently, I'm the first one who wants to use them. And moreover it seems hard (to me) to handle them when generating our methods signatures. For example, when I want "[J" I have got "JI", sure we could handle this pretty easily and tell "if you see JI then it is [J". But what if we have "JI" and actually want "JI"? Is it time to re-factor the code that takes care of methods signatures for signals? -- Guillaume Mazoyer |
|
From: Andrew C. <an...@op...> - 2012-01-15 12:26:27
|
On Sat, 2012-01-14 at 00:01 +0100, Guillaume Mazoyer wrote: > Considering the current "bindings_java_typeToSignature" I think that > it can be tricky to make it handle arrays (is it even possible?). So > what can we do about it? Any thoughts? We're missing something obvious. TONS of other code paths in java-gnome handle arrays, GLists, etc of GObjects without any problem. I've got a flight to catch, but I'll try looking this evening. AfC Melbourne |
|
From: Guillaume M. <res...@gm...> - 2012-01-13 23:15:11
|
I forgot to include a short example in my previous mail. After compiling my code here is what I did: javap -classpath .:gtk-4.1.jar -s org.gnome.glib.GApplication This gave me the signature for every methods of the GApplication class. The interesting one is: protected static final void receiveOpen(org.gnome.glib.Signa, long, long[], java.lang.String); Signature: (Lorg/gnome/glib/Signal;J[JLjava/lang/String;)V But when I start my test program and after decommenting the lines 555 and 556 of the "bindings_java_signal.c" file I can see that the signature that is being used to find the "receiveOpen" method is: (Lorg/gnome/glib/Signal;JJILjava/lang/String;)V So the "bindings_java_typeToSignature" function is considering "[J" (the array of GFile) as "JI". -- Guillaume Mazoyer |
|
From: Guillaume M. <res...@gm...> - 2012-01-13 23:02:20
|
I did some changes in my code to use a basic implementation of GFile instead of using String and an array of String. This still does not work but I think that the problem is in a "bindings_java_util.c" function. When looking for a method to handle a signal the code is using the "bindings_java_typeToSignature" function. This is used on all parameters of the function to generate the proper signature. The thing is that this function does not seem to handle arrays. So the signature if the method has arrays in its parameters will be wrong and then the code will not handle the signal properly (saying that the method it is looking for does not exist). Considering the current "bindings_java_typeToSignature" I think that it can be tricky to make it handle arrays (is it even possible?). So what can we do about it? Any thoughts? -- Guillaume Mazoyer |
|
From: Guillaume M. <res...@gm...> - 2012-01-02 23:36:32
|
The branch is almost ready I have finally fixed several bugs and crashes and I'm pretty happy of the result now. There is still something that I can't get done. My custom signals to handle 'command-line' and 'open' signals use arrays of gchar* in the parameters. The thing is that I cannot find a way to use that array from the Java side. I'm actually trying to pass G_TYPE_STRV as type of the parameters during the signal creation but then the code just don't know what to do with that. I figured that the G_TYPE_STRV should be used as G_TYPE_BOXED in the marshaller so it seems tricky to handle. Does anyone has a clue how to "fix" that? Thank for the help. By the way, the branch is still at: hackers/guillaume/gtk-application/ -- Guillaume Mazoyer |
|
From: Guillaume M. <res...@gm...> - 2011-12-18 21:22:13
|
On Sun, Dec 18, 2011 at 10:18:32PM +0100, Guillaume Mazoyer wrote: > In attachment, you will find the patch. And now there is the patch. |
|
From: Guillaume M. <res...@gm...> - 2011-12-18 21:18:55
|
Hello, Since GTK+ 3, a new method has been added to the GtkProgressBar class to tell if a progress bar should display text or not. So I added the coverage for these methods. In attachment, you will find the patch. Regards, -- Guillaume Mazoyer |
|
From: Andrew C. <an...@op...> - 2011-12-15 23:42:19
|
On Thu, 2011-12-15 at 22:28 +0100, Alexander Boström wrote: > Ok, see attached patch. > > Merged to 'mainline', thanks! AfC Sydney |
|
From: Alexander B. <ab...@ro...> - 2011-12-15 22:07:14
|
tor 2011-12-15 klockan 22:28 +0100 skrev Alexander Boström: > ons 2011-12-07 klockan 10:18 +1100 skrev Andrew Cowie: > > > If you set the type of "type" to > > > > Class<? extends Boxed> > > > > in each of the Boxed related methods in [org.gnome.glib] Plumbing it > > compiles cleanly for me. Perhaps you could try that? There are also some public static Entity entityFor(Class<?> type, long pointer) that look suspiciously similar. I'll have a look at that... /Alexander |
|
From: Alexander B. <ab...@ro...> - 2011-12-15 21:29:02
|
ons 2011-12-07 klockan 10:18 +1100 skrev Andrew Cowie: > If you set the type of "type" to > > Class<? extends Boxed> > > in each of the Boxed related methods in [org.gnome.glib] Plumbing it > compiles cleanly for me. Perhaps you could try that? Ok, see attached patch. I haven't had time to install a VM with openjdk 1.7 to run it, but it builds with openjdk 1.7 and builds and runs with openjdk 1.6. /Alexander |
|
From: Serkan K. <se...@ge...> - 2011-12-07 04:48:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could it be a duplicate of guava bug (well this is bug in javac I suppose) See: http://code.google.com/p/guava-libraries/issues/detail?id=635 On 12/07/2011 12:18 AM, Andrew Cowie wrote: > On Tue, 2011-12-06 at 22:16 +0100, Alexander Boström wrote: > >> Adding "extends Boxed" to org.gnome.glib.Plumbing.boxedFor() >> makes it break elsewhere, > > If you set the type of "type" to > > Class<? extends Boxed> > > in each of the Boxed related methods in [org.gnome.glib] Plumbing > it compiles cleanly for me. Perhaps you could try that? > > AfC Sydney > > > > ------------------------------------------------------------------------------ > > > > > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist > and point of discussion for anyone considering optimizing the > pricing and packaging model of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ java-gnome-hackers > mailing list jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7e8CkACgkQRh6X64ivZaJZhgCeLNjzcwxF3tR7V9vPyhgR+pzV 1M8An10/4IZpT//s3GzSea2TZsEcrWrJ =nRWB -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2011-12-06 23:18:45
|
On Tue, 2011-12-06 at 22:16 +0100, Alexander Boström wrote: > Adding "extends Boxed" to org.gnome.glib.Plumbing.boxedFor() makes it > break elsewhere, If you set the type of "type" to Class<? extends Boxed> in each of the Boxed related methods in [org.gnome.glib] Plumbing it compiles cleanly for me. Perhaps you could try that? AfC Sydney |
|
From: Alexander B. <ab...@ro...> - 2011-12-06 21:38:04
|
Hello,
Rebuilding java-gnome 4.1.1 with javac 1.7.0_b147 (on what will become
Fedora 17) fails with this error:
src/bindings/org/gnome/gdk/Plumbing.java:69: error: name clash:
boxedFor(Class<? extends Boxed>,long) in org.gnome.gdk.Plumbing and
boxedFor(Class<?>,long) in org.gnome.glib.Plumbing have the same erasure,
yet neither hides the other
protected static Boxed boxedFor(Class<? extends Boxed> type, long pointer) {
^
Adding "extends Boxed" to glib.Plumbing.boxedFor() makes it break
elsewhere, but if I instead remove it from gdk it does compile. Is that
the right fix?
/Alexander
|
|
From: Andrew C. <an...@op...> - 2011-12-06 00:24:25
|
On Tue, 2011-12-06 at 00:08 +0100, Guillaume Mazoyer wrote: > If anyone wants to give me a hand (by making some code, giving me more > details about how G[tk]Application works, etc..) I will thank you :) You might want to look through https://bugzilla.gnome.org/show_bug.cgi?id=658805 it talks extensively about how to terminate a GTK program when using GtkApplication. Apparently gtk_main_quit() is *not* what you use. Which is unexpected. We'll have to cater for the fact that all our users think Gtk.mainQuit() is how you tell GTK to stop & exit the main loop. AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2011-12-05 23:08:27
|
Hi, I'm currently working on the coverage of GApplication and GtkApplication to fix one of the bug[1] in our Bugzilla. You can find my work on a branch at 'hackers/guillaume/gtk-application/'. Sadly, I'm hiting some problems: * Dbus error, * Command line handler, * Opened files handler. Basically, it works (for now) only if we use the "NONE" ApplicationFlags and if no arguments are passed when starting the application. Moreover, everybody knows that in our lovely crafted bindings, we should always call Gtk.init() first except for some rare cases (you know that right?). But GtkApplication is supposed (and is calling it [the C function]) automatically. Is it cool? I don't know, but it is a problem for us because we cannot allow that. We must explictly call Gtk.init() ourselves. If anyone wants to give me a hand (by making some code, giving me more details about how G[tk]Application works, etc..) I will thank you :) And to finish this email, here is a quote from the IRC channels for people who don't stay always on IRC or who are not using it (you should!). 07:24 < AfC> Respawner: do you want me to hold off releasing 4.1.2? 07:24 < AfC> If you can figure it out it would give us a good feature to include 07:26 < Respawner> AfC: hum I don't know it might take some time to me to figure out the issues, and the issues make the application crash so... 07:27 < AfC> Respawner: Well, we can try and figure them out 07:27 < AfC> Respawner: there have been some threads & bugs about GtkApplication lately, so perhaps that would help 07:27 < Respawner> AfC: hackers/guillaume/gtk-application/ 07:28 < Respawner> AfC: some issues are commented in the code ;) 07:30 < Respawner> and there is a bug which appears when launching the app with args like "java .... GtkApp blabla blibli blublu" 07:30 < Respawner> it says "this app cannot open files" then when you start using the capp (eg clicking on a button) it crashes 07:31 < Respawner> I understand that I have to handle the "command-line" and "open" signals from that error 07:33 < Respawner> the "command-line" signal is probably not a hard to fix, but the "open" signal is a little more complex since it uses a GFile array 07:34 < Respawner> but maybe we can use a String array containing the path to each file instead? 07:35 < Respawner> I don't think that we need to cover GFile, the Java API is capable enough to handle files :D btw: It looks like some guys wants that we integrate the G[tk]Application class before the GNOME 3.4 release. [1] https://bugzilla.gnome.org/show_bug.cgi?id=658400 -- Guillaume Mazoyer |
|
From: Andrew C. <an...@op...> - 2011-10-28 12:30:59
|
On Thu, 2011-10-27 at 20:13 +0200, Guillaume Mazoyer wrote: > Yes I think that it's more consistent. Ok > I changed the signal name and pushed it into the branch. Thanks. Merged to 'mainline' AfC Prague |
|
From: Guillaume M. <res...@gm...> - 2011-10-27 18:13:30
|
On Thu, Oct 27, 2011 at 11:19:26AM +0200, Andrew Cowie wrote: > I'm not saying that this is the best solution, but we should probably be > consistent. If so, then maybe you could change it to > Switch.NotifyActivated ? Yes I think that it's more consistent. I changed the signal name and pushed it into the branch. -- Guillaume Mazoyer |
|
From: Andrew C. <an...@op...> - 2011-10-27 09:19:42
|
On Tue, 2011-10-25 at 01:38 +0200, Guillaume Mazoyer wrote: > From the branch location you probably understand that it covers the > GtkSwitch widget that was introduce with GTK+ 3. That's a pretty simple > branch, I just had to play with some C functions to be able to emit and > catch a signal when the user plays with the Switch. The other 'notify::property' signals we have exposed have been as Widget.NotifyProperty, for example http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/gtk/TextBuffer.NotifyCursorPosition.html I'm not saying that this is the best solution, but we should probably be consistent. If so, then maybe you could change it to Switch.NotifyActivated ? [Yes, I agree it's more cumbersome, but it would be more consistent, maybe. What do you think?] AfC Prague |
|
From: Guillaume M. <res...@gm...> - 2011-10-26 00:12:30
|
Hi,
As said on IRC, I have a branch covering GtkStyleContext and some
related constants and flags I'd like to see merged for the next release
of the bindings. The branch can be found at:
hackers/guillaume/gtk-style-context/
There is a certain amount of C code to review due to the use of some
functions that return GList* etc...
Any feedbacks are welcome.
Cheers,
--
Guillaume Mazoyer
|
|
From: Guillaume M. <res...@gm...> - 2011-10-24 23:39:05
|
Hi,
Here is I propose another branch that I'd like to see merged for the
next java-gnome release. The branch is located at:
hackers/guillaume/gtk-switch
From the branch location you probably understand that it covers the
GtkSwitch widget that was introduce with GTK+ 3. That's a pretty simple
branch, I just had to play with some C functions to be able to emit and
catch a signal when the user plays with the Switch.
Any feedbacks are welcome (as usual).
Cheers,
--
Guillaume Mazoyer
|
|
From: Andrew C. <an...@op...> - 2011-10-24 06:34:16
|
When you're working in C, please check the return value of every JNI
function,
+ _array = (*env)->NewObjectArray(env, size, stringCls, NULL);
+
+ if ((*env)->ExceptionCheck(env)) {
+ (*env)->ExceptionDescribe(env);
+ g_printerr("Unable to create array?");
+ }
and meanwhile, if there's an exception pending, just return from the
function; Java will do the right thing once control returns to the JVM.
AfC
Sydney
|
34 messages has been excluded from this view by a project administrator.
