On Fri, 2007-10-12 at 15:45 +0100, Ricardo Cruz wrote:

The mockup looks great, thanks. Christian Jäger also suggested the use of icons. However, I am afraid we can only hack that for installed software. Zypp downloads a file from the repos that has some informations about the packages (names, descriptions, ...), but it doesn't have an inlined icon -- it doesn't even have all the RPM header info. We would need to download the entire package to extract that information. What we can do, for the available packages, is to use the icon of the group they belong to. E.g. for bombermaze, I guess the games/action.

# I could imagine a stacked icon retrieval algo.; top to bottom: - Use the "icon" property supplied by package tag from zypper/metadata (described below) - Use GNOME icon lookup interface with specific package name - Package Category's icon (Icon naming spec gives us appropriate icons) - Use generic icon for application/x-rpm Of course the biggest challenge are icons for not installed packages. An idea to solve this... # Get icon metadata from packager up to the software stack: - .spec files allow "Icon:" tags, let's put them to use to specify an icon name for a package - Generated repository metadata gets "icon" attribute which is read from the .spec file - Zypper gets "icon" attribute support in the API - Packagemanager is able to use/read the "icon" information (which now comes all the way from the .spec file) and use it in the icon lookup process While this would add the ability for packagers to specify an "Icon:" tag with a name according to the icon naming spec and thus at least already gain a good set of icons to use, it still would not work for completely custom icons. # External icons Here, we would require to get those from some place in the internets. I think one solution would be to extend the "Icon:" tag to be able to specify names, filenames and URLs so the build process might pull the appropriate images into the final repository (probably the repodata/ or src/ directory renamed according to the package). If the icons are put in some directory in the repository they could be accessible from the createrepo generated html pages, from within the build service's package listings or even some supergeeky AJAX frontend (oh, like http://software.opensuse.org/search/) Again, just an idea and for sure needs a final specification to become reality.

We already have exchanged some ideas privately about the interface. You guys can start a public discussion, if you wish. We'll certainly listen to the feedback. Maybe during next week I can start working on it; before changing the interface, I will want to re-work the code to support for this, which can take more time.

Some stuff we need: * support for filters. Besides the name search, we need filtering based on statuses and repositories. Would be great if they could be used together. Maybe have a left pane for them, hiding them with expanders by default (the search would always be visible of course).

I think as soon as filters are added the two pane package management becomes obsolete in my eyes. No doubt they are needed and to be hidden by default for less than rookie users.

* browse. Whenever the user wants to check out what other word processor (to give an example) are available, browsing is more reliable than search, that can miss something. So, browse should really be a first class citizen. Maybe we could have it together with search, on the filters pane, though it makes only sense for packages. Anyway, we probably want something external like yast-qt has, because it gives more flexibility to the user to list all Server Programs, without having to go through all nodes. And we really need icons for the browser, to make it easier to navigate.

Browsing wins. ;) Perhaps the optimal useability might be achieved with making the package selection "filebrowser" like. Folders are categories/patterns/languages and files correspond to packages.

* dedicated interface for upgrading. We need to give the user more information on the upgrades (and downgrades) available. A nice extra could be doing a diff between the installed ChangeLog and the available one, so the user can check easily what's new. (they aren't very nice). Maybe an extra Upgrade tab page (or Version) should be available when a package has multiple versions.

That would be nice. Anyways, keep up the great work. --- Martin -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org