[packagekit] package icons and names

Ken VanDine ken at vandine.org
Sun Sep 9 04:55:10 PDT 2007


What is the status of this integration in PackageKit?  Planned?  This
solves a problem I have and would love to know if I need to go another
route.

Thanks,
--Ken

On 8/30/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> Richard wanted to show nice package names and icons, something we are
> already doing in BigBoard - the info is on
> http://online.gnome.org/applications (with a mugshot theme that needs
> to be changed to the online.gnome.org theme when someone has time).
> There's a (very lame) Wiki-type UI that allows app information to be
> edited. Since this will benefit from more people using it and keeping
> it updated, and also supplies useful features like popularity ratings
> (and possibly other useful stuff in the future), it may make sense to
> use.
>
> I just tweaked the API for package information a bit; it's not live
> quite yet, but you can see it on the dogfood server:
>
>  http://dogfood-online.gnome.org/xml/allApplications?distribution=fedora&lang=en_US
>
> (caution, 300K XML document)
>
> Note that a distribution= and lang= param should be provided. lang= is
> ignored now but would theoretically be used later; distribution=
> filters the packageNames attribute you get if you omit it, providing a
> packageName attribute suitable for the distribution.
>
> The icon urls in the XML are now "unsized" urls[1], which means size
> and theme parameters should be added, like:
>   unsizedurl?size=48&theme=Tango
>
> The theme parameter is ignored for now but we could use it later.
>
> Important notes on using this:
>  - ideally, the "base" url  (like dogfood-online.gnome.org or
> online.gnome.org) should be
>    obtained from the org.freedesktop.od.Engine D-Bus service, but hardcoding
>    online.gnome.org is probably fine for now, at least once we deploy the latest
>    features to that server
>  - it is important to honor the "cache control" headers on the icons
> when they are
>    downloaded, when appropriate we will set "never expire" headers to chill out
>    server load
>
> Pragmatically, for using this some suggestions discussed on IRC:
>  - make the package UI able to operate without the information (since
> some packages will
>    always be missing icons/names anyway, it already has to be able to do this)
>  - download and cache the metadata on demand
>  - if desired, we could set up a nightly "release" which would just
> download the
>    information in the same format as the cache, and put it in a tarball;
>    people would then be free to create an RPM from it; but this might
>    be more trouble than it's worth if the UI can operate without the
>    info anyway
>
> Finally, something to check out is that with BigBoard plus
> http://online.gnome.org/applications, there's no major need for a
> *desktop* app "package manager" at all... package installation is
> integrated into the same UI used to launch applications. This same
> approach should be usable with panel / app-launcher thingies that are
> not BigBoard. It does not work for say installing MySQL, of course, so
> a more "package manager" kind of UI may make sense instead for
> servers.
>
> Havoc
>
> [1] OK, it looks like there's a bug in my code, but they will be unsized soon
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>


-- 
Ken VanDine
http://ken.vandine.org



More information about the PackageKit mailing list