[packagekit] PackageKit-gnome: saner icons usage

[Richard Hughes]

On Tue, 2008-01-22 at 18:30 +0100, Jakub 'Livio' Rusinek wrote:
> I'm because I have talked with people on fedora-devel-list.

Hi, I'm glad you acted on my invite to the list, welcome.

> PackageKit would check for .desktop file existence and use its "Icon= "
> definition to display appropriate icon from icon theme (or from
> specified pixmap).

An icon from the icon theme seems most sane, as then people running
tango get the right ones.

> If app provides few .desktop files, almost in all situations, there's
> one "main" desktop file, which should be used,

How do you decide which on is the main file? Something like the
openoffice package has several.

> Another approach should be used for libraries - we shouldn't use exact
> "library" in icon, but maybe generic icon with some emblem (like
> "default" in GNOME' icon theme).

Sure, I think having a library icon is a sane thing to do.

The main difficulty is working out which desktop file corresponds to
which package. For instance, abiword I guess we can get from:

[hughsie at hughsie-laptop PackageKit]$ rpm -ql abiword  | grep desktop
/usr/share/applications/fedora-abiword.desktop
cat /usr/share/applications/fedora-abiword.desktop
[Desktop Entry]
Exec=abiword
Icon=abiword_48.png
Terminal=false
Type=Application
...

So lets assume we have a wealth of information about _some_ installed
packages (like it's localized name, localized comment, icon etc. How do
we get this information out of the daemon or client? We also have data
available to us from the online desktop people, for stuff like
popularity ratings and that sort of stuff, and also for applications we
haven't yet installed.

I think we need to cache this somewhere, as it's likely to be expensive
to parse, and we need to have a pretty up to date cache for when we want
that simple application installer we keep mentioning. A cache means an
sqlite database, either managed by the client (per-user) or the daemon
(per-system).

I'm erring on this stuff being per-system, as it would suck having to
build a database (i guess taking a few minutes) for each user. Doing it
per-system also means it could tie in with the RefreshCache action which
also takes some time to do and is only scheduled when idle.

This does mean we either have to do one of two banned things:
* Pass the locale into the daemon (ick)
* Pass all the desktop data back to the client in all locales and rely
on the client program to parse it and do something sane.

It also means we have to inject (maybe the wrong word) information that
has to be per-user (like the gnome-online-desktop) data back into the
per-system database. Securely.

And we also need a way to inject all the data that is captured offline
(in a sane way) into the database by adding a PackageKit-data package
with all the desktop files made sane and packaged in a sqlite repo. This
does mean anyone who generates this file needs to have all (and I mean
all) the packages available to the distro and that ship desktop files
installed.

So, comments :-)

Richard.