Version: (using Devel) Compiler: gcc 4.3.2 OS: Linux Installed from: Compiled sources It appears at first glance that the smoke findMethod() function should find a method regardless of which smoke object that method is defined in. For instance, qt_Smoke can find the method MessageBox::enableAllMessages, even though it is defined in kdeui_Smoke. This isn't the case for methods defined in QGlobalSpace, because that "class" is marked as being internal to each of qt_Smoke, kdecore_Smoke, and kdeui_Smoke, among others. This makes it rather difficult to find methods defined in the QGlobalSpace namespace, because you have to know which Smoke object to use before you do the lookup. I wrote this small program to illustrate the problem: #include "smoke.h" #include "qt_smoke.h" #include "kdecore_smoke.h" #include "kdeui_smoke.h" int main() { init_qt_Smoke(); init_kdecore_Smoke(); init_kdeui_Smoke(); Smoke::ModuleIndex method1 = qt_Smoke->findMethod( "QGlobalSpace", "ki18n$" ); Smoke::ModuleIndex method2 = kdecore_Smoke->findMethod( "QGlobalSpace", "ki18n$" ); Smoke::ModuleIndex method3 = kdeui_Smoke->findMethod( "QGlobalSpace", "ki18n$" ); Smoke::ModuleIndex method4 = qt_Smoke->findMethod( "KMessageBox", "enableAllMessages" ); Smoke::ModuleIndex method5 = kdecore_Smoke->findMethod( "KMessageBox", "enableAllMessages" ); Smoke::ModuleIndex method6 = kdeui_Smoke->findMethod( "KMessageBox", "enableAllMessages" ); if( ( method1 == method2 ) && ( method2 == method3 ) && ( method3 == method1 ) ) { printf( "QGlobalSpace::ki18n$ found from all smoke objects\n" ); } else { printf( "QGlobalSpace::ki18n$ NOT found from all smoke objects\n" ); } if( ( method4 == method5 ) && ( method5 == method6 ) && ( method6 == method4 ) ) { printf( "KMessageBox::enableAllMessages found from all smoke objects\n" ); } else { printf( "KMessageBox::enableAllMessages NOT found from all smoke objects\n" ); } }
The problem is that QGlobalSpace is defined in multiple smoke modules, and findMethod() will first look for the classId of 'QGlobalSpace'. It then finds the last one registered and looks the method up in that. We circumvent the problem in QtRuby and Qyoto by searching every module explicitly for QGlobalSpace methods. There's no other way around that currently. Any fix within smoke itself would get pretty ugly I think (using std::multmaps or another list of loaded smoke modules, which doesn't really belong to smoke itself) and would be BIC anyway. I'm not quite sure what to do, but letting the bindings figure out the correct QGlobalSpace as it is now seems best to me, currently.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Arno's comment implies that this is a design decision and won't change.