[packagekit] A PackageKit browser plugin

[Richard Hughes]

On Mon, 2008-07-28 at 09:18 -0400, Owen Taylor wrote:
> On Sun, 2008-07-27 at 09:00 +0100, Richard Hughes wrote:
> > On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote:
> > > What do people think...
> > 
> > I think it looks great. Some comments tho:
> > 
> > * You are using gpk-install-package-name -- you probably don't want to
> > call the binary name, you want to call the InstallPackageName DBUS
> > method -- see http://www.packagekit.org/pk-faq.html#session-methods for
> > more info.
> 
> OK, I'll look at switching it over.

Cool, yell if you get stuck.

> I actually would like something a little different ... since it isn't
> 100% clear that clicking somewhere on a web page is going to install a
> package on your system directly (possibly taking quite some time to
> download, possibly keeping you from suspending, etc.) I'd really prefer
> to always show a confirmation dialog like the one you get when there
> are additional dependencies to install. It would be nice if that was
> an option through the D-BUS interface.

Right at the moment the DBUS interface honours the "don't show me this
again" checkbox that you might have already clicked.

> I could obviously pop up a dialog myself but:
> 
>  A) Wouldn't have the download size
>  B) Would suck if there was then also going to be the additional
>     dependencies dialog
>  C) Some hopes of making the plugin GTK+ independent

Right.

> > * You are using the libpackagekit Resolve() -- which is fine, but you're
> > using the status boolean to check for installed. It's perfectly valid
> > for PackageKit to emit installed foo-0.1.2, available foo-0.1.3 if there
> > is a package update available. Maybe one to check for.
> 
> I'm not sure I understand this comment ...  do you mean the 
> 
> enum PackageStatus { IN_PROGRESS, INSTALLED, AVAILABLE, UNAVAILABLE, INSTALLING };
> 
> Enumeration? Actually despite this enum, the code does handle INSTALLED
> and also available for upgrade, since it has separate "availablePackage"
> and "availableVersion" fields, but it probably would be clearer with
> a UPGRADABLE status.

Ahh right.

> What I don't do at the moment is show a user interface for that case..
> it just look like the INSTALLLED case. I'm not completely sure that
> handling it is necessary... basically if the user hits that dialog
> more than infrequently, then the right user interface is
> "Fix automatic updates on your system!". But certainly you could imagine
> cases where it might be hit for newly released packages. My main
> reason for avoiding it was that having multiple links made the UI
> code considerably trickier :-)

Understood.

> I'll take a look at a "_Run 1.2.1 now_. _Upgrade to version 1.2.3_" 
> user interface.

That would rock.

> > * The destop file checking code is already present in gpk-client-run.c
> > -- maybe we can share some code there.
> > 
> > > does this make sense as part of the PackageKit project?
> > 
> > Yes, but the licence could be tricky. All of stuff in PackageKit has to
> > be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't
> > know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things.
> 
> If you read the details of the license it's actually MPL 1.1/GPL 2.0 or
> greater/LGPL 2.1 or greater. So stripping down to any GPL or LGPL
> variety is feasible. I was just keeping things simple by sticking to the
> tri-license license of the Mozilla stub code.

Right.

> In fact the Mozilla stub code could be eliminated with moderate work if
> there was a desire to change the license to something oddball or move
> the codebase from C++ to C. 

I would love it to move to C, but I didn't ask as I figured this was too
much work. I can do C++, but I much prefer C for this low level stuff.

Richard.