java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 5)
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: Philipp H. <phi...@gm...> - 2011-06-01 00:52:57
|
Hello again, I sort of implemented the changes I suggested in the post from earlier. It allows to optionally compile the library with different modules. Please try it and let me know what you think: $ bzr co --lightweight lp:~binwiederhier/java-gnome/modules java-gnome-modules $ cd java-gnome-modules $ ./configure --with-module=appindicator-0.1 $ make $ ldd tmp/*.so --> Appindicator included Changes I made: - moved the directory "src/defs" to "src/defs/core" - moved the directory "src/bindings" to "src/bindings/core" - added one directory for each module: 1. "src/defs/appindicator-0.1" and "src/bindings/appindicator-0.1" 2. "src/defs/indicate-gtk" and "src/bindings/indicate-gtk" (*** see below) - adjusted all scripts (mainly configure, faster, Makefile and BindingsGenerator) to support more than one "defs" and "bindings" folder Note: when you recompile, make sure to delete the tmp-folder since it might contain "modules" that are not defined in the --with-module thing arguments anymore. "make clean" is not enough here. What do you think? It's not a dynamic loader, but it's a start and it doesn't break the old stuff... Cheers, Philipp *** On Natty, use 'indicate-gtk-0.5' instead. It didn't compile for me though. I think because of the major version jump ... On Tue, May 31, 2011 at 10:40 PM, Philipp Heckel <phi...@gm...> wrote: > Hallo everyone, > > First of all: thank you for a great library. I wouldn't know what to > do without it :-) > > I am referring to the issue of "optional dependencies" discussed in > [1]: I can definitely understand the discussed problems: many > developers probably only use a fraction of the built-in functionality. > Reducing dependencies and having optional dependencies is certainly a > must in big projects like this. However, in my opinion, an issue like > this should not stand in the way of making progress and including new > functionalities: Francisco implemented support for App Indicators over > a year ago [2] and even though is works like a charm, it is still not > in the library. > > In the long run, I would love a dynamic loader that only allows the > use of classes for which the native libraries are available. For > example, if libappindicate is present, an application may use the > corresponding Java classes. If not, an exception is thrown. > > However, to avoid getting stuck in an endless discussion about how to > implement this, I'd suggest to adjust the configure script to allow > choosing libraries at build-time. This is exactly what Serkan > suggested (2011-05-05 07:17). Something like: ./configure > --with-module=libappindicator > > That way, if the "default version" in the distros' repositories is not > built with the desired functionality, one could check out the source > of the current stable version (4.0.19) and simply re-compile it > --with-module=... > > What do you think of that? > > Cheers > Philipp > > [1] https://sourceforge.net/mailarchive/message.php?msg_id=27435400 > [2] https://sourceforge.net/mailarchive/message.php?msg_id=25397649 > |
From: Philipp H. <phi...@gm...> - 2011-05-31 20:40:30
|
Hallo everyone, First of all: thank you for a great library. I wouldn't know what to do without it :-) I am referring to the issue of "optional dependencies" discussed in [1]: I can definitely understand the discussed problems: many developers probably only use a fraction of the built-in functionality. Reducing dependencies and having optional dependencies is certainly a must in big projects like this. However, in my opinion, an issue like this should not stand in the way of making progress and including new functionalities: Francisco implemented support for App Indicators over a year ago [2] and even though is works like a charm, it is still not in the library. In the long run, I would love a dynamic loader that only allows the use of classes for which the native libraries are available. For example, if libappindicate is present, an application may use the corresponding Java classes. If not, an exception is thrown. However, to avoid getting stuck in an endless discussion about how to implement this, I'd suggest to adjust the configure script to allow choosing libraries at build-time. This is exactly what Serkan suggested (2011-05-05 07:17). Something like: ./configure --with-module=libappindicator That way, if the "default version" in the distros' repositories is not built with the desired functionality, one could check out the source of the current stable version (4.0.19) and simply re-compile it --with-module=... What do you think of that? Cheers Philipp [1] https://sourceforge.net/mailarchive/message.php?msg_id=27435400 [2] https://sourceforge.net/mailarchive/message.php?msg_id=25397649 |
From: Philipp H. <phi...@gm...> - 2011-05-31 19:46:47
|
Hello Guillaume, Will do. Cheers, Philipp On Tue, May 31, 2011 at 7:08 PM, Guillaume Mazoyer <res...@gm...> wrote: > Hey Philipp, >> >> I apologize if this has been asked before, but I was wondering if >> java-gnome or any other library you know will support application >> indicators in future versions? > > I'd really love to see appindicator in java-gnome someday. > Actually since the topic was mentioned I'm thinking about how to do that. > I even thought about patching the ubuntu package but it's not a good idea I > think. >> >> Francisco's patch still works very well. It could be added to >> java-gnome or a separate package. If you don't like to have it in >> java-gnome, why not create something like "libappindicator-java"? > > Because it wouldn't benefit of the great java-gnome code generator. And it > would be very painful to develop. I'd like to see optional dependencies in > java-gnome so we can depend and build appindicator bindings *only* > appindicator is on the system > Feel free to join this discussion [1] to talk about optional dependencies. > [1] http://sourceforge.net/mailarchive/message.php?msg_id=27435400 > -- > Guillaume Mazoyer - http://www.respawner.fr/ > |
From: Guillaume M. <res...@gm...> - 2011-05-31 17:08:49
|
Hey Philipp, I apologize if this has been asked before, but I was wondering if > java-gnome or any other library you know will support application > indicators in future versions? > I'd really love to see appindicator in java-gnome someday. Actually since the topic was mentioned I'm thinking about how to do that. I even thought about patching the ubuntu package but it's not a good idea I think. Francisco's patch still works very well. It could be added to > java-gnome or a separate package. If you don't like to have it in > java-gnome, why not create something like "libappindicator-java"? > Because it wouldn't benefit of the great java-gnome code generator. And it would be very painful to develop. I'd like to see optional dependencies in java-gnome so we can depend and build appindicator bindings *only* appindicator is on the system Feel free to join this discussion [1] to talk about optional dependencies. [1] http://sourceforge.net/mailarchive/message.php?msg_id=27435400 -- Guillaume Mazoyer - http://www.respawner.fr/ |
From: Philipp H. <phi...@gm...> - 2011-05-31 16:41:34
|
Hello everyone, I apologize if this has been asked before, but I was wondering if java-gnome or any other library you know will support application indicators in future versions? I read a thread from the archive [1] in which Francisco and Guillaume talked about this, but more or less came to the conclusion that this functionality should be exported to a separate binding. I was wondering if there has been any progress on this issue. Francisco's patch still works very well. It could be added to java-gnome or a separate package. If you don't like to have it in java-gnome, why not create something like "libappindicator-java"? Cheers, Philipp [1] https://sourceforge.net/mailarchive/message.php?msg_id=25397649 |
From: Vreixo F. L. <met...@ya...> - 2011-05-30 18:04:56
|
Hi! Andrew: > > Does anybody know about some negative influence of RTLD_GLOBAL? > What I wrote in my original message is just a guess - does it consume [a > lot of] memory? Or is it just a bookkeeping thing? I think (just think) that memory is not the main problem. It is that when other libraries lookup symbols, the search also includes that library, so if, for example another library defines gtk_button_new a problem will raise. But anyway, that seems a very stupid thing to do, so I doubt there is a real implication... Guillaume: > Why did you choose to do that [G_MODULE_BIND_LAZY]? Does it save memory? I guess it saves the time to resolve the symbols at load time... > This change looks good for me now but we have to improve it. > I'm guessing that it significantly impacts the library. > Are we sure this will not cause some unwanted side effects? I think it doesn't, but no, I am not sure, maybe we can try it in a development version, if a problem appears we just revert the change. Note that I know (at least I think so) how to fix this problem without the GLOBAL thing, just by creating a custom GtkBuilder, but it is a much bigger piece of code. Cheers Vreixo |
From: Guillaume M. <res...@gm...> - 2011-05-30 07:36:43
|
I'm not really familiar with all those things but I do have few questions? Moreover, note that I use G_MODULE_BIND_LAZY, which means calling dlopen() > with > RTLD_LAZY, > so the symbols are only resolved when needed, but it still works. (note > that the > default with > Why did you choose to do that? Does it save memory? This change looks good for me now but we have to improve it. I'm guessing that it significantly impacts the library. Are we sure this will not cause some unwanted side effects? -- Guillaume Mazoyer - http://www.respawner.fr/ |
From: Andrew C. <an...@op...> - 2011-05-30 06:45:22
|
On Sun, 2011-05-22 at 02:22 +0100, Vreixo Formoso Lopes wrote: > I have update Plumbing,loadNativeCode() to call g_module_open(file_name, > G_MODULE_BIND_LAZY) with file_name the path to our JNI library as computed in > loadNativeCode(). I like your work :) This is a pretty invasive change and more than just me should check it. Can anyone do so? Other than that, will merge. > Does anybody know about some negative influence of RTLD_GLOBAL? What I wrote in my original message is just a guess - does it consume [a lot of] memory? Or is it just a bookkeeping thing? AfC Sydney |
From: Vreixo F. L. <met...@ya...> - 2011-05-22 01:22:12
|
Hi again!! I was implementing the GtkBuilder subclass, but I needed a reference to the handle, so I have update Plumbing,loadNativeCode() to call g_module_open(file_name, G_MODULE_BIND_LAZY) with file_name the path to our JNI library as computed in loadNativeCode(). I do not why but I pressed run in eclipse and, it ran!!! All worked perfectly. I could not believe why, so at first I thought g_module_symbol (Glib wrapper for dlsym()) was modified to search in all loaded modules. So I looked into glib code to confirm that, but I couldn't. The code was just a call to dlsym(). The only possible explanation was that g_module_open() loaded the library with RTLD_GLOBAL, and yes, it was. Curiously, that is the default for glib: http://developer.gnome.org/glib/stable/glib-Dynamic-Loading-of-Modules.html#GModuleFlags and in fact it is the way GtkBuilder calls g_module_open. So I begin to think why I thought RTLD_GLOBAL was a bad thing and.... I now think it is not! It makes the symbols be global to the program but, anyway, in a C program where the library is loaded at program startup they also are (according to dlsym manpage). Moreover, note that I use G_MODULE_BIND_LAZY, which means calling dlopen() with RTLD_LAZY, so the symbols are only resolved when needed, but it still works. (note that the default with g_module_open is to resolve them on load with RTLD_NOW). Does anybody know about some negative influence of RTLD_GLOBAL? Unless we found a strong reason against it, I think we should add this piece of code (needs improvement, though): === modified file 'src/bindings/org/freedesktop/bindings/Plumbing.c' --- src/bindings/org/freedesktop/bindings/Plumbing.c 2010-01-06 06:41:27 +0000 +++ src/bindings/org/freedesktop/bindings/Plumbing.c 2011-05-22 01:17:20 +0000 @@ -34,6 +34,36 @@ #include <jni.h> #include "bindings_java.h" #include "org_freedesktop_bindings_Plumbing.h" +/* + * Class: org_freedesktop_bindings_Plumbing + * Method: initializeNativeModule + * Signature: (Ljava/lang/String;)V + */ +/* + * Implements + * org.freedesktop.bindings.Plumbing.initializeNativeModule(String path) + */ +JNIEXPORT void JNICALL +Java_org_freedesktop_bindings_Plumbing_initializeNativeModule +( + JNIEnv *env, + jclass cls, + jstring path +) +{ + const gchar* file_name; + + file_name = bindings_java_getString(env, path); + if (G_UNLIKELY(file_name == NULL)) { + return; // Java Exception already thrown + } + + g_module_open(file_name, G_MODULE_BIND_LAZY); + // FIXME handle error! + + bindings_java_releaseString(file_name); + +} /* * Implements === modified file 'src/bindings/org/freedesktop/bindings/Plumbing.java' --- src/bindings/org/freedesktop/bindings/Plumbing.java 2010-02-15 05:18:25 +0000 +++ src/bindings/org/freedesktop/bindings/Plumbing.java 2011-05-22 00:32:00 +0000 @@ -202,7 +202,10 @@ path = library.getPath(); System.load(path); + initializeNativeModule(path); } + + static final native void initializeNativeModule(String path); /* * Proxy handling ------------------------------------ Cheers Vreixo ----- Mensagem original ---- De: Vreixo Formoso Lopes <met...@ya...> Para: java-gnome-hackers <jav...@li...> Enviadas: Domingo, 22 de Maio de 2011 1:24:37 Assunto: [java-gnome-hackers] Res: Symol issues with GtkBuilder Hi! I think I have found the reason for this problem. GtkBuilder UI files are XML files where the UI widgets are defined by their name. So, if you have a Button in your GUI, it will exist a node in the file like <object class="GtkButton" .... So, the object type is defined by its class name. Internally, GtkBuilder will read that file and translate those names to the given GType. That is done by means of the function xxx_get_type, that is, gtk_button_get_type in this case. To locate this function, dlsym() is used. To understand how this dlsym locates functions, let me refer to "man dlsym": "... When given to dlsym(), this handle causes a search for a sym‐ bol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL..." The handle is the return value of dlopen(). When dlopen() is called with a NULL filename, it returns a handler to the main program. And that is what GtkBuilder does to get the handler. From gtkbuilder.c, _gtk_builder_resolve_type_lazily(): module = g_module_open (NULL, 0); (that NULL is the filename argument that is finally passed to dlopen()). And that is the reason of why java-gnome fails and a C program does not. A C program is a binary linked against libgtk, so when dlsym is called, it tries to locate the symbol (for example, gtk_button_get_type) in the program binary, and the in all shared libraries loaded at program startup. Libgtk is one of them, so the symbol is properly found. However, in a java-gnome program, the binary is the /usr/bin/java (or whatever it links to) binary, and it is not linked against libgtk. So it fails. One solution is what Andrew has said: to load the library (well, all the libraries that define a widget) with the flag RTLD_GLOBAL. Pretty ugly. But I think there is another solution. Again from "man dlink()": "External references in the library are resolved using the libraries in that library's dependency list and any other libraries previously opened with the RTLD_GLOBAL flag." So, if I understand things right, what we need is to replace gtkbuilder _gtk_builder_resolve_type_lazily() with a implementation where in module = g_module_open (NULL, 0); the NULL is replaced with the native library name. I will try to implement this fix and see what happens. Cheers Vreixo ----- Mensagem original ---- De: Andrew Cowie <an...@op...> Para: java-gnome-hackers <jav...@li...> Enviadas: Sexta-feira, 8 de Abril de 2011 5:46:35 Assunto: [java-gnome-hackers] Symol issues with GtkBuilder I had a shot at implementing GtkBuilder support in java-gnome. The public API was easy and was done in a flash. But it doesn't work. Exception in thread "main" java.text.ParseException: Invalid object type `GtkLabel' at org.gnome.gtk.Builder.addFromFile(Builder.java:107) at Designer.setupUserInterface(Designer.java:46) at Designer.main(Designer.java:80) Invalid object type? huh? ++ I have copied in the logs of a long conversation I had on #gtk+ today with Tristan van Berkom, Benjamin Otte, and Johan Dahlin. I'd ask you to read through it. The end result appears to be that because java-gnome reaches GTK via a shared library and not by virtue of being an executable itself, GtkBuilder won't work as is. There are two options: 1) implement a vFunc (by C side subclassing GtkBuilder, I think) to do ... something 2) manually call dlopen() with RTLD_GLOBAL which does ... something The fact that I was able to hack (2) to work is not interesting. What's the cost of it? I assume switching it to global would mean an insane growth in the runtime size of the symbol table. Is that bad? I assume so. How do we measure it? No idea. Also, if we did (2) then we'd have to manually list every system library name in C code. That's fragile, to say the least. On the other hand, it's not like our symbol table isn't huge already care of JNIEXPORT [which is the reason to investigate JNI's RegisterNatives, but that's another story]. But this wouldn't read-only sharable data space in a .so, right? We want to shrink our memory footprint, not grow it! Johan said that the vFunc was just for this sort of occasion. Ok, so presumably (1) is the better thing to do, but can anyone figure out from this conversation what, exactly, we're supposed to do there? My branch is at 'hackers/andrew/builder'. It's a 4.0 branch. With the patch below it "works", but we can't use that patch as is. Slightly edited IRC log follows. As you'll read, on quite a number of occasions I point out that I really don't know enough about linking to be able to properly assess what is (or isn't) going on. Thanks to Tristan, Benjamin, and Johan for their help getting us this far! Now, my friendly little java-gnome hackers, I need yours... AfC Sydney ++ AfC: Hm. I wonder why GtkBuilder would emit "Invalid object type `GtkLabel'" when parsing a .ui file? Company: AfC: not yet called gtk_init() or so? Company: AfC: the gtk_label_get_type() function must have been called once for the type to be registered AfC: Company: no, gtk_init() etc called already AfC: Company: er AfC: what? AfC: you're kidding. Company: no, i'm not Company: but i'm pretty sure there is some function that does that AfC: You mean someone has to manually call gtk_label_new() and gtk_foobar_new() and gtk_everything_else_new() before they can use GtkBuilder? Company: AfC: no tristan: AfC, you you doing this in C ? Company: AfC: i mean someone has to call gtk_label_get_type() tristan: AfC, there is a function that creates "gtk_label_get_type" from "GtkLabel" AfC: tristan: no, I'm finally getting around to porting our libglade coverage in java-gnome to GtkBuilder instead. It was easy enough, except that I've hit this tristan: it's used along with g_module_symbol() to initialize types Company: ahhh Company: more magical than i'd have thought tristan: AfC, I suspect... not sure... but suspect that the binding has problems getting the type from name AfC: bloody hell. Do you have any idea how much we have *not* exposed the _get_type() functions? They're meaningless in a language binding. tristan: I think bindings are supposed to override that part of the builder tristan: I mean... do you want builder to create a raw GtkLabel ? or do you want it to create some java-gnome wrapper object ? tristan: I suspect that in gtkmm they have some derived code that returns a wrapper ***tristan checks with builder how thats done for bindings... I dont recall Company: i'd expect you let the builder create the label tristan: AfC, GtkBuilderClass.get_type_from_name() Company: and then wrap it AfC: tristan: the proxy object (to use Owen's terminology) is already fully engineered, that works fine [and worked fine with libglade]. AfC: tristan: we're stuck at add_from_file tristan: Company, you would expect that to be done where then ? Company: tristan: in get_object() AfC: Company: that's what I'd expect, and that's what we're doing tristan: AfC, I dont know how it worked fine in the past and how it worked with libglade. AfC: Company: we're not even at get_object() yet. Given any pointer we can ... call g_type_name() on ... we can construct our proxy, no problem Company: AfC: as tristan says, that's not enough AfC: Company: but I can't understand why gtk_builder_add_from_file() can't hack it when glade_xml_parse() managed it AfC: Well. tristan: different languages seem to have totally different binding sets tristan: for instance, I'm not sure that when you create a derived widget with gtkmm, that it even registers a GType for the new class tristan: when you create an object with python... it makes a GType tristan: so they are bidirectional tristan: in a sense Company: AfC: glade called all gtk get_type() functions afair Company: AfC: was always tricky when gtk added new widgets and libglade hadn't been updated yet tristan: Company, would it be enough to do it in get_object() ? tristan: if I go and fetch a window or box... and then itterate it's children AfC: tristan: no we don't do anything like that. Never needed to. As far as C is concerned it's just a GtkWhatever. If the developer has created a Java side subclass that's their business. Things Just Work™. But that's not the problem here tristan: do I get widgets as children or wrappers ? Company: tristan: you get wrappers AfC: Company: ... called all gtk_get_type_ functions. Oh. Yes, well, that'd do it Company: AfC: so why does gtkbuilder not find the existing C function gtk_label_get_type() when trying to g_module_symbol() it? tristan: AfC, they *kindof* work then... if you cannot get the derived class details in GType terms in C... then ... it's impossible for me to make a useful java-gnome plugin for Glade Company: AfC: in java-gnome i mean AfC: Company: hm? tristan: because I cannot read any properties or signals that the java-gnome object may have added AfC: Company: Code is like this: AfC: Gtk.init() AfC: builder = new Builder(); AfC: builder.addFromFile("simple.ui"); AfC: crash AfC: (well, GError → Exception → terminate) Company: AfC: yes, because java-gnome is doing bad things Company: AfC: because g_module_symbol(null_module, "gtk_label_get_type") fails Company: AfC: and that's java-gnome's fault somehow AfC: Company: sorry, what is that? Company: AfC: that is C AfC: Company: look I know you guys don't give a shit about language bindings, but maybe we can leave off the "fault" stuff and assume that the project means well, and has done what was asked of it over the years? AfC: So if there's a new initialization pattern that needs to be supported, fine Company: AfC: there isn't Company: AfC: there's just a new way to look up class names Company: AfC: and it's done by inspecting the running code for an exported C function AfC: Company: so you're saying we instantiated the GtkBuilder object somehow wrong? tristan: AfC, I do give a shit, and I also wish I could introspect more from language-binding created classes... I dont see exactly what could be going wrong AfC: tristan: no, me neither; tristan: if your code is running with libgtk+, then "gtk_label_get_type" MUST be there tristan: no reason for the C code calling g_module_symbol to fail. AfC: tristan: what I wrote above is == to this C code, right? Company: AfC: no, i'm saying that a java-gnome application looks different to C code than a C application AfC: gtk_init() AfC: gtk_builder_new() AfC: gtk_builder_add_from_file() tristan: AfC, yes that should really definitely work AfC: well, that's the sequence of C calls we're making. :( Company: AfC: no, deep down it's not Company: AfC: are you linking your java app with gcc? Company: AfC: is it doing the equivalent of gcc -shared -lgtk-3 ? AfC: Company: This is GTK 2, but yes AfC: LINK=/usr/bin/gcc-4.4 -shared + pkg-config --libs tristan: right, I suppose there could be low-level trickery, that some obscure calls to ldd/nm might reveal Company: AfC: so if you run ldd on the generated binary, it will list libgtk just like when running it on /usr/bin/gtk-demo ? AfC: Company: there's no binary. There's a shared library loaded at runtime, but I will double check Company: AfC: aha! tristan: i.e. what is the actual symbol name... but if it's linking to a real libgtk+ lib... I still dont see why there would be no "T gtk_label_get_type" in there Company: AfC: shared libraries loaded at runtime may be loaded with hidden symbols Company: AfC: so that g_module_symbol() would not find the symbol AfC: Company: um, ok, that's interesting AfC: notes that the rest of the GNOME stack works fine, and has for 9 years Company: yes tristan: if it obfuscates the symbol name or such, you can reverse the process by implementing GtkBuilderClass.get_type_from_name() Company: the rest of the gnome stack doesn't have to resolve C symbols at runtime AfC: if [what] obfuscates? AfC: This is very interesting tristan: whatever obscure linking method you might use Company: tristan: it's dlopen()ing libgtk with RTLD_LOCAL AfC: Um, well, it's doing whatever pkg-config tells it to do tristan: Company, that means you can find nothing in the global namespace ? Company: tristan: actually, it's not dlopen()ing libgtk but libjava-gnome-plugin.so Company: tristan: yes AfC: yes AfC: (where it is the Java VM process, yes) tristan: right, so "whoever" is dlopening it.. has access to those symbols, there is a handle somewhere tristan: that handle needs to be used in GtkBuilder->get_type_from_name() tristan: to get the actual type AfC: tristan, Company: thanks for your help. I'll be honest and say I don't really understand what needs to be done; AfC: tristan, Company: sounds like its not a matter of a different linker flag but I certainly don't have access to the dlopen call being made by the VM [nor would any language binding, I imagine] AfC: tristan, Company: unless it's $something I can do before calling [say] gtk_init() Company: AfC: i'd suspect python or other languages have the same problem Company: JS, whatever tristan: AfC, short answer/explanation is that a language binding needs to know how to get the actual GType from a type name before the type is actually registered Company: unless they don't use RTLD_LOCAL Company: AfC: and as tristan says, you can overwrite the lookup function AfC: [I don't know that the JVM is, fwiw] tristan: python works find with GtkBuilder, they create real GObjects afaik also AfC: tristan: isn't that circular? g_type_from_name() only works after a type has been registered, right? AfC: Hey, if someone can point us at the call that eg Python is making before they call gtk_init() that magically fixes the problem, then I'll get it added right away. tristan: AfC, no it's not circular, I said a binding needs to make that association *before* the type is registered AfC: tristan: ah AfC: tristan: well as it happens we do have such a list tristan: it's simple: GTK+ provides standard naming convention, and all the _get_type() stubs are there tristan: just have to mash up the string a bit and use the _get_type() to create it AfC: tristan: so you're saying we have to invoke every _get_type() possible before attempting to use GtkBuilder. tristan: GTK+ already does the string mashing part, you can copy that code pretty easily tristan: AfC, no... you have to call _get_type() as a result of GtkBuilder->get_type_from_name() tristan: in your language binding's wrapper of GtkBuilder... you override the ->get_type_from_name() vfunc tristan: and make it do something language binding custom AfC: this is where I'm lost. There's nothing custom AfC: we just have a GtkBuilder* tristan: AfC, that was an ugly issue with libglade... you actually had to register each type to use them tristan: so a.) libglade needed updates for new types... and b.) applications needed to provide modules to load their own custom types tristan: AfC, you use GtkBuilder directly from java ?? tristan: or you have something in between, right ? tristan: the in between should use CustomBuilder instead of GtkBuilder directly tristan: with ->get_type_from_name() overridden AfC: We're verging off-topic for #gtk+ and I don't want to further clutter up the channel when important bug fixing is going on. AfC: tristan: I was hoping to have GtkBuilder coverage in our 4.1 release to replace the removed libglade, but it sounds like we'll have to dig a bit harder. AfC: appreciate your help tristan: I'll be around, sorry to walk out on you AfC: tristan: nah, that's cool (12:19:43) jdahlin: AfC: libglade has a huge table which maps widget name to GType, we wanted to avoid that when rewriting libglade into GtkBuilder AfC: jdahlin: I see jdahlin: and as Company pointed out, that caused problems when a new widget was added in gtk+ but not in that table AfC: jdahlin: sure, I grok that jdahlin: so dlsym(NULL, "gtk_widget_get_type") needs to work, not sure why that isn't working for java-gnome AfC: jdahlin: yeah. I don't really understand why a shared linking to GTK is different than an executable linking to GTK [with respect to however this works in a normal C GTK program] (which is Company's hypothesis) jdahlin: AfC: executable linking is done at compile time, while dlopen/dlsym is runtime jdahlin: AfC: GtkBuilder creates a bit of problem for C programs as well, it uses dlsym to find out callbacks specific in the .ui file jdahlin: so for C programs you need to link with -rdynamic jdahlin: is java-gnome using jna or jni? AfC: jdahlin: JNI tristan|afk: jdahlin, I think he means that... java-gnome being a shared lib is linking to GTK+... I *think*... that the java-gnome lib is dlopened by whatever is running this AfC: tristan|afk: that's correct jdahlin: AfC: the main executable is the jvm (/usr/bin/java or whatever), it loads in libjava-gnome.so via dlopen AfC: So if there's something I have to add to the linker invocation to build the .so, no problem jdahlin: for GtkBuilder to work you have to make all *_get_type symbols accessible in the main namespace for jvm jdahlin: that's usually accomplished by passing in RTLD_GLOBAL to dlopen tristan|afk: if I'm guessing Company's hypothesis right... maybe what is opening java-gnome is doing so without making the symbols global tristan|afk: so when that code actually ends up running dlsym() with NULL... it finds nothing jdahlin: how is libjava-gnome.so linked against libgtk.so? tristan|afk: jdahlin, or... it can be done by overriding ->get_type_from_name() inside java-gnome... I think, no ? AfC: If so, that's going to be hard to beat, because I have zero control over that. The only workaround would be to cause the VM process to load a *separate* library first, and call dlopen() on libgtk-x11-2.0.so.0 jdahlin: tristan|afk: that would work as well AfC: jdahlin: well, let's see jdahlin: AfC: do you know how the VM loads JNI modules? AfC: jdahlin: no AfC: jdahlin: more to the point, I have zero influence over it. AfC: I mean, it's gotta be dlopen() and dlsym(), but with what flags? No idea AfC: jdahlin: LINK=/usr/bin/gcc-4.4 -g -shared -Wall -fPIC AfC: and AfC: jdahlin: $LINK -o tmp/libgtkjni-4.0.20-dev.so $objects `pkg-config --libs $modules` AfC: [sic] jdahlin: okay, you could fix it up yourself, either by overriding get_type_from_name as tristan mentioned or just doing something like dlopen("libgtk.so", RTLD_GLOBAL) in JNI's module initialization function AfC: jdahlin: I can certainly do that. AfC: That's what suggested to Company AfC: though I wasn't sure if that would do anything if invoked from a .so that is already linked against libgtk-x11-2.0.so.0 jdahlin: it's a bit ugly using RTLD_GLOBAL though, you're polluting the namespaces jdahlin: it'll hopefully do the right thing jdahlin: the same needs to be done for all shared libraries with *_get_type functions that java-gnome wants to support, it's not just gtk jdahlin: but gtk+ is arguable the most important one AfC: As for "a bit ugly", that's what I'm blown away by all this. I've tried to follow this conversation, but fundamentally I just don't understand why it works for a C program [without "polluting"] and not a .so AfC: anyway, trying my best jdahlin: AfC: because of a number of reasons, a C program is linked at compile time and all the functions its using are known jdahlin: eg, it knows that gtk_label_get_type() is going to be used, but not gtk_button_get_type() etc jdahlin: you can check which functions are linked in by running ldd on the executable jdahlin: now, dynamic languages uses dlopen() which can specific, make all functions available or none at all jdahlin: the JNI authors decided the latter should be the default for some reason, and it doesn't seem (by 2 minutes googling) that it's possible to change that AfC: [ldd + executable = functions? What option is that?] jdahlin: or if it's objdump/nm, haven't looked at it for a while jdahlin: objdump -T executable seems to do it here on my system AfC: ah AfC: Well AfC: I added this before the call to gtk_init(): === modified file 'src/bindings/org/gnome/gtk/GtkMain.c' --- src/bindings/org/gnome/gtk/GtkMain.c 2010-02-14 20:14:38 +0000 +++ src/bindings/org/gnome/gtk/GtkMain.c 2011-04-08 02:51:05 +0000 @@ -31,6 +31,7 @@ * wish to do so, delete this exception statement from your version. */ +#include <dlfcn.h> #include <jni.h> #include <glib.h> #include <gdk/gdk.h> @@ -56,6 +57,7 @@ jobjectArray _args ) { + void* handle; int argc; char** argv; gint i; @@ -90,6 +92,12 @@ argv[0] = ""; argc++; + handle = dlopen("libgtk-x11-2.0.so", RTLD_NOW | RTLD_GLOBAL); + if (handle == NULL) { + bindings_java_throw(env, "dlopen() failed: %s", dlerror()); + return; + } + // call function gtk_init(&argc, &argv); AfC: and now GtkBuilder works jdahlin: great AfC: yeah. But is it great? :) jdahlin: great that it's working AfC: Certainly lends strength to Company's hypothesis, that's for sure jdahlin: is it inconvenient for you to override the GtkBuilder vfunc get_type_from_name? AfC: jdahlin: "no", but I'm not sure what I'd be overriding it with? jdahlin: AfC: implementing it! jdahlin: you need to subclass it and override it AfC: "This is mainly used when implementing the GtkBuildable interface on a type." jdahlin: sure, but we're outside of "mainly" right now jdahlin: I added it specifically for these kind of situations jdahlin: s/added/made it overridable/ jdahlin: gtkmm uses it as well if iirc AfC: Oh? Ok. I should go look at their code, then jdahlin: not really jdahlin: all gtkmm classes are subclasses, and they implement it to map GtkLabel to their overridden GType jdahlin: http://git.gnome.org/browse/gtkmm/tree/gtk/src/builder.ccg AfC: jdahlin: yeah, I'm reading that right now AfC: All they do is call g_type_from_name() ? jdahlin: gtkmm is considerably different from a dynamic binding, so you shouldn't worry too much AfC: um generally we're mostly the same; Java is a static language too jdahlin: no, it's not really static AfC: [except for this business of getting to GTK through a .so rather than a linked executable] jdahlin: in the sense that language bindings are loaded via dynamically AfC: Sure. I means static as in static language API, not a dynamic language API AfC: So I assume that GtkBuilder just calls g_type_from_name() itself internally. jdahlin: not really no jdahlin: but it works fine for gtkmm which calls all get_type functions when the library loads AfC: Ah AfC: No, we definitely don't do that. :) AfC: We could, I guess. Sounds expensive. jdahlin: maybe it doesn't, but their impl. requires you to call the _get_type function of a class before using it in gtkbuilder AfC: which is why g_type_from_name() works AfC: right AfC: hm AfC: Embedding system library names in the source code to pass to dlopen() is going to be fragile. AfC: I wondered if -rdynamic to the linker would have the same effect, but no jdahlin: kind of fragile yes, but the alternatives are wors jdahlin: e AfC: jdahlin: that seems pretty nuts of GTKmm; if I do get_object() on something I think is be a GtkButton and it turns out to be a GtkCheckButton (say) it'll crash AfC: [actually, it won't get past add_from_file() which is my problem right now] jdahlin: dunno about the details, you need to check with the gtkmm authors if you really want to know AfC: jdahlin: yeah, I'll talk to Murray next time I see him ***jdahlin -> zzz AfC: jdahlin: do you have an opinion about the "expense" of dlopen(... , | RTLD_GLOBAL)? AfC: jdahlin: ah, g'night. Thanks for your help ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Vreixo F. L. <met...@ya...> - 2011-05-21 23:24:46
|
Hi! I think I have found the reason for this problem. GtkBuilder UI files are XML files where the UI widgets are defined by their name. So, if you have a Button in your GUI, it will exist a node in the file like <object class="GtkButton" .... So, the object type is defined by its class name. Internally, GtkBuilder will read that file and translate those names to the given GType. That is done by means of the function xxx_get_type, that is, gtk_button_get_type in this case. To locate this function, dlsym() is used. To understand how this dlsym locates functions, let me refer to "man dlsym": "... When given to dlsym(), this handle causes a search for a sym‐ bol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL..." The handle is the return value of dlopen(). When dlopen() is called with a NULL filename, it returns a handler to the main program. And that is what GtkBuilder does to get the handler. From gtkbuilder.c, _gtk_builder_resolve_type_lazily(): module = g_module_open (NULL, 0); (that NULL is the filename argument that is finally passed to dlopen()). And that is the reason of why java-gnome fails and a C program does not. A C program is a binary linked against libgtk, so when dlsym is called, it tries to locate the symbol (for example, gtk_button_get_type) in the program binary, and the in all shared libraries loaded at program startup. Libgtk is one of them, so the symbol is properly found. However, in a java-gnome program, the binary is the /usr/bin/java (or whatever it links to) binary, and it is not linked against libgtk. So it fails. One solution is what Andrew has said: to load the library (well, all the libraries that define a widget) with the flag RTLD_GLOBAL. Pretty ugly. But I think there is another solution. Again from "man dlink()": "External references in the library are resolved using the libraries in that library's dependency list and any other libraries previously opened with the RTLD_GLOBAL flag." So, if I understand things right, what we need is to replace gtkbuilder _gtk_builder_resolve_type_lazily() with a implementation where in module = g_module_open (NULL, 0); the NULL is replaced with the native library name. I will try to implement this fix and see what happens. Cheers Vreixo ----- Mensagem original ---- De: Andrew Cowie <an...@op...> Para: java-gnome-hackers <jav...@li...> Enviadas: Sexta-feira, 8 de Abril de 2011 5:46:35 Assunto: [java-gnome-hackers] Symol issues with GtkBuilder I had a shot at implementing GtkBuilder support in java-gnome. The public API was easy and was done in a flash. But it doesn't work. Exception in thread "main" java.text.ParseException: Invalid object type `GtkLabel' at org.gnome.gtk.Builder.addFromFile(Builder.java:107) at Designer.setupUserInterface(Designer.java:46) at Designer.main(Designer.java:80) Invalid object type? huh? ++ I have copied in the logs of a long conversation I had on #gtk+ today with Tristan van Berkom, Benjamin Otte, and Johan Dahlin. I'd ask you to read through it. The end result appears to be that because java-gnome reaches GTK via a shared library and not by virtue of being an executable itself, GtkBuilder won't work as is. There are two options: 1) implement a vFunc (by C side subclassing GtkBuilder, I think) to do ... something 2) manually call dlopen() with RTLD_GLOBAL which does ... something The fact that I was able to hack (2) to work is not interesting. What's the cost of it? I assume switching it to global would mean an insane growth in the runtime size of the symbol table. Is that bad? I assume so. How do we measure it? No idea. Also, if we did (2) then we'd have to manually list every system library name in C code. That's fragile, to say the least. On the other hand, it's not like our symbol table isn't huge already care of JNIEXPORT [which is the reason to investigate JNI's RegisterNatives, but that's another story]. But this wouldn't read-only sharable data space in a .so, right? We want to shrink our memory footprint, not grow it! Johan said that the vFunc was just for this sort of occasion. Ok, so presumably (1) is the better thing to do, but can anyone figure out from this conversation what, exactly, we're supposed to do there? My branch is at 'hackers/andrew/builder'. It's a 4.0 branch. With the patch below it "works", but we can't use that patch as is. Slightly edited IRC log follows. As you'll read, on quite a number of occasions I point out that I really don't know enough about linking to be able to properly assess what is (or isn't) going on. Thanks to Tristan, Benjamin, and Johan for their help getting us this far! Now, my friendly little java-gnome hackers, I need yours... AfC Sydney ++ AfC: Hm. I wonder why GtkBuilder would emit "Invalid object type `GtkLabel'" when parsing a .ui file? Company: AfC: not yet called gtk_init() or so? Company: AfC: the gtk_label_get_type() function must have been called once for the type to be registered AfC: Company: no, gtk_init() etc called already AfC: Company: er AfC: what? AfC: you're kidding. Company: no, i'm not Company: but i'm pretty sure there is some function that does that AfC: You mean someone has to manually call gtk_label_new() and gtk_foobar_new() and gtk_everything_else_new() before they can use GtkBuilder? Company: AfC: no tristan: AfC, you you doing this in C ? Company: AfC: i mean someone has to call gtk_label_get_type() tristan: AfC, there is a function that creates "gtk_label_get_type" from "GtkLabel" AfC: tristan: no, I'm finally getting around to porting our libglade coverage in java-gnome to GtkBuilder instead. It was easy enough, except that I've hit this tristan: it's used along with g_module_symbol() to initialize types Company: ahhh Company: more magical than i'd have thought tristan: AfC, I suspect... not sure... but suspect that the binding has problems getting the type from name AfC: bloody hell. Do you have any idea how much we have *not* exposed the _get_type() functions? They're meaningless in a language binding. tristan: I think bindings are supposed to override that part of the builder tristan: I mean... do you want builder to create a raw GtkLabel ? or do you want it to create some java-gnome wrapper object ? tristan: I suspect that in gtkmm they have some derived code that returns a wrapper ***tristan checks with builder how thats done for bindings... I dont recall Company: i'd expect you let the builder create the label tristan: AfC, GtkBuilderClass.get_type_from_name() Company: and then wrap it AfC: tristan: the proxy object (to use Owen's terminology) is already fully engineered, that works fine [and worked fine with libglade]. AfC: tristan: we're stuck at add_from_file tristan: Company, you would expect that to be done where then ? Company: tristan: in get_object() AfC: Company: that's what I'd expect, and that's what we're doing tristan: AfC, I dont know how it worked fine in the past and how it worked with libglade. AfC: Company: we're not even at get_object() yet. Given any pointer we can ... call g_type_name() on ... we can construct our proxy, no problem Company: AfC: as tristan says, that's not enough AfC: Company: but I can't understand why gtk_builder_add_from_file() can't hack it when glade_xml_parse() managed it AfC: Well. tristan: different languages seem to have totally different binding sets tristan: for instance, I'm not sure that when you create a derived widget with gtkmm, that it even registers a GType for the new class tristan: when you create an object with python... it makes a GType tristan: so they are bidirectional tristan: in a sense Company: AfC: glade called all gtk get_type() functions afair Company: AfC: was always tricky when gtk added new widgets and libglade hadn't been updated yet tristan: Company, would it be enough to do it in get_object() ? tristan: if I go and fetch a window or box... and then itterate it's children AfC: tristan: no we don't do anything like that. Never needed to. As far as C is concerned it's just a GtkWhatever. If the developer has created a Java side subclass that's their business. Things Just Work™. But that's not the problem here tristan: do I get widgets as children or wrappers ? Company: tristan: you get wrappers AfC: Company: ... called all gtk_get_type_ functions. Oh. Yes, well, that'd do it Company: AfC: so why does gtkbuilder not find the existing C function gtk_label_get_type() when trying to g_module_symbol() it? tristan: AfC, they *kindof* work then... if you cannot get the derived class details in GType terms in C... then ... it's impossible for me to make a useful java-gnome plugin for Glade Company: AfC: in java-gnome i mean AfC: Company: hm? tristan: because I cannot read any properties or signals that the java-gnome object may have added AfC: Company: Code is like this: AfC: Gtk.init() AfC: builder = new Builder(); AfC: builder.addFromFile("simple.ui"); AfC: crash AfC: (well, GError → Exception → terminate) Company: AfC: yes, because java-gnome is doing bad things Company: AfC: because g_module_symbol(null_module, "gtk_label_get_type") fails Company: AfC: and that's java-gnome's fault somehow AfC: Company: sorry, what is that? Company: AfC: that is C AfC: Company: look I know you guys don't give a shit about language bindings, but maybe we can leave off the "fault" stuff and assume that the project means well, and has done what was asked of it over the years? AfC: So if there's a new initialization pattern that needs to be supported, fine Company: AfC: there isn't Company: AfC: there's just a new way to look up class names Company: AfC: and it's done by inspecting the running code for an exported C function AfC: Company: so you're saying we instantiated the GtkBuilder object somehow wrong? tristan: AfC, I do give a shit, and I also wish I could introspect more from language-binding created classes... I dont see exactly what could be going wrong AfC: tristan: no, me neither; tristan: if your code is running with libgtk+, then "gtk_label_get_type" MUST be there tristan: no reason for the C code calling g_module_symbol to fail. AfC: tristan: what I wrote above is == to this C code, right? Company: AfC: no, i'm saying that a java-gnome application looks different to C code than a C application AfC: gtk_init() AfC: gtk_builder_new() AfC: gtk_builder_add_from_file() tristan: AfC, yes that should really definitely work AfC: well, that's the sequence of C calls we're making. :( Company: AfC: no, deep down it's not Company: AfC: are you linking your java app with gcc? Company: AfC: is it doing the equivalent of gcc -shared -lgtk-3 ? AfC: Company: This is GTK 2, but yes AfC: LINK=/usr/bin/gcc-4.4 -shared + pkg-config --libs tristan: right, I suppose there could be low-level trickery, that some obscure calls to ldd/nm might reveal Company: AfC: so if you run ldd on the generated binary, it will list libgtk just like when running it on /usr/bin/gtk-demo ? AfC: Company: there's no binary. There's a shared library loaded at runtime, but I will double check Company: AfC: aha! tristan: i.e. what is the actual symbol name... but if it's linking to a real libgtk+ lib... I still dont see why there would be no "T gtk_label_get_type" in there Company: AfC: shared libraries loaded at runtime may be loaded with hidden symbols Company: AfC: so that g_module_symbol() would not find the symbol AfC: Company: um, ok, that's interesting AfC: notes that the rest of the GNOME stack works fine, and has for 9 years Company: yes tristan: if it obfuscates the symbol name or such, you can reverse the process by implementing GtkBuilderClass.get_type_from_name() Company: the rest of the gnome stack doesn't have to resolve C symbols at runtime AfC: if [what] obfuscates? AfC: This is very interesting tristan: whatever obscure linking method you might use Company: tristan: it's dlopen()ing libgtk with RTLD_LOCAL AfC: Um, well, it's doing whatever pkg-config tells it to do tristan: Company, that means you can find nothing in the global namespace ? Company: tristan: actually, it's not dlopen()ing libgtk but libjava-gnome-plugin.so Company: tristan: yes AfC: yes AfC: (where it is the Java VM process, yes) tristan: right, so "whoever" is dlopening it.. has access to those symbols, there is a handle somewhere tristan: that handle needs to be used in GtkBuilder->get_type_from_name() tristan: to get the actual type AfC: tristan, Company: thanks for your help. I'll be honest and say I don't really understand what needs to be done; AfC: tristan, Company: sounds like its not a matter of a different linker flag but I certainly don't have access to the dlopen call being made by the VM [nor would any language binding, I imagine] AfC: tristan, Company: unless it's $something I can do before calling [say] gtk_init() Company: AfC: i'd suspect python or other languages have the same problem Company: JS, whatever tristan: AfC, short answer/explanation is that a language binding needs to know how to get the actual GType from a type name before the type is actually registered Company: unless they don't use RTLD_LOCAL Company: AfC: and as tristan says, you can overwrite the lookup function AfC: [I don't know that the JVM is, fwiw] tristan: python works find with GtkBuilder, they create real GObjects afaik also AfC: tristan: isn't that circular? g_type_from_name() only works after a type has been registered, right? AfC: Hey, if someone can point us at the call that eg Python is making before they call gtk_init() that magically fixes the problem, then I'll get it added right away. tristan: AfC, no it's not circular, I said a binding needs to make that association *before* the type is registered AfC: tristan: ah AfC: tristan: well as it happens we do have such a list tristan: it's simple: GTK+ provides standard naming convention, and all the _get_type() stubs are there tristan: just have to mash up the string a bit and use the _get_type() to create it AfC: tristan: so you're saying we have to invoke every _get_type() possible before attempting to use GtkBuilder. tristan: GTK+ already does the string mashing part, you can copy that code pretty easily tristan: AfC, no... you have to call _get_type() as a result of GtkBuilder->get_type_from_name() tristan: in your language binding's wrapper of GtkBuilder... you override the ->get_type_from_name() vfunc tristan: and make it do something language binding custom AfC: this is where I'm lost. There's nothing custom AfC: we just have a GtkBuilder* tristan: AfC, that was an ugly issue with libglade... you actually had to register each type to use them tristan: so a.) libglade needed updates for new types... and b.) applications needed to provide modules to load their own custom types tristan: AfC, you use GtkBuilder directly from java ?? tristan: or you have something in between, right ? tristan: the in between should use CustomBuilder instead of GtkBuilder directly tristan: with ->get_type_from_name() overridden AfC: We're verging off-topic for #gtk+ and I don't want to further clutter up the channel when important bug fixing is going on. AfC: tristan: I was hoping to have GtkBuilder coverage in our 4.1 release to replace the removed libglade, but it sounds like we'll have to dig a bit harder. AfC: appreciate your help tristan: I'll be around, sorry to walk out on you AfC: tristan: nah, that's cool (12:19:43) jdahlin: AfC: libglade has a huge table which maps widget name to GType, we wanted to avoid that when rewriting libglade into GtkBuilder AfC: jdahlin: I see jdahlin: and as Company pointed out, that caused problems when a new widget was added in gtk+ but not in that table AfC: jdahlin: sure, I grok that jdahlin: so dlsym(NULL, "gtk_widget_get_type") needs to work, not sure why that isn't working for java-gnome AfC: jdahlin: yeah. I don't really understand why a shared linking to GTK is different than an executable linking to GTK [with respect to however this works in a normal C GTK program] (which is Company's hypothesis) jdahlin: AfC: executable linking is done at compile time, while dlopen/dlsym is runtime jdahlin: AfC: GtkBuilder creates a bit of problem for C programs as well, it uses dlsym to find out callbacks specific in the .ui file jdahlin: so for C programs you need to link with -rdynamic jdahlin: is java-gnome using jna or jni? AfC: jdahlin: JNI tristan|afk: jdahlin, I think he means that... java-gnome being a shared lib is linking to GTK+... I *think*... that the java-gnome lib is dlopened by whatever is running this AfC: tristan|afk: that's correct jdahlin: AfC: the main executable is the jvm (/usr/bin/java or whatever), it loads in libjava-gnome.so via dlopen AfC: So if there's something I have to add to the linker invocation to build the .so, no problem jdahlin: for GtkBuilder to work you have to make all *_get_type symbols accessible in the main namespace for jvm jdahlin: that's usually accomplished by passing in RTLD_GLOBAL to dlopen tristan|afk: if I'm guessing Company's hypothesis right... maybe what is opening java-gnome is doing so without making the symbols global tristan|afk: so when that code actually ends up running dlsym() with NULL... it finds nothing jdahlin: how is libjava-gnome.so linked against libgtk.so? tristan|afk: jdahlin, or... it can be done by overriding ->get_type_from_name() inside java-gnome... I think, no ? AfC: If so, that's going to be hard to beat, because I have zero control over that. The only workaround would be to cause the VM process to load a *separate* library first, and call dlopen() on libgtk-x11-2.0.so.0 jdahlin: tristan|afk: that would work as well AfC: jdahlin: well, let's see jdahlin: AfC: do you know how the VM loads JNI modules? AfC: jdahlin: no AfC: jdahlin: more to the point, I have zero influence over it. AfC: I mean, it's gotta be dlopen() and dlsym(), but with what flags? No idea AfC: jdahlin: LINK=/usr/bin/gcc-4.4 -g -shared -Wall -fPIC AfC: and AfC: jdahlin: $LINK -o tmp/libgtkjni-4.0.20-dev.so $objects `pkg-config --libs $modules` AfC: [sic] jdahlin: okay, you could fix it up yourself, either by overriding get_type_from_name as tristan mentioned or just doing something like dlopen("libgtk.so", RTLD_GLOBAL) in JNI's module initialization function AfC: jdahlin: I can certainly do that. AfC: That's what suggested to Company AfC: though I wasn't sure if that would do anything if invoked from a .so that is already linked against libgtk-x11-2.0.so.0 jdahlin: it's a bit ugly using RTLD_GLOBAL though, you're polluting the namespaces jdahlin: it'll hopefully do the right thing jdahlin: the same needs to be done for all shared libraries with *_get_type functions that java-gnome wants to support, it's not just gtk jdahlin: but gtk+ is arguable the most important one AfC: As for "a bit ugly", that's what I'm blown away by all this. I've tried to follow this conversation, but fundamentally I just don't understand why it works for a C program [without "polluting"] and not a .so AfC: anyway, trying my best jdahlin: AfC: because of a number of reasons, a C program is linked at compile time and all the functions its using are known jdahlin: eg, it knows that gtk_label_get_type() is going to be used, but not gtk_button_get_type() etc jdahlin: you can check which functions are linked in by running ldd on the executable jdahlin: now, dynamic languages uses dlopen() which can specific, make all functions available or none at all jdahlin: the JNI authors decided the latter should be the default for some reason, and it doesn't seem (by 2 minutes googling) that it's possible to change that AfC: [ldd + executable = functions? What option is that?] jdahlin: or if it's objdump/nm, haven't looked at it for a while jdahlin: objdump -T executable seems to do it here on my system AfC: ah AfC: Well AfC: I added this before the call to gtk_init(): === modified file 'src/bindings/org/gnome/gtk/GtkMain.c' --- src/bindings/org/gnome/gtk/GtkMain.c 2010-02-14 20:14:38 +0000 +++ src/bindings/org/gnome/gtk/GtkMain.c 2011-04-08 02:51:05 +0000 @@ -31,6 +31,7 @@ * wish to do so, delete this exception statement from your version. */ +#include <dlfcn.h> #include <jni.h> #include <glib.h> #include <gdk/gdk.h> @@ -56,6 +57,7 @@ jobjectArray _args ) { + void* handle; int argc; char** argv; gint i; @@ -90,6 +92,12 @@ argv[0] = ""; argc++; + handle = dlopen("libgtk-x11-2.0.so", RTLD_NOW | RTLD_GLOBAL); + if (handle == NULL) { + bindings_java_throw(env, "dlopen() failed: %s", dlerror()); + return; + } + // call function gtk_init(&argc, &argv); AfC: and now GtkBuilder works jdahlin: great AfC: yeah. But is it great? :) jdahlin: great that it's working AfC: Certainly lends strength to Company's hypothesis, that's for sure jdahlin: is it inconvenient for you to override the GtkBuilder vfunc get_type_from_name? AfC: jdahlin: "no", but I'm not sure what I'd be overriding it with? jdahlin: AfC: implementing it! jdahlin: you need to subclass it and override it AfC: "This is mainly used when implementing the GtkBuildable interface on a type." jdahlin: sure, but we're outside of "mainly" right now jdahlin: I added it specifically for these kind of situations jdahlin: s/added/made it overridable/ jdahlin: gtkmm uses it as well if iirc AfC: Oh? Ok. I should go look at their code, then jdahlin: not really jdahlin: all gtkmm classes are subclasses, and they implement it to map GtkLabel to their overridden GType jdahlin: http://git.gnome.org/browse/gtkmm/tree/gtk/src/builder.ccg AfC: jdahlin: yeah, I'm reading that right now AfC: All they do is call g_type_from_name() ? jdahlin: gtkmm is considerably different from a dynamic binding, so you shouldn't worry too much AfC: um generally we're mostly the same; Java is a static language too jdahlin: no, it's not really static AfC: [except for this business of getting to GTK through a .so rather than a linked executable] jdahlin: in the sense that language bindings are loaded via dynamically AfC: Sure. I means static as in static language API, not a dynamic language API AfC: So I assume that GtkBuilder just calls g_type_from_name() itself internally. jdahlin: not really no jdahlin: but it works fine for gtkmm which calls all get_type functions when the library loads AfC: Ah AfC: No, we definitely don't do that. :) AfC: We could, I guess. Sounds expensive. jdahlin: maybe it doesn't, but their impl. requires you to call the _get_type function of a class before using it in gtkbuilder AfC: which is why g_type_from_name() works AfC: right AfC: hm AfC: Embedding system library names in the source code to pass to dlopen() is going to be fragile. AfC: I wondered if -rdynamic to the linker would have the same effect, but no jdahlin: kind of fragile yes, but the alternatives are wors jdahlin: e AfC: jdahlin: that seems pretty nuts of GTKmm; if I do get_object() on something I think is be a GtkButton and it turns out to be a GtkCheckButton (say) it'll crash AfC: [actually, it won't get past add_from_file() which is my problem right now] jdahlin: dunno about the details, you need to check with the gtkmm authors if you really want to know AfC: jdahlin: yeah, I'll talk to Murray next time I see him ***jdahlin -> zzz AfC: jdahlin: do you have an opinion about the "expense" of dlopen(... , | RTLD_GLOBAL)? AfC: jdahlin: ah, g'night. Thanks for your help ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Andrew C. <an...@op...> - 2011-05-08 23:08:47
|
On Sun, 2011-05-08 at 13:09 +0100, Mat Booth wrote: > There is a setting in Gnome 3 called "Have file manager handle the > desktop" which you can turn on in gnome-tweak-tool. Would that solve > the problem? I imagine it would, except that setting that would be a fairly invasive change to impose on the user's configuration - especially by a test suite! :) The only reason we tested against Nautilus was simply because it was a libunique process that we *knew* would be running, regardless. We just need to find something else. Incidentally, I remember someone looked into starting a second Java process with libnotify there. There's nothing intrinically wrong with that, but firing up additional processes from within a test suite is tricky engineering. Oh well. I suspect this whole thing is on the wrong track anyway; in a DBus + services on demand + GtkApplication world there are probably better things to test. Of course, testing GtkApplication will probably amount to the same thing, so suggestions welcome. AfC Sydney |
From: Mat B. <mb...@fe...> - 2011-05-08 12:09:47
|
On 8 May 2011 05:24, Andrew Cowie <an...@op...> wrote: > I have a system that is now Ubuntu Natty (and therefore GTK 3 available) > + GNOME 3 (from gnome 3 developers' PPA), and so I'm now able to finish > getting our 4.1 release ready. > > Our test suite has two problems: > > 1. libnotify > > Our test connects to Nautilus. This made the assumption that Nautilus is > always running, which it was on a GNOME 2 system since it draws the > Desktop. But for some time now the Ubuntu Netbook Edition users have > complained that they only have Nautilus running on-demand when they pull > up a file browser. And since Canonical's Netbook code became Unity, I > can only expect this to get worse. > > Meanwhile, it would seem based on my few days experience that GNOME 3 > behaves the same way; Nautilus only available on demand. > > So I'm going to have to deactivate > > ValidateUniqueApplications.testIsNautilusRunning() > ValidateUniqueApplications.testSendToNautilus() > There is a setting in Gnome 3 called "Have file manager handle the desktop" which you can turn on in gnome-tweak-tool. Would that solve the problem? -- Mat Booth http://fedoraproject.org/get-fedora |
From: Guillaume M. <res...@gm...> - 2011-05-08 09:31:49
|
> 1. libnotify I suppose that you mean libunique and not libnotify. > Our test connects to Nautilus. This made the assumption that Nautilus is > always running, which it was on a GNOME 2 system since it draws the > Desktop. But for some time now the Ubuntu Netbook Edition users have > complained that they only have Nautilus running on-demand when they pull > up a file browser. And since Canonical's Netbook code became Unity, I > can only expect this to get worse. I don't know about Gnome-Shell but with Unity it looks like Nautilus is still used like it was with GNOME 2 and GNOME panel. > So I'm going to have to deactivate > > ValidateUniqueApplications.testIsNautilusRunning() > ValidateUniqueApplications.testSendToNautilus() Maybe we can find another application that runs all the time and use it to replace Nautilus in our tests. What about this bug we found with Ubuntu running Unity and appmenu? https://bugzilla.gnome.org/show_bug.cgi?id=647772 Should we use the workaround to ensure that it will work for Ubuntu users? |
From: Andrew C. <an...@op...> - 2011-05-08 04:40:02
|
I have a system that is now Ubuntu Natty (and therefore GTK 3 available) + GNOME 3 (from gnome 3 developers' PPA), and so I'm now able to finish getting our 4.1 release ready. Our test suite has two problems: 1. libnotify Our test connects to Nautilus. This made the assumption that Nautilus is always running, which it was on a GNOME 2 system since it draws the Desktop. But for some time now the Ubuntu Netbook Edition users have complained that they only have Nautilus running on-demand when they pull up a file browser. And since Canonical's Netbook code became Unity, I can only expect this to get worse. Meanwhile, it would seem based on my few days experience that GNOME 3 behaves the same way; Nautilus only available on demand. So I'm going to have to deactivate ValidateUniqueApplications.testIsNautilusRunning() ValidateUniqueApplications.testSendToNautilus() 2. Compose sequences The test ValidateInputMethods.testNormalKeystrokes() is failing. This pisses me off; it works fine in GTK 2; and meanwhile, actual live Compose key handling works fine in my large text editing application. So it's not the java-gnome binding at fault, but rather something about our test case and/or Xvfb that's not working. So I'll have to deactivate this one too. ++ I'm sure most of you don't care about any of this; but removing tests to make the test suite pass is not a very good approach to problem solving. The methods have been renamed s/test/fails/ so that the test code is still there but not run. I hope that someday someone will try and make these tests work again. AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-05-05 07:17:45
|
2011/5/5 Andrew Cowie <an...@op...>: > On Sun, 2011-05-01 at 07:38 +0300, Serkan Kaba wrote: > >> Did you consider building single jar/so with the features requested in >> configure stage. That might be an option instead of cluttering >> commandline/filesystem with multiple libraries. > > It would be "easier", but it creates some problems of it's own: > > I remember Cairo on Gentoo Linux; sure it was just "cairo" but we needed > "cairo with PDF support built in" and there was no for a developer to > tell whether their Cairo had it or not. with proper USE deps we now can depend on cairo with pdf support (actually now pdf support is hardcoded in the ebuild) > > I'm still looking for someone to definitively assert either that a) > dlopen()ing multiple libraries is more expensive that having one library > that links in huge libraries that aren't being used or b) the opposite. > That might give us some guidance. > > AfC > Singapore > > > > > > > > > > >> >> - -- >> Sincerely, >> Serkan KABA >> Gentoo Developer >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.17 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk2849IACgkQRh6X64ivZaIw2wCfdyx/GU+hIknSg7602lMF2xst >> SFUAn2kaUq3I/D1DW/kUGSRp6jzGfnZH >> =dHw1 >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> java-gnome-hackers mailing list >> jav...@li... >> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers >> > > -- > Andrew Frederick Cowie > > Operational Dynamics is an operations and engineering consultancy > focusing on IT strategy, organizational architecture, systems > review, and effective procedures for change management: enabling > successful deployment of mission critical information technology in > enterprises, worldwide. > > http://www.operationaldynamics.com/ > > Sydney New York Toronto London > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > If we choose to have multiple libs we may have something similar to 2.x and split packages in distros. |
From: Andrew C. <an...@op...> - 2011-05-04 22:59:16
|
On Sun, 2011-05-01 at 07:38 +0300, Serkan Kaba wrote: > Did you consider building single jar/so with the features requested in > configure stage. That might be an option instead of cluttering > commandline/filesystem with multiple libraries. It would be "easier", but it creates some problems of it's own: I remember Cairo on Gentoo Linux; sure it was just "cairo" but we needed "cairo with PDF support built in" and there was no for a developer to tell whether their Cairo had it or not. I'm still looking for someone to definitively assert either that a) dlopen()ing multiple libraries is more expensive that having one library that links in huge libraries that aren't being used or b) the opposite. That might give us some guidance. AfC Singapore > > - -- > Sincerely, > Serkan KABA > Gentoo Developer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2849IACgkQRh6X64ivZaIw2wCfdyx/GU+hIknSg7602lMF2xst > SFUAn2kaUq3I/D1DW/kUGSRp6jzGfnZH > =dHw1 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management: enabling successful deployment of mission critical information technology in enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
From: Guillaume M. <res...@gm...> - 2011-05-01 09:48:33
|
> Something I have been musing about for a while is how we could implement > optional dependencies into java-gnome. I have been thinking about it too. > The big case that pushes this is WebKit. We'd like to include coverage > of WebKitGtk soon. But either you have it on your distro and can easily > build against it, or you don't, and it becomes a blocker against you're > being able to build java-gnome from source. I'd like to add appindicator (for Ubuntu) as an optional dependency too. The thing is that in Java we don't have #ifdef like C[++]. So we will need our build system to compile only buildable classes. We could use modules that would not be depend from each other except for a first module which would be the base for all other. -- Guillaume Mazoyer - http://www.respawner.fr/ |
From: Serkan K. <se...@ge...> - 2011-05-01 04:38:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-05-2011 05:41, Andrew Cowie wrote: > AfC > Phuket I like this idea in Gentoo POV (USE flags, customization...) So I'm supporting optional deps/builds in any kind. Did you consider building single jar/so with the features requested in configure stage. That might be an option instead of cluttering commandline/filesystem with multiple libraries. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2849IACgkQRh6X64ivZaIw2wCfdyx/GU+hIknSg7602lMF2xst SFUAn2kaUq3I/D1DW/kUGSRp6jzGfnZH =dHw1 -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-05-01 02:44:09
|
Something I have been musing about for a while is how we could implement optional dependencies into java-gnome. Right now you put gtk-4.0.jar on your classpath, and you're done. That's a Good Thing™ That .jar magically loads libgtkjni-4.0.20-dev.so [the name does not matter] which is linked against ... everything. :( The big case that pushes this is WebKit. We'd like to include coverage of WebKitGtk soon. But either you have it on your distro and can easily build against it, or you don't, and it becomes a blocker against you're being able to build java-gnome from source. Another example is GtkSpell; at the moment I don't use it, and so seeing it in the output of ldd tmp/libgtkjni-4.0.20-dev.so is a bit of a surprise Because Java only loads classes when required, it doesn't cost developers anything to have a single .jar to include in their classpath, and indeed that is MUCH better than having to include 14 .jar files in some complex stack of dependencies that no one cares about. The libraries, on the other hand, bother me a bit. I've been wondering if we should have tmp/libglibjni-4.0.20-dev.so tmp/libgtkjni-4.0.20-dev.so tmp/libgnomejni-4.0.20-dev.so tmp/libwebkitjni-4.0.20-dev.so etc that would be loaded by System.load() calls in the individual package Plumbing classes. The usual wisdom is that more shared libraries are bad. If that is true, then our single .so is a good thing. On the other hand, if tighter linkage in many .sos would perhaps reduce our virtual memory demand? Our footprint appears huge in top(1), gnome-system-properties etc and while I know those are not much of a measurement tool, I am conscious that over time memory pressure adds up and I'd like to make sure we're doing the right thing. AfC Phuket |
From: Andrew C. <an...@op...> - 2011-04-14 06:20:48
|
On Wed, 2011-04-13 at 00:04 +1000, Andrew Cowie wrote: > ValidateProperties is failing, however; Thanks to Guillaume we've tracked that one down. And I fixed what appears to be a renamed internal type in GDK. Now we've moved on to a failure in ValidateInputMethods. This is harder to guess. AfC Sydney |
From: Andrew C. <an...@op...> - 2011-04-12 14:04:58
|
I've just finished porting the unit test suite and friends in tests/ to here to use Widget.Draw and other new APIs. ValidateProperties is failing, however; it looks like the clamping behaviour has changed. Could someone have a try building and see a) if they duplicate it, and b) if you can figure out what might be wrong? Appreciate any help. The '4.1' branch is at http://research.operationaldynamics.com/bzr/java-gnome/4.1/ AfC Sydney |
From: Andrew C. <an...@op...> - 2011-04-12 03:08:29
|
Over the past few days I have (for lack of a better word) backported a number of APIs from java-gnome 4.1 to java-gnome 4.0 These are just simulations, but so far so good - where GTK 3 has hung us out to dry I've been able to wrap the old GTK 2 calls in things that look suspiciously like what the GTK 3 APIs. Currently 'mainline' has, as 4.0.20-dev, Widget.Draw signal wraps Widget.ExposeEvent void overrideFont() wraps modifyFont() void overrideColor() wraps modifyText(), etc ComboBoxText wraps our TextComboBox StateFlags wraps StateType RGBA wraps Color I have no idea if we can keep this up, but I'm trying. With any luck, I'm hoping to reach the point where code that compiles against 4.0.20 can be recompiled against 4.1.1, which would make porting/upgrading a hell of a lot easier. There's no behaviour consistency guarantee, of course - Widget.ExposeEvent and Widget.Draw are not the same thing. And since my code worked with ExposeEvent before, of course it works with "Draw" now. We'll see what happens when we all finally get desktops with a GTK 3 packages on them. Simultaneously I've been merging the 4.0 'mainline' into the 4.1.1-dev branch and reverting all the adaptor cruft that I'm introducing in 4.0.20-dev. AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-04-08 20:17:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-04-2011 06:51, Andrew Cowie wrote: > On Thu, 2011-03-31 at 11:12 +0300, Serkan Kaba wrote: >> So what's your plan for example about slashtime. Do you >> plan to allow depending on both series? > > Not really up to me, but you won't easily be able to get a complex app > to build against java-gnome 4.0 and java-gnome 4.1. The underlying API > break is large, and I'm not sure we can simulate everything in 4.0 > > We can try, of course :) I think I've managed it with Widget.Draw for > example. > > For Slashtime, I suspect that I'll branch a 0.5 series off so there's a > head that always builds against 4.0, but that future development would > depend on 4.1 > > AfC > Sydney > So as far as I understand slotting it in Gentoo will make sense. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fbRQACgkQRh6X64ivZaK0PQCfZ6Wk+B2e7I2YBcfIfOsJr7YI kkQAn0l3v8/3Nf/gytZx7DpA7JwtwZj6 =hMda -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-04-08 03:46:45
|
I had a shot at implementing GtkBuilder support in java-gnome. The public API was easy and was done in a flash. But it doesn't work. Exception in thread "main" java.text.ParseException: Invalid object type `GtkLabel' at org.gnome.gtk.Builder.addFromFile(Builder.java:107) at Designer.setupUserInterface(Designer.java:46) at Designer.main(Designer.java:80) Invalid object type? huh? ++ I have copied in the logs of a long conversation I had on #gtk+ today with Tristan van Berkom, Benjamin Otte, and Johan Dahlin. I'd ask you to read through it. The end result appears to be that because java-gnome reaches GTK via a shared library and not by virtue of being an executable itself, GtkBuilder won't work as is. There are two options: 1) implement a vFunc (by C side subclassing GtkBuilder, I think) to do ... something 2) manually call dlopen() with RTLD_GLOBAL which does ... something The fact that I was able to hack (2) to work is not interesting. What's the cost of it? I assume switching it to global would mean an insane growth in the runtime size of the symbol table. Is that bad? I assume so. How do we measure it? No idea. Also, if we did (2) then we'd have to manually list every system library name in C code. That's fragile, to say the least. On the other hand, it's not like our symbol table isn't huge already care of JNIEXPORT [which is the reason to investigate JNI's RegisterNatives, but that's another story]. But this wouldn't read-only sharable data space in a .so, right? We want to shrink our memory footprint, not grow it! Johan said that the vFunc was just for this sort of occasion. Ok, so presumably (1) is the better thing to do, but can anyone figure out from this conversation what, exactly, we're supposed to do there? My branch is at 'hackers/andrew/builder'. It's a 4.0 branch. With the patch below it "works", but we can't use that patch as is. Slightly edited IRC log follows. As you'll read, on quite a number of occasions I point out that I really don't know enough about linking to be able to properly assess what is (or isn't) going on. Thanks to Tristan, Benjamin, and Johan for their help getting us this far! Now, my friendly little java-gnome hackers, I need yours... AfC Sydney ++ AfC: Hm. I wonder why GtkBuilder would emit "Invalid object type `GtkLabel'" when parsing a .ui file? Company: AfC: not yet called gtk_init() or so? Company: AfC: the gtk_label_get_type() function must have been called once for the type to be registered AfC: Company: no, gtk_init() etc called already AfC: Company: er AfC: what? AfC: you're kidding. Company: no, i'm not Company: but i'm pretty sure there is some function that does that AfC: You mean someone has to manually call gtk_label_new() and gtk_foobar_new() and gtk_everything_else_new() before they can use GtkBuilder? Company: AfC: no tristan: AfC, you you doing this in C ? Company: AfC: i mean someone has to call gtk_label_get_type() tristan: AfC, there is a function that creates "gtk_label_get_type" from "GtkLabel" AfC: tristan: no, I'm finally getting around to porting our libglade coverage in java-gnome to GtkBuilder instead. It was easy enough, except that I've hit this tristan: it's used along with g_module_symbol() to initialize types Company: ahhh Company: more magical than i'd have thought tristan: AfC, I suspect... not sure... but suspect that the binding has problems getting the type from name AfC: bloody hell. Do you have any idea how much we have *not* exposed the _get_type() functions? They're meaningless in a language binding. tristan: I think bindings are supposed to override that part of the builder tristan: I mean... do you want builder to create a raw GtkLabel ? or do you want it to create some java-gnome wrapper object ? tristan: I suspect that in gtkmm they have some derived code that returns a wrapper ***tristan checks with builder how thats done for bindings... I dont recall Company: i'd expect you let the builder create the label tristan: AfC, GtkBuilderClass.get_type_from_name() Company: and then wrap it AfC: tristan: the proxy object (to use Owen's terminology) is already fully engineered, that works fine [and worked fine with libglade]. AfC: tristan: we're stuck at add_from_file tristan: Company, you would expect that to be done where then ? Company: tristan: in get_object() AfC: Company: that's what I'd expect, and that's what we're doing tristan: AfC, I dont know how it worked fine in the past and how it worked with libglade. AfC: Company: we're not even at get_object() yet. Given any pointer we can ... call g_type_name() on ... we can construct our proxy, no problem Company: AfC: as tristan says, that's not enough AfC: Company: but I can't understand why gtk_builder_add_from_file() can't hack it when glade_xml_parse() managed it AfC: Well. tristan: different languages seem to have totally different binding sets tristan: for instance, I'm not sure that when you create a derived widget with gtkmm, that it even registers a GType for the new class tristan: when you create an object with python... it makes a GType tristan: so they are bidirectional tristan: in a sense Company: AfC: glade called all gtk get_type() functions afair Company: AfC: was always tricky when gtk added new widgets and libglade hadn't been updated yet tristan: Company, would it be enough to do it in get_object() ? tristan: if I go and fetch a window or box... and then itterate it's children AfC: tristan: no we don't do anything like that. Never needed to. As far as C is concerned it's just a GtkWhatever. If the developer has created a Java side subclass that's their business. Things Just Work™. But that's not the problem here tristan: do I get widgets as children or wrappers ? Company: tristan: you get wrappers AfC: Company: ... called all gtk_get_type_ functions. Oh. Yes, well, that'd do it Company: AfC: so why does gtkbuilder not find the existing C function gtk_label_get_type() when trying to g_module_symbol() it? tristan: AfC, they *kindof* work then... if you cannot get the derived class details in GType terms in C... then ... it's impossible for me to make a useful java-gnome plugin for Glade Company: AfC: in java-gnome i mean AfC: Company: hm? tristan: because I cannot read any properties or signals that the java-gnome object may have added AfC: Company: Code is like this: AfC: Gtk.init() AfC: builder = new Builder(); AfC: builder.addFromFile("simple.ui"); AfC: crash AfC: (well, GError → Exception → terminate) Company: AfC: yes, because java-gnome is doing bad things Company: AfC: because g_module_symbol(null_module, "gtk_label_get_type") fails Company: AfC: and that's java-gnome's fault somehow AfC: Company: sorry, what is that? Company: AfC: that is C AfC: Company: look I know you guys don't give a shit about language bindings, but maybe we can leave off the "fault" stuff and assume that the project means well, and has done what was asked of it over the years? AfC: So if there's a new initialization pattern that needs to be supported, fine Company: AfC: there isn't Company: AfC: there's just a new way to look up class names Company: AfC: and it's done by inspecting the running code for an exported C function AfC: Company: so you're saying we instantiated the GtkBuilder object somehow wrong? tristan: AfC, I do give a shit, and I also wish I could introspect more from language-binding created classes... I dont see exactly what could be going wrong AfC: tristan: no, me neither; tristan: if your code is running with libgtk+, then "gtk_label_get_type" MUST be there tristan: no reason for the C code calling g_module_symbol to fail. AfC: tristan: what I wrote above is == to this C code, right? Company: AfC: no, i'm saying that a java-gnome application looks different to C code than a C application AfC: gtk_init() AfC: gtk_builder_new() AfC: gtk_builder_add_from_file() tristan: AfC, yes that should really definitely work AfC: well, that's the sequence of C calls we're making. :( Company: AfC: no, deep down it's not Company: AfC: are you linking your java app with gcc? Company: AfC: is it doing the equivalent of gcc -shared -lgtk-3 ? AfC: Company: This is GTK 2, but yes AfC: LINK=/usr/bin/gcc-4.4 -shared + pkg-config --libs tristan: right, I suppose there could be low-level trickery, that some obscure calls to ldd/nm might reveal Company: AfC: so if you run ldd on the generated binary, it will list libgtk just like when running it on /usr/bin/gtk-demo ? AfC: Company: there's no binary. There's a shared library loaded at runtime, but I will double check Company: AfC: aha! tristan: i.e. what is the actual symbol name... but if it's linking to a real libgtk+ lib... I still dont see why there would be no "T gtk_label_get_type" in there Company: AfC: shared libraries loaded at runtime may be loaded with hidden symbols Company: AfC: so that g_module_symbol() would not find the symbol AfC: Company: um, ok, that's interesting AfC: notes that the rest of the GNOME stack works fine, and has for 9 years Company: yes tristan: if it obfuscates the symbol name or such, you can reverse the process by implementing GtkBuilderClass.get_type_from_name() Company: the rest of the gnome stack doesn't have to resolve C symbols at runtime AfC: if [what] obfuscates? AfC: This is very interesting tristan: whatever obscure linking method you might use Company: tristan: it's dlopen()ing libgtk with RTLD_LOCAL AfC: Um, well, it's doing whatever pkg-config tells it to do tristan: Company, that means you can find nothing in the global namespace ? Company: tristan: actually, it's not dlopen()ing libgtk but libjava-gnome-plugin.so Company: tristan: yes AfC: yes AfC: (where it is the Java VM process, yes) tristan: right, so "whoever" is dlopening it.. has access to those symbols, there is a handle somewhere tristan: that handle needs to be used in GtkBuilder->get_type_from_name() tristan: to get the actual type AfC: tristan, Company: thanks for your help. I'll be honest and say I don't really understand what needs to be done; AfC: tristan, Company: sounds like its not a matter of a different linker flag but I certainly don't have access to the dlopen call being made by the VM [nor would any language binding, I imagine] AfC: tristan, Company: unless it's $something I can do before calling [say] gtk_init() Company: AfC: i'd suspect python or other languages have the same problem Company: JS, whatever tristan: AfC, short answer/explanation is that a language binding needs to know how to get the actual GType from a type name before the type is actually registered Company: unless they don't use RTLD_LOCAL Company: AfC: and as tristan says, you can overwrite the lookup function AfC: [I don't know that the JVM is, fwiw] tristan: python works find with GtkBuilder, they create real GObjects afaik also AfC: tristan: isn't that circular? g_type_from_name() only works after a type has been registered, right? AfC: Hey, if someone can point us at the call that eg Python is making before they call gtk_init() that magically fixes the problem, then I'll get it added right away. tristan: AfC, no it's not circular, I said a binding needs to make that association *before* the type is registered AfC: tristan: ah AfC: tristan: well as it happens we do have such a list tristan: it's simple: GTK+ provides standard naming convention, and all the _get_type() stubs are there tristan: just have to mash up the string a bit and use the _get_type() to create it AfC: tristan: so you're saying we have to invoke every _get_type() possible before attempting to use GtkBuilder. tristan: GTK+ already does the string mashing part, you can copy that code pretty easily tristan: AfC, no... you have to call _get_type() as a result of GtkBuilder->get_type_from_name() tristan: in your language binding's wrapper of GtkBuilder... you override the ->get_type_from_name() vfunc tristan: and make it do something language binding custom AfC: this is where I'm lost. There's nothing custom AfC: we just have a GtkBuilder* tristan: AfC, that was an ugly issue with libglade... you actually had to register each type to use them tristan: so a.) libglade needed updates for new types... and b.) applications needed to provide modules to load their own custom types tristan: AfC, you use GtkBuilder directly from java ?? tristan: or you have something in between, right ? tristan: the in between should use CustomBuilder instead of GtkBuilder directly tristan: with ->get_type_from_name() overridden AfC: We're verging off-topic for #gtk+ and I don't want to further clutter up the channel when important bug fixing is going on. AfC: tristan: I was hoping to have GtkBuilder coverage in our 4.1 release to replace the removed libglade, but it sounds like we'll have to dig a bit harder. AfC: appreciate your help tristan: I'll be around, sorry to walk out on you AfC: tristan: nah, that's cool (12:19:43) jdahlin: AfC: libglade has a huge table which maps widget name to GType, we wanted to avoid that when rewriting libglade into GtkBuilder AfC: jdahlin: I see jdahlin: and as Company pointed out, that caused problems when a new widget was added in gtk+ but not in that table AfC: jdahlin: sure, I grok that jdahlin: so dlsym(NULL, "gtk_widget_get_type") needs to work, not sure why that isn't working for java-gnome AfC: jdahlin: yeah. I don't really understand why a shared linking to GTK is different than an executable linking to GTK [with respect to however this works in a normal C GTK program] (which is Company's hypothesis) jdahlin: AfC: executable linking is done at compile time, while dlopen/dlsym is runtime jdahlin: AfC: GtkBuilder creates a bit of problem for C programs as well, it uses dlsym to find out callbacks specific in the .ui file jdahlin: so for C programs you need to link with -rdynamic jdahlin: is java-gnome using jna or jni? AfC: jdahlin: JNI tristan|afk: jdahlin, I think he means that... java-gnome being a shared lib is linking to GTK+... I *think*... that the java-gnome lib is dlopened by whatever is running this AfC: tristan|afk: that's correct jdahlin: AfC: the main executable is the jvm (/usr/bin/java or whatever), it loads in libjava-gnome.so via dlopen AfC: So if there's something I have to add to the linker invocation to build the .so, no problem jdahlin: for GtkBuilder to work you have to make all *_get_type symbols accessible in the main namespace for jvm jdahlin: that's usually accomplished by passing in RTLD_GLOBAL to dlopen tristan|afk: if I'm guessing Company's hypothesis right... maybe what is opening java-gnome is doing so without making the symbols global tristan|afk: so when that code actually ends up running dlsym() with NULL... it finds nothing jdahlin: how is libjava-gnome.so linked against libgtk.so? tristan|afk: jdahlin, or... it can be done by overriding ->get_type_from_name() inside java-gnome... I think, no ? AfC: If so, that's going to be hard to beat, because I have zero control over that. The only workaround would be to cause the VM process to load a *separate* library first, and call dlopen() on libgtk-x11-2.0.so.0 jdahlin: tristan|afk: that would work as well AfC: jdahlin: well, let's see jdahlin: AfC: do you know how the VM loads JNI modules? AfC: jdahlin: no AfC: jdahlin: more to the point, I have zero influence over it. AfC: I mean, it's gotta be dlopen() and dlsym(), but with what flags? No idea AfC: jdahlin: LINK=/usr/bin/gcc-4.4 -g -shared -Wall -fPIC AfC: and AfC: jdahlin: $LINK -o tmp/libgtkjni-4.0.20-dev.so $objects `pkg-config --libs $modules` AfC: [sic] jdahlin: okay, you could fix it up yourself, either by overriding get_type_from_name as tristan mentioned or just doing something like dlopen("libgtk.so", RTLD_GLOBAL) in JNI's module initialization function AfC: jdahlin: I can certainly do that. AfC: That's what suggested to Company AfC: though I wasn't sure if that would do anything if invoked from a .so that is already linked against libgtk-x11-2.0.so.0 jdahlin: it's a bit ugly using RTLD_GLOBAL though, you're polluting the namespaces jdahlin: it'll hopefully do the right thing jdahlin: the same needs to be done for all shared libraries with *_get_type functions that java-gnome wants to support, it's not just gtk jdahlin: but gtk+ is arguable the most important one AfC: As for "a bit ugly", that's what I'm blown away by all this. I've tried to follow this conversation, but fundamentally I just don't understand why it works for a C program [without "polluting"] and not a .so AfC: anyway, trying my best jdahlin: AfC: because of a number of reasons, a C program is linked at compile time and all the functions its using are known jdahlin: eg, it knows that gtk_label_get_type() is going to be used, but not gtk_button_get_type() etc jdahlin: you can check which functions are linked in by running ldd on the executable jdahlin: now, dynamic languages uses dlopen() which can specific, make all functions available or none at all jdahlin: the JNI authors decided the latter should be the default for some reason, and it doesn't seem (by 2 minutes googling) that it's possible to change that AfC: [ldd + executable = functions? What option is that?] jdahlin: or if it's objdump/nm, haven't looked at it for a while jdahlin: objdump -T executable seems to do it here on my system AfC: ah AfC: Well AfC: I added this before the call to gtk_init(): === modified file 'src/bindings/org/gnome/gtk/GtkMain.c' --- src/bindings/org/gnome/gtk/GtkMain.c 2010-02-14 20:14:38 +0000 +++ src/bindings/org/gnome/gtk/GtkMain.c 2011-04-08 02:51:05 +0000 @@ -31,6 +31,7 @@ * wish to do so, delete this exception statement from your version. */ +#include <dlfcn.h> #include <jni.h> #include <glib.h> #include <gdk/gdk.h> @@ -56,6 +57,7 @@ jobjectArray _args ) { + void* handle; int argc; char** argv; gint i; @@ -90,6 +92,12 @@ argv[0] = ""; argc++; + handle = dlopen("libgtk-x11-2.0.so", RTLD_NOW | RTLD_GLOBAL); + if (handle == NULL) { + bindings_java_throw(env, "dlopen() failed: %s", dlerror()); + return; + } + // call function gtk_init(&argc, &argv); AfC: and now GtkBuilder works jdahlin: great AfC: yeah. But is it great? :) jdahlin: great that it's working AfC: Certainly lends strength to Company's hypothesis, that's for sure jdahlin: is it inconvenient for you to override the GtkBuilder vfunc get_type_from_name? AfC: jdahlin: "no", but I'm not sure what I'd be overriding it with? jdahlin: AfC: implementing it! jdahlin: you need to subclass it and override it AfC: "This is mainly used when implementing the GtkBuildable interface on a type." jdahlin: sure, but we're outside of "mainly" right now jdahlin: I added it specifically for these kind of situations jdahlin: s/added/made it overridable/ jdahlin: gtkmm uses it as well if iirc AfC: Oh? Ok. I should go look at their code, then jdahlin: not really jdahlin: all gtkmm classes are subclasses, and they implement it to map GtkLabel to their overridden GType jdahlin: http://git.gnome.org/browse/gtkmm/tree/gtk/src/builder.ccg AfC: jdahlin: yeah, I'm reading that right now AfC: All they do is call g_type_from_name() ? jdahlin: gtkmm is considerably different from a dynamic binding, so you shouldn't worry too much AfC: um generally we're mostly the same; Java is a static language too jdahlin: no, it's not really static AfC: [except for this business of getting to GTK through a .so rather than a linked executable] jdahlin: in the sense that language bindings are loaded via dynamically AfC: Sure. I means static as in static language API, not a dynamic language API AfC: So I assume that GtkBuilder just calls g_type_from_name() itself internally. jdahlin: not really no jdahlin: but it works fine for gtkmm which calls all get_type functions when the library loads AfC: Ah AfC: No, we definitely don't do that. :) AfC: We could, I guess. Sounds expensive. jdahlin: maybe it doesn't, but their impl. requires you to call the _get_type function of a class before using it in gtkbuilder AfC: which is why g_type_from_name() works AfC: right AfC: hm AfC: Embedding system library names in the source code to pass to dlopen() is going to be fragile. AfC: I wondered if -rdynamic to the linker would have the same effect, but no jdahlin: kind of fragile yes, but the alternatives are wors jdahlin: e AfC: jdahlin: that seems pretty nuts of GTKmm; if I do get_object() on something I think is be a GtkButton and it turns out to be a GtkCheckButton (say) it'll crash AfC: [actually, it won't get past add_from_file() which is my problem right now] jdahlin: dunno about the details, you need to check with the gtkmm authors if you really want to know AfC: jdahlin: yeah, I'll talk to Murray next time I see him ***jdahlin -> zzz AfC: jdahlin: do you have an opinion about the "expense" of dlopen(... , | RTLD_GLOBAL)? AfC: jdahlin: ah, g'night. Thanks for your help |
From: Andrew C. <an...@op...> - 2011-04-06 13:57:50
|
I finished the src/bindings/ core of the '4.1' branch; java-gnome compiles against a GTK 3 stack now. I also added constructors for the formerly abstract Box, Scale, Scrollbar, Paned, etc http://research.operationaldynamics.com/bzr/java-gnome/4.1/ Maybe someone can take a swing at cleaning up the tests? `make test` shows things like ComboBox needing fixing... Notable things on the TODO list: - overrideColor() etc methods for Widget - height for width methods on Container (?) I'm also sure the screenshot infrastructure is a broken; I patched it but I have no idea if that worked. AfC Sydney |