[Qt-qml] How plugin paths should work

[Jyrki Hämäläinen]

09.08.2010 16:14, Matthias Ettrich kirjoitti:
> On Monday 09 August 2010 10:09:34 ext Jyrki Hämäläinen wrote:
>    
>
>> The problem (as I understand it and the actual technical background may be
>>   somewhat different) was that we tried to use pluginpath to tell where
>>   plugins are located and then force QT to load the plugins by declaring the
>>   existence of them in the qmldir-files in the modules that use the plugin.
>>   This led QT to believe that the plugin should be initialized under wrong
>>   modules "namespace" and moreover under multiple modules "namespaces". This
>>   again confused parser for some reason.
>> Funny thing in here is that the parser does not seem to get confused, if
>>   each module actually contains a separate copy of the plugin file. Not that
>>   it really matters, as it is obviously a very wrong way to use such a
>>   plugin.
>>      
>
>
> Did you use a release build? in qdeclearativeimport.cpp, line 894 I find a
> Q_ASSERT_X for exactly that case with
> "Internal error: Plugin imported previously with different uri".
>
> This is not good. If we ignore the 2nd import, we need to give a warning a
> least. Or shall we simply accept the 2nd import?
>
>    

I was using release build made out of beta2. Sorry, I failed to say that 
in the beginning.
I think we need to change that in our development environment.



Cannot really say that I understand the import parser very well so my 
opinion are just my opinions :)

My first impression is that importing same plugin / module twice is a 
fatal error and it could cause immediate failure.
I suppose that in most cases everything would work as they should, but 
it is still possible to make invisible (to user of the plugin) design 
decisions that make things behave badly if two instances are "running" 
at the same time.


But if different versions of the plugin / module are interpreted to be 
same, it makes things little bit more complicated.
I suppose that as QML gets wider user population and there will be 
larger applications built on top of it, there will also be cases where 
different parts of the application (or shared modules in import tree) 
will try to import different versions of modules.
Don't want to discuss (at least in this thread) whether that will be 
good or bad architecture but it may be needed to get things working. 
Especially if some of the modules that require imports are maintained by 
someone else.

Then again. This version issue might already be taken account in import 
parser or can be thought as such a corner case that can be sacrificed to 
keep things simple.

BR,
Jyrki