KLibFactory preview of planned changes

koos vriezen koos.vriezen at gmail.com
Tue Oct 31 11:33:58 GMT 2006

2006/10/31, Holger Freyther <freyther at kde.org>:
> Am 30.10.2006 um 10:45 schrieb koos vriezen:
> >> 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.

Okay with me (or what David suggested sound okay too). At first
thought, QHash would be convenient.

One other note, I noticed in your patch:
 class KHTML_EXPORT KJavaAppletViewer : public KParts::ReadOnlyPart {
+    Q_PROPERTY(QString __KHTML__CODEBASE      WRITE setCodeBase)
+    Q_PROPERTY(QString __KHTML__CLASSID       WRITE setClassID)
+    // ... Q_PROPERTY(QString

Now I assume you skip this in favor of this new setOptions() API (I
wondered about this if now KHTML should query each part for supported
But setting the base URL is actually quite useful in general to
consider for all kparts.
(the idea is that if baseurl is 'www.untrusted.com' and openURL is
'/etc/passwd', the plugin opens 'www.untrusted.com/etc/passd' and
allowRedir makes sense as well).

But forget it if it makes no sense to you,

More information about the kde-core-devel mailing list