KLibFactory preview of planned changes

koos vriezen koos.vriezen at gmail.com
Mon Oct 30 09:45:44 GMT 2006


2006/10/29, Holger Freyther <freyther at kde.org>:
> Hi again,
>
> I have started converting the code that actually used the QStringList
> and now I need some comments. Changing KDEPrint was straight forward,
> I have added two Q_PROPERTY and then called setProperty on the newly
> loaded QObject. But KHTML specially the KJavaAppletViewer gives me a
> headache.
>
> So far KJavaAppletViewer is the only real user of the QStringList
> argument, it implements splitting of options and such. I have started
> converting it to Q_PROPERTY but there are two issues where I need
> some comments.
>
> 1.) KJavaAppletViewer needs to use QDynamicPropertyChangeEvent for a
> very easy reason:
>        Currently there is name_lower in KJavaAppletViewer and we will
> need to use the Event to look at the property name in lowercase. To
> work with all different comibations of capitalisation.
>
> 2.) We need to make sure the event gets delivered before openURL on
> the Part gets called. And this is where it gets tricky. We need to
> make sure that all options are passed to the Part, we need to
> indicate that all options have been passed as well.
>
>
> Maybe we should add something like setOptions to ReadOnlyPart, or
> Part directly? As options one could use a QMap or QHash storing
> QString->QVariant pairs.
>
>
> 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.

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

Koos

>
>
> regards
>         holger
>
> PS: The patch attached changes KHTML to use a QMap<QString,QString>
> instead of encoding the QStringList with key="value"
>
>
>
>




More information about the kde-core-devel mailing list