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. 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. 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 > * 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. 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 :-) I'll take a look at a "_Run 1.2.1 now_. _Upgrade to version 1.2.3_" user interface. > * 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. 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. - Owen -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
