[packagekit] gpk-install-mime-type - order of items listed ?

[David Timms]

On 07/04/10 00:09, Richard Hughes wrote:
> On 6 April 2010 12:53, David Timms<dtimms at iinet.net.au>  wrote:
>> What is the logic behind the order of items listed when you run eg:
>> gpk-install-mime-type application/x-shockwave-flash
>> Is this just random ?
>> It's not in alpha of title nor package name.
>
> Yes, I'm pretty sure it's just random at the moment. It would be a few
> lines to sort it by name, although that get a bit political... GNOME
> then KDE...
And any specific package might still end up being the first in the list 
! I agree with the potential of the political statement.

Here is a small plan:
1. Could we provide "column sorter" buttons/UI so that we can sort by 
either the packagename or summary (what about most recently added to the 
repository, and most recently updated, longest time in repository ;-) ) ?

2. We highlight a default selection only when there is just 1x entry 
returned. Make the user read at least a little, and make a decision.

3. Once an item is selected, show the full package description (or have 
"show description" button to click), this can help the user make a good 
choice. In this case, I would add to the description the -play 
capability limitations.

4. My particular user/bug reporter I think thought that all the packages 
listed in the dialog would be installed. But only one will be. Could we 
make it so that multi-select is possible - eg then in one click they 
could install multiple packages, and then try them out.

Actually for the multiple install. Perhaps the helper could install the 
first, and as soon as that is ready, trigger opening in that 
application, while downloading and installing the remainder. When the 
first application is closed (or crashes!) the helper could ask do you 
want to keep the first app you tried installed ? ...
Then ask and trigger loading the file with the second package etc ...


Anything past this would need additional "scored" metadata, like most 
installed, most highly rated, most bugs !, most used !. I think a 
discussion in the f-devel past came to conclusion that packages should 
fight on their own merits, rather than be subject to user voting 
systems, where there is always the possibility of fraudulent voting, and 
also most installed didn't really mean anything, since some people just 
install everything and never use it....

>> How could we improve this to help the user choose an application that will
>> actually work ?
>
> Well, that's a very hard problem, any ideas welcome. Maybe we should
> restrict it to packages with a desktop file?
Well, mine has a couple of desktop files. These aren't the show it in 
the GUI menu type, but rather the "I handle this mime type" type (but 
I'm not a GUI application - I do not have a menu where you can choose 
which file to open). Yet if you right click one of my associated files, 
you will get a open in "vnc2swf Screen Recorder viewer" entry, which 
will play back the clip.

In fact I was hoping to make more packages that provide useful but CLI 
only triggered / visible apps more accessible to GUI users. tnef (a ms 
lookout attachment decoder) is one.

David Timms.