On Sun, Mar 16, 2003 at 03:44:58PM +0100, Casper Gielen wrote: > > This is tempting, but the package selection menus are focused in > > browsing available system features (packages), while launcher > > menus are focused in browsing available user applications. > > The task is different, so we should pay attention at the risk of > > using a solution which is unique, but suboptimal for both. > I disagree. If a user wants to do a task, he will look in the same way wether > he wants to execute the programm, or wants to install it. It might be > usefull to have different views of the data, depending on if your installing > or running software, but it should be based of the same data. I didn't say that the data should be different, only that the tasks are, so we should pay attention. I'm trying to find a scenario in which cathegory data could be different between packages and applications. The first that comes in my mind is a package providing two applications that address two different tasks. However the idea of having a single cathegory database is sound, because assigning cathegories to a package corresponds to highlighting some of its qualities; those qualities belong to the software itself, and not specifically to the package or the installed application. These cathegories will then need to be filtered to create the different views for the different contexts of usage. At the moment I can't figure out a way to implement these views, that is not explicitly providing the different set of tags for each one. Can you think of some way to implement multiple cathegory views, by exploiting and reusing the data from a unique cathegory database? Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
Attachment:
pgpehUXProtFe.pgp
Description: PGP signature