KLibFactory preview of planned changes
freyther at kde.org
Tue Oct 31 07:48:40 GMT 2006
Am 30.10.2006 um 10:45 schrieb koos vriezen:
> 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.
More information about the kde-core-devel