Wording fix for "Install software to open files?" window

Oh, there are perhaps even more pieces of bad grammar :)

Would you mind to have a look at sessioninstaller/core.py ?

Besides the grammar, there are a few other things in that screenshot that could be made much better:

a. It's impolite to instruct someone to "Select an application" from an empty list. If no installed applications can open the file, just ask if you want to search online.

b. However, you shouldn't be given the choice to search for applications for the "unknown" filetype. That's never going to work!

c. If sessioninstaller *is* told to search for "unknown" handlers by some rogue application, it shouldn't put up any UI, it should just silently fail.

d. Again it's impolite to ask someone if they want to install software from a choice of zero possibilities. If there are no available applications, just show an error message.

c. Okay, maybe just silently failing is a little harsh. :-) Something like "Ubuntu can’t search for applications to open {filename}, because the file type is not recognized.”, with secondary text “File type: {file type}”.

I could edit the strings in core.py myself, but I'd need to know the answers to two questions:
1. How would I include the name of the file in a string?
2. How would I include the OS name, e.g. "Ubuntu", in the string?

For example, "Sorry, %s couldn\u2019t find any applications to open \u201c%s\u201d." % something1, something2

I was hoping that this was a kind of test setup and not a real life screenshot :/

Having a short look at the code I have to admit that the logic of the dialog isn't very good. The case in which a file cannot be opened at all isn't handled. That is why you get this strange dialog.

Unfortunately we don't know the path of the file. Only the human undfriendly mime type, e.g audio/x-mp3. I already implemented some tricks to get a nice name of the requesting application. I could add a test if we cannot get a real world name for mime type, but what to do in this case? Should we point to an Internet site or support platform?

Getting the name of the distro is easy. I could add this to your code changes afterwards: platform.dist()[0]

You can use the test command in the sessioninstaller source code to trigger the dialog yourself:

In a terminal session run: ./session-installer
And in a second one: ./test --install-mime-types "audio/x-mp3 audio/x-ogg"

Specification updated.
<https://wiki.ubuntu.com/SoftwarePackageOperations?action=diff&rev2=21&rev1=20>
<https://wiki.ubuntu.com/SoftwarePackageOperations?action=diff&rev2=23&rev1=22>
Sebastian, how does that look?

I am currently working on a 1.0 release of aptdaemon. Afterwards I will have a look at sessioninstaller.

There is a very akward cornor case: We could find an application that handles the file type but we don't know the file type :) Because knowning the type means to have a human name for the file/mime type only. Should we show the technical definition of the type, e.g. audio/x-mp3 instead?

The PackageKit API allows to specify more than one mime type. So we could end up with the situation in which we don't know only one of the types.

Thanks Sebastian! Currently my sketches in <https://wiki.ubuntu.com/SoftwarePackageOperations#searching> show only Mime types only, not human-readable names for types. I thought that if the OS doesn't have any software installed for a type, probably it doesn't know a human-readable name for the type either. After all, /etc/mime.types includes only Mime types and their corresponding filename suffixes, not human-readable names. (Maybe there is a list with human-readable names somewhere else?)

It would be nice to show the human-readable name as well, if we know it. So, I've defined a "file type string" for use in the UI, being the Mime type, plus the human-readable name in brackets if known. <https://wiki.ubuntu.com/SoftwarePackageOperations?action=diff&rev2=27&rev1=25> Does that look good to you?

Apart from that string, though, whether we know a human-readable name for the Mime type shouldn't make any difference to whether -- or how -- we offer to install an application for that Mime type.

hello mpt,
but how to handle the case of multiple mime types or gstreamer codecs? generally not all applications can support all mime types or codecs. so in this particular case you need to show in the dialog which application supports which mime type. and perhaps which mime type is not supported add all. the test script has an option to search for multiple codecs. if you uninstall the gstreamer bad and ugly plugins you should get an idea and how this is handled currently.

Matthew Paul Thomas <email address hidden> schrieb:

>Thanks Sebastian! Currently my sketches in
><https://wiki.ubuntu.com/SoftwarePackageOperations#searching> show only
>Mime types only, not human-readable names for types. I thought that if
>the OS doesn't have any software installed for a type, probably it
>doesn't know a human-readable name for the type either. After all,
>/etc/mime.types includes only Mime types and their corresponding
>filename suffixes, not human-readable names. (Maybe there is a list
>with
>human-readable names somewhere else?)
>
>It would be nice to show the human-readable name as well, if we know
>it.
>So, I've defined a "file type string" for use in the UI, being the Mime
>type, plus the human-readable name in brackets if known.
><https://wiki.ubuntu.com/SoftwarePackageOperations?action=diff&rev2=27&rev1=25>
>Does that look good to you?
>
>Apart from that string, though, whether we know a human-readable name
>for the Mime type shouldn't make any difference to whether -- or how --
>we offer to install an application for that Mime type.
>
>--
>You received this bug notification because you are subscribed to
>sessioninstaller in Ubuntu.
>https://bugs.launchpad.net/bugs/1125514
>
>Title:
> Wording fix for "Install software to open files?" window
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1125514/+subscriptions

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Sebastian, sorry, I don't understand the question. Are you saying the API lets you search for an application that can open multiple Mime types? E.g. "Find an application that handles both audio/mpeg3 and application/ogg"? If so, what is the use case for that? Thanks.

Am 2013-03-19 09:37, schrieb Matthew Paul Thomas:
> Sebastian, sorry, I don't understand the question. Are you saying the
> API lets you search for an application that can open multiple Mime
> types? E.g. "Find an application that handles both audio/mpeg3 and
> application/ogg"? If so, what is the use case for that? Thanks.

Indeed. You can request a handler or several handlers for multiple mime
types at once. I also cannot imagine a good use case for requesting
several mime type handlers at the same time. But that is the given
design of the PackageKit API that we need to implement here.

The same is true for multimedia codecs - and more obvious: You e.g.
need a handler for the audio stream, the video stream and the container
format. In a cornor case all three handlers are located in separate
packages. There is a small logic in session-installer that pre-selects
the package or the best packages that provide all handlers by default.