Thread: [java-gnome-hackers] GApplication and GtkApplication coverage
Brought to you by:
afcowie
From: Guillaume M. <res...@gm...> - 2011-12-05 23:08:27
Attachments:
signature.asc
|
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-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...> - 2012-01-02 23:36:32
Attachments:
signature.asc
|
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...> - 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-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: 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-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 23:57:22
Attachments:
signature.asc
|
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 |