[Kde-pim] Grantlee 0.1.3 issues

Stephen Kelly steveire at gmail.com
Sun Aug 8 23:41:10 BST 2010


Janne Hakonen wrote:

> Hi again,
> 
> Found another issue. Plugin grantlee_defaultfilters will not load with
> release configuration, not on Windows platform at least.
> 
> Grantlee::Template returns error string: Plugin library
> 'grantlee_defaultfilters' not found.
> 
> QPluginLoader in corelib/pluginpointer_p.h gives error: The plugin
> 
'E:/Programs/StarUML/modules/QtSMGenerator/grantlee/0.1/grantlee_defaultfilters.dll'
> uses incompatible Qt library. (Cannot mix debug and release libraries.)
> 
> It looks like that Qt thinks that the plugin is a debug library and not
> release library as it should.
> 
> Checking defines for grantlee_defaultfilters and grantlee_defaulttags
> projects gives following lists:
> grantlee_defaultfilters:
> 
WIN32,_WINDOWS,NDEBUG,CMAKE_INTDIR=\"Release\",grantlee_defaultfilters_EXPORTS
> grantlee_defaulttags:
> 
WIN32,_WINDOWS,NDEBUG,QT_DLL,QT_GUI_LIB,QT_CORE_LIB,QT_NO_DEBUG,CMAKE_INTDIR=\"Release\",grantlee_defaulttags_EXPORTS
> 
> Comparing those lists shows that grantlee_defaultfilters project is
> missing all the usual Qt related stuff including QT_NO_DEBUG, which I
> believe is the cause why the plugin will not load.
> 
> The plugin loads succesfully If I add
> include(${QT_USE_FILE})
> to grantlee_defaultfilters/CMakeLists.txt and rebuild it.
> 
> Or maybe Grantlee_USE_FILE should be included instead, as
> grantlee_defaulttags does, not sure.

You are right. I was able to reproduce the issue on windows with mingw, but 
not on linux. It is weird to me that adding that resolves the issue because 
the Grantlee USE file defines the grantlee_add_plugin macro, so if it builds 
then the USE file must have already been included.

Maybe I'm just mis-assuming things about how CMake works though. I've 
patched the CMakeLists file and pushed the branch. Thanks for investigating.

Steve.

> 
> Thanks,
> Janne
> 
> --------------------------------------------------
> From: "Stephen Kelly" <steveire at gmail.com>
> Sent: Wednesday, August 04, 2010 11:51 PM
> To: <kde-pim at kde.org>
> Subject: Re: [Kde-pim] Grantlee 0.1.3 issues
> 
>> Janne Hakonen wrote:
>>
>>> Hello,
>>
>> Hi,
>>
>>>
>>> I've stumbled upon two issues with Grantlee 0.1.3 while creating a
>>> custom tag and filter with javascript.
>>
>> Thanks for the patches. I've committed the change to scriptablefilter.cpp
>> to
>> the 0.1 branch. It will be part of the 0.1.5 release (in a few days
>> probably) and will then be merged into master.
>>
>>>
>>> The tag-issue I found when I attempted to make a javascript based tag
>>> (noblanks...endnoblanks) for removing empty lines from template output.
>>> I based the custom tag to spaceless-tag with some modifications and then
>>> ported it to javascript using the if2-tag from
>>> testscriptabletags-project as an example. The issue appears when there
>>> is two or more noblanks-tags used in same template file, each tags'
>>> content is replaced with template's
>>> last tag's content.
>>>
>>> The problem is easy to see by using if2-tag in
>>> tests/testscriptabletags.cpp in following way: QTest::newRow(
>>> "scriptable-tags12" ) << "{% load scripteddefaults %}{% if2 \"any\"
>>> %}foo{% endif2 %}{% if2 \"key\" %}bar{% endif2 %}" << dict << "foobar"
>>> << NoError;
>>>
>>> This causes following failure:
>>> FAIL!  : TestScriptableTagsSyntax::testBasicSyntax(scriptable-tags12)
>>> Compared values are not the same
>>>    Actual (result): barbar
>>>    Expected (output): foobar
>>> ..\..\tests\testscriptabletags.cpp(106) : failure location
>>>
>>> With trial and error, I found a workaround which seems to work. Changes
>>> to
>>> the if2-tag is in the attached scripteddefaults.qs.patch. But, I don't
>>> think that the solution is good enough IMO.
>>
>> I agree that the work-around is not a scalable fix and should not be
>> necessary in the javascript implementation. The whole QtScript stuff is a
>> bit hacky. It needs to be redesigned a bit. Thanks for the test. That
>> will certainly help to get it fixed. The fix might not make it until
>> 0.1.6 though, depending on complexity.
>>
>>>
>>>
>>>
>>> The second issue with filtering occurred when I attempted to filter a
>>> list
>>> of QObject based wrapper objects with javascript filter.
>>>
>>> Here's a clip from my template:
>>>     enum EventType
>>>     {
>>> {% for event in statemachine.uniqueEvents|onlytype:"signal" %}
>>>         Event{{ event.name|safeident|capfirst }}{% if not forloop.last
>>>         %},{% endif %}
>>> {% endfor %}
>>>     };
>>>
>>> The idea with onlytype-filter is to pass through a list of wrapper
>>> objects
>>> which type-property is same as given argument.
>>>
>>> The onlytype-filter is defined as follows:
>>> function OnlyTypeFilter( input, filterArgument )
>>> {
>>>     var outList = [];
>>>     for( var i = 0; i < input.length; i++ )
>>>     {
>>>         if( input[i].type == filterArgument.rawString() )
>>>             outList.push( input[i] );
>>>     }
>>>     return outList;
>>> };
>>>
>>> This filter, however doesn't work without some changes to
>>> scriptabletags/scriptablefilter.cpp. The input variable is a javascript
>>> Array with QVariant(QObject*) objects in it. Expression 'input[i].type'
>>> fails because the object is a QVariant and not QObject and there doesn't
>>> seem to be anyway to get the actual object from the variant. Also, even
>>> if
>>> I would just return the input variable without doing anything inside the
>>> OnlyTypeFilter-function, the returned value on template's side is empty.
>>>
>>> In C++-code that calls the javascript function the wrapper objects are
>>> passed to script engine's newVariant-method which doesn't seem to know
>>> what to do with QObject pointer and just stores it as a QVariant. in the
>>> attached scriptablefilter.cpp.patch are some modifications which uses
>>> newQObject-method instead of newVariant, if the input variants can be
>>> converted to QObject pointers. Also, the return value is checked if it's
>>> an javascript Array and then casted to QVariantList.
>>
>> Committed, thanks.
>>
>> All the best,
>>
>> Steve.
>>
>>>
>>> Thanks,
>>> Janne Hakonen
>>
>>
>> _______________________________________________
>> KDE PIM mailing list kde-pim at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>> 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list