[Kde-bindings] question about the hello.cpp example

[John J Foerch]

Arno Rehn <arno at arnorehn.de> writes:
> On 11/02/13 04:16, John J Foerch wrote:
>> Hello,
> Hello,
>
>> I have been studying the example program hello.cpp from
>> http://techbase.kde.org/Development/Languages/Smoke#hello.cpp as I
>> develop a set of Qt/Smoke bindings for my favorite Scheme dialect, and
>> there is one thing about the program that has me mightily confused.
>>
>> qtcoreBinding and qtguiBinding seem to be used almost interchangeably.
>> The QApplication constructor is looked up in qtcore, but at the end of
>> the program, the destructor is looked up in qtgui.  The "set smoke
>> binding" call for both qapp and widget use qtgui, and nothing uses
>> qtcore.  In my experiments in my scheme implementation of this program,
>> I have found that I can completely remove all references to qtcore in
>> the program and use qtgui instead, and it still works, but not the other
>> way around.
> Yes, you can replace qtcore with qtgui in this case, because only QtGui
> classes are used (i.e. QApplication and QWidget). Method lookups work
> across module boundaries, but they can be faster if you do the call in the
> correct module.
> The QtCore smoke module will implicitly be loaded by the QtGui smoke
> module (you might leak memory then, however, if you don't delete the
> qtcore Smoke instance at the end).
>
> The SmokeBinding instance that you set for each object should be the
> correct one for the respective module, i.e. you have to have one
> SmokeBinding instance per Smoke module (that you use).
>
>> What is the relationship between these two modules?  Does qtgui contain
>> qtcore?  Are they both needed in this program, or in any program that
>> uses qtgui?  Can anybody clarify?
> No, qtgui doesn't contain qtcore. It only implictly loads it. Some types
> in qtgui depend on classes from qtcore (the respective classes are then
> flagged as "external" in qtgui and you'll have to look them up in the
> other modules), so in a more complex app you'll need it anyway.

I see.  Thank you very much for the explanation.  It's very clear now.
I see the source of my confusion; perhaps my newbie-level feedback can
be helpful to the maintainer(s) of this example..

The point that confused me was that the two findClass lookups use
qtcore_Smoke instead of qtgui_Smoke, perhaps as a convenience:

   Smoke::ModuleIndex classId = qtcore_Smoke->findClass("QApplication");
   ...
   classId = qtcore_Smoke->findClass("QWidget");

The code following these lookups did not use qtcore_Smoke, but instead
used the 'smoke' reference from the returned ModuleIndex.  It's not
clear though that the convenience of a cross-module lookup served any
purpose here, because the programmer has to know later on which
SmokeBinding to attach to the qapp and widget objects.  For illustrative
purposes, I think it would be clearer if qtgui_Smoke was used for that
class lookup, or if there were an explanatory comment covering this
point.

Another comment might added to note what you told me - that it is not
strictly necessary to init_qtcore_Smoke() or even to include
qtcore_smoke.h in this program, because no qtcore classes are used
directly, but that it represents good practice, for memory-leak reasons.

Thank you again,

-- 
John Foerch