KLibFactory preview of planned changes

Holger Freyther freyther at kde.org
Tue Oct 31 07:48:40 GMT 2006

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  
>> solely in the KParts
> No that would pass modified options.


>>         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

More information about the kde-core-devel mailing list