[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KLibFactory preview of planned changes
From: Holger Freyther <freyther () kde ! org>
Date: 2006-10-31 7:48:40
Message-ID: 02A06BB1-0CF9-47A4-BDDC-E161D81CAD74 () kde ! org
[Download RAW message or body]
Am 30.10.2006 um 10:45 schrieb koos vriezen:
Hi Koos,
> 2006/10/29, Holger Freyther <freyther@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic