[packagekit] A PackageKit browser plugin

[Owen Taylor]

[ Adding back the packagekit list CC: ]

On Mon, 2008-07-28 at 08:12 +0100, Richard Hughes wrote:
> On Sun, 2008-07-27 at 13:33 -0400, Colin Walters wrote:
> > On Sun, Jul 27, 2008 at 11:41 AM, Kevin Kofler
> > <kevin.kofler at chello.at> wrote:
> >         Colin Walters <walters <at> verbum.org> writes:
> >         > Well, keep in mind that this isn't the same target use case
> >         as the pk shared
> >         > libraries; i.e. nothing except Firefox-derived codebases is
> >         going to be
> >         > linking in Firefox extensions.
> >         
> >         
> >         Is it an extension or a traditional plugin? Other browsers,
> >         such as Konqueror,
> >         can also load classic Mozilla plugins (but not Firefox
> >         extensions, of course).
> > 
> > Actually you're right, it is a plugin and not an extension.  However I
> > think the generic-interface exception would apply here (i.e. it
> > doesn't count as linking).
> 
> Sure, then I think it makes perfect sense to include this in the
> PackageKit source tree. I think it just needs a --enable-mozilla-plugin
> in configure.ac and stick the files in contrib/mozilla-plugin
> 
> If we change it to use the dbus interface, then it's not gnome specific
> -- and we get the native KDE stuff when the KPackageKit guys implement
> the same session interface.

It won't be GNOME specific, but it is going to link to at least

 Glib (for main loop)
 Pango and Cairo (for drawing the UI)
 
And without some work:

 GTK+ (to get colors and fonts and X server timestamp)

It's pretty hard to build a useful open source OS without having those
libraries installed, but maybe people would object to having them as
build dependencies of a core system component?

(It also depends on the 'mozilla-plugin' .pc file from xulrunner
for header files, though that dependency is pretty shallow.)

> Plus, putting it in tree allows me to keep it compiling even if we
> change API/ABI in the future.

Yeah, that definitely is an argument for keeping it in tree. Keeping a
separate package for ~1000 lines of real code is a pain.

> Could you prepare a patch, of do you want me to have a go?

I'll probably do a couple of more revision as a standalone thing to
cover some of the points you brought up in your other mail, and then we
can discuss moving forward from there.

- Owen