KLibFactory preview of planned changes

[Holger Freyther]

Am 30.10.2006 um 10:45 schrieb koos vriezen:

Hi Koos,


> 2006/10/29, Holger Freyther <freyther at kde.org>:
>>
>>
>> I still want to kill the QStringList and I see the following options:
>>         1.) we don't kill the QStringList
>>         2.) we don't kill the QStringList for KParts
>>         3.) we use toLower on all keys from the HTML and can use  
>> Q_PROPERTY
>> solely in the KParts
>
> No that would pass modified options.

Okay


>
>>         4.) we make option passing of KParts a first class citizen  
>> and a
>> dedicated method.
>>         5.) something you have in mind
>>
>> any comments?
>
> QStringList has the advantage being flexible, that KParts being used
> by KHTML use it as key=value pairs, doesn't mean it has to be that
> way. And the multible splitter code, can be solved by a library
> function as well.
> In the kjavaaplletviewer (and in nspluginviewer) only some options are
> recognised and used by the part, other options are listed and can be
> used by the applet or flash. Eg. Java applets have the
> String getParameter(String name)
> function for that. This means that you cannot lowercase at will, these
> options should be accessable unmodified.
> So you have to pass remaining options anyhow.

Okay, I think one really wants to have a virtual setOptions( const  
QMap/QHash<QString,QVariant>&) in KPart and if it gets called it must  
be called in advance of openURL. This avoids formating a parameter  
list and parsing it again when direct functions calls could work. For  
KParts/KHTML it looks like a valid use-case and I will prepare a patch.


kind regards
	holger