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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
