[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KLibFactory preview of planned changes
From:       "Michel Hermier" <michel.hermier () gmail ! com>
Date:       2006-10-31 11:54:31
Message-ID: 2e631f490610310354m35a98a50u277d1c8873976807 () mail ! gmail ! com
[Download RAW message or body]

2006/10/31, koos vriezen <koos.vriezen@gmail.com>:
> 2006/10/31, Holger Freyther <freyther@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_OBJECT
> +    Q_PROPERTY(QString __KHTML__PLUGINBASEURL WRITE setPluginBaseUrl)
> +    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
> properties).
> 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,
> Koos
>

Hi,

Reading that, I'm wondering why we can't use the qt interface system
for that? I mean, if we know the arguments the KPart should react on,
we are able to create a thin interface to access the data.

Michel
[prev in list] [next in list] [prev in thread] [next in thread]