plugin badness

Koos Vriezen koos.vriezen at xs4all.nl
Tue Mar 16 18:36:08 GMT 2004


On Tue, Mar 16, 2004 at 12:57:47PM -0500, George Staikos wrote:
> On Tuesday 16 March 2004 11:47, Koos Vriezen wrote:
> > On Tue, Mar 16, 2004 at 07:11:10AM -0500, George Staikos wrote:
> 
> > > - We list KHTML as a plugin for KHTML.  How strange (from a website
> > > perspective).
> > > - We list libnsplugin as a plugin.  That is, we list the plugin loader as
> > > a plugin, which supports all the mimetypes that all the plugins support
> > > of course.  This must be extremely confusing to some sites out there and
> > > results in at -least- duplicating each mime type.
> > > - We publish a list of all installed kparts to any website out there that
> > > wants to know (minor privacy concerns)
> > > - We list rediculous things like Inode/directory parts to websites
> > > - The plugin list is -huge- and thus slow to iterate
> > > - Many mimetypes are now duplicated, triplicated, or more
> >
> > All these are plugable. Only nsplugin is an exception that it plugs
> > something else (obviously needed for some scripts).
> 
>    I don't really like the idea of some of those being listed as plugins.
> 
> > > Why don't we add a new property to kparts that says to publish them to
> > > remote sites who query for a list of plugins?
> >
> > Sounds fine with me. Btw, too bad you didn't react on this last mounth.
> 
>    Sorry, didn't think of it....

Branch should be reverted (why was it backported?). For HEAD, have you any
ideas? Now we use Browser/View, should it be Browser/Embed or check for a
property?
For plugin name and mime, there should also something made for. Now
pluginsinfo has multible entries like

  description=Shockwave Flash 6.0 r79
  file=libflashplayer.so
  mime=application/x-shockwave-flash:swf:Shockwave Flash;application/futuresplash:spl:FutureSplash Player
  name=Shockwave Flash

Now how could a kpart present itself as more then one plugin more generally?
Also using properies in .desktop files.. doesn't sound that dynamic...
Hmm, what if we add a pluginsinfo property that points to this file. So if a
part has this property, try open this file and register plugin as it used to be.
Other ideas?

Koos




More information about the kfm-devel mailing list