Fredag den 19. marts 2010 10:26:05 skrev Lubos Lunak:

On Thursday 18 of March 2010, todd rme wrote:

...

On Thu, Mar 18, 2010 at 5:30 AM, Lubos Lunak wrote:

...

... There is a reason why adding community repositories in Yast fetches a list of those from a 3rd party site and knows nothing else than the URL of that list. Yes, this all sucks. ...

Could doing this be the solution? The program would have a trusted third-party list of file types and associated package repositories that the program would download periodically and check against.

That is very similar to "MP3 support is missing, press Yes to install it from Packman", so as I said, unlikely.

Maybe we could just use the "let me google that for you"-service. Say the user tries to play an mp3, a dialog appears, "You don't have support for the patent encumbered mp3 format installed. Let me google that for you - http://lmgtfy.com/?q=opensuse+mp3 " >:-) </troll> -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Freitag, 19. März 2010 11:50:22 schrieb Александр Мелентьев:

...

Lubos Lunak: That is very similar to "MP3 support is missing, press Yes to install it from Packman", so as I said, unlikely.

Then OK, let's write " support is not available due to patent issues, for more information, see http://en.opensuse.org/Restricted_Formats". Is that OK with the law? But one-click install of codecs and stuff is only three clicks away from there =)

That sounds good to me, but has it really been that big of a showstopper?

Other distributions use on-demand install of codecs succesfully. What are the real objections of lawyers to the user's "I wanna listen this damn MP3, gimme the package and shut up!" position expressed in a yes/no dialog? )) And what is average nonUS-user reaction to "We will not give you direct link to Packman, cause you want to break the US law"?

Fedora Mandriva and openSUSE don't do that because they are quite entangled with their big sponsors which derivate from and contribute to the community spins. The sponsors have a big share of money in it they don't want to risk for something that easily "fixed". AFAIK in Ubuntu you need to activate the Universe repository which is just pulled in by debian and not touched by canonical, as most of the stuff in Ubuntu, but let's not drift off =) So what's left are distributions where there is nothing to gain from pursuing mp3 (etc) licences except a bad reputation, Arch Linux, Debian, Gentoo etc, so they just do what the community repositories do on Fedora Mandriva openSUSE, be so "unimportant" to the big picture nobody expects any revenue from these sources. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Fri, Mar 19, 2010 at 5:26 AM, Lubos Lunak wrote:

On Thursday 18 of March 2010, todd rme wrote:

...

On Thu, Mar 18, 2010 at 5:30 AM, Lubos Lunak wrote:

...

... There is a reason why adding community repositories in Yast fetches a list of those from a 3rd party site and knows nothing else than the URL of that list. Yes, this all sucks. ...

Could doing this be the solution?  The program would have a trusted third-party list of file types and associated package repositories that the program would download periodically and check against.

 That is very similar to "MP3 support is missing, press Yes to install it from Packman", so as I said, unlikely.

I guess I don't understand why it is okay to do this for the repositories containing the restricted codecs, but not okay for the codecs themselves.

...

Alternatively, you could provide a program that detects something is missing, and third-party repositories could provide packages that add a list of what they could provide.  So when you are missing MP3 support, the software will query the lists provided by the repositories and grab the package that provides that capability.  So, for instance, packman could provide a "package-detection-lists" rpm that installs a list of media types it can provide, and the KDE program consults that list (along with similar lists from other repos) when it detects a problem.  If multiple repositories provide the same capability, the zypper solver would have to take over.

 I don't see how this could solve the problems I described. Repositories already offer a list of packages that they provide, and this list is used when the repository is added e.g. in yast. But before it's added, this information cannot be read, so it doesn't solve anything. The same way we cannot install by default a rpm provided by Packman.

It is useful because it is often not obvious which package contains the codec or file reader necessary to open a given file. This is especially true with video containers, where it might be impossible without opening a metadata editing program to view the contents of the container. The method I describe requires people add the repository, but it is a lot easier than having to open a meta-data editor and then hunt through the repository to find the package you need just to open some random video. I guess it could also be set up to query the repositories listed in the "community repositories" list for their lists of provided codecs, then add those repositories. Or it could just prompt you to add repositories from the community repository list. I'm not sure what would and would not be allowed.

...

It might even be possible to set up so that when you add a repository it automatically queries the repository for this list and installs it if it is available (updating it along with repository updates if it has changed).

 I don't understand this either. When the repository is added in yast, the problem is already basically solved.

The problem of matching a given package to a given file you want to open is not solved unless you know a lot about the files and file formats in question. It is only solved if you know that the rmvb and wmv codecs are in w32codecs-all, for instance. As another example, you need to know a random avi movie trailer you downloaded contains an h263 video stream and aac audio stream, and that you need the x264-72 and faad codecs to play it. Similarly, you need to know which version, and which other software, your media player needs to play it (is it gstreamer based, xine based, phonon based, mplayer based, is x264 pulled by good, good extra, bad, or ugly gstreamer packages, etc). This would eliminate that problem, the OS would know what program or programs it needs to install to play the file and will install them automatically. It is also desktop environment-independent. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Freitag, 19. März 2010 10:37:03 schrieb Karsten König:

After adding the packman repository and updating you can basicly play anything you throw at the multimedia player of your choice, and not even bother about a "codec pack" or similar obscurities under windows.

what I personally like best about how that works in linux is that you can come up with combinations of container, video codec, audio codec, and subtitle format, that would make ANY windows installation just scream "WTF are you doing!" at you... and on linux it simply plays. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Monday 22 of March 2010, Christian Trippe wrote:

Hello,

I installed the packages from home:llunak:ksuseinstall. What I have discovered so far:

2.) Today I wanted to have a look at zypper.log before I attached it to a bug report. So I clicked on it in Dolphin with the expectation that it is opened with kwrite, but I got a dialog containing

There is an application installed that can also open file of the type text/x- log, but there is no specialized application for this file type. Do you want to try to install it?

Yes/No

I was not sure what specialized application would exist for this case, but I thought "Let's try it out."

This is a problem with mimetypes :(. Each mimetype can be a subclass of another one. For example, here text/x-log is a subclass of text/plain, because a log is basically a text file, so everything you can do with text/plain you can do also with text/x-log. Opening text/x-log with KWrite is perfectly fine. The problem is for example with application/x-kvtml, which is a file containing words for KWordQuiz. It claims to be a subclass of application/xml, since it is an XML file. The problem is, handlers for application/xml are apps like Konqueror or KWrite, but you certainly are not interested in .kvtml files to be opened in them, you want them opened with KWordQuiz. That's what "specialized application" means, suggestions for better wording are welcome. For 11.3 I do not see a better option than whitelisting cases where subclassing is ok for this purpose.

End after this

The software to install could not be found in the currently enabled software repositories.It could be possibly located in additional repositories. Do you want to configure your repositories?

Yes/No

Choosing Yes launched yast2 repositories

And left me with no clue about which repo to add and which package to install. This is not so nice.

I know, and I don't know how to do that better. I mean, in this specific case KWrite should have been simply used, but assume you clicked on a file that doesn't have any application for it in the default repositories. How can this be any better when the code simply doesn't know where the app may be, if at all?

However this dialog will appear every time I try to open a .log file. It would be nice to have an option to disable the dialog

I have a don't-ask-again in my TODO. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Thursday 25 of March 2010, Christian Trippe wrote:

Am Donnerstag, 25. März 2010 12:07:51 schrieb Lubos Lunak:

...

On Monday 22 of March 2010, Christian Trippe wrote:

...

And left me with no clue about which repo to add and which package to install. This is not so nice.

I know, and I don't know how to do that better. I mean, in this specific case KWrite should have been simply used, but assume you clicked on a file that doesn't have any application for it in the default repositories. How can this be any better when the code simply doesn't know where the app may be, if at all?

Ok, maybe a minor improvement would be to change the sentence "Do you want to try to install it?" to "Do you want to try to install one?" in the first dialog.

Ok.

One other thing that came to my mind. How is the application for this mime type determined and searched.

Try e.g. "zypper what-provides 'mimetype(text/html)'". Rpm includes a script which creates such provides from .desktop files of applications.

Maybe one could use webpin via (yast2-packager- webpin), which more or less searches the whole obs and packman as far as I understood instead of the yast repositories module. However it might be dangerous to offer a direct link to something which searches the whole obs.

That cannot search for provides, and yes, I think it's too risky (I bet it'd be tempting for somebody to create another libxine1-codecs just to see how many clueless users would install it from random source). -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Tuesday 06 of April 2010, Christian Trippe wrote:

Today I clicked on a po file and as expected the new mimetype dialog appeared. The search was successful and gave me the option to install gtranslator from contrib. I would have expected that lokalize would be offered for installation

So my question is how is the package determined which gets installed if there are several possibilities? And would it be useful (and possible) to prefer KDE packages?

Currently it just picks the first one. I know that's not optimal. I originally planned to come up with a dialog offering choice if there would be more hits, but freezes are getting close :-/. Maybe the code can select depending on what the packages need (to prefer KDE apps), but that would e.g. break with OpenOffice not being preferred to KOffice even though it probably should be. What would you (ideally and realistically) expect to happen in such cases? -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Donnerstag, 25. März 2010 12:07:51 schrieb Lubos Lunak:

On Monday 22 of March 2010, Christian Trippe wrote: This is a problem with mimetypes :(. Each mimetype can be a subclass of another one. For example, here text/x-log is a subclass of text/plain, because a log is basically a text file, so everything you can do with text/plain you can do also with text/x-log. Opening text/x-log with KWrite is perfectly fine.

The problem is for example with application/x-kvtml, which is a file containing words for KWordQuiz. It claims to be a subclass of application/xml, since it is an XML file. The problem is, handlers for application/xml are apps like Konqueror or KWrite, but you certainly are not interested in .kvtml files to be opened in them, you want them opened with KWordQuiz. That's what "specialized application" means, suggestions for better wording are welcome.

For 11.3 I do not see a better option than whitelisting cases where subclassing is ok for this purpose.

I have now done a quick test of of files in my home directory to test if the on-demand package installation is started and if it manages to find a specialized application. For the cases where the search was not successful and white-listing might be useful I created a bugreport https://bugzilla.novell.com/show_bug.cgi?id=592003 Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Tuesday 30 of March 2010, Martin Schlander wrote:

Overall it seems very helpful. People often think their sound is broken when Amarok can't play MP3s - this should put an end to that.

I miss similar checks for Kaffeine (or whatever will be the 11.3 default video player) like what Amarok has - checking for libxine1-codecs and libdvdcss or something like that.

I'll check and try to add a hook there too.

When the codecs are missing, and no proper repo is already added, ksuseinstall launches 'yast2 repositories' base module - this it not really helpful. I wonder if it's somehow possible to launch the list of community repositories directly - otherwise I think it would prolly be better just to send people to google or similar with 'opensuse codecs' or 'opensuse [file extension]' or something like that.

This is difficult. I'll see if it is possible to add a link to a wiki page there.

And finally. There was a typo in the warning dialog for amarok when no mp3 support was present. Don't remember the exact sentence, but a space was missing after a fullstop :-)

I do not see any problem there. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Saturday 17 of April 2010, Cristian Morales Vega wrote:

2010/3/18 Lubos Lunak :

...

 Hello,

 in OBS in home:llunak:ksuseinstall there are packages branched from KDE:KDE4:Factory:Desktop that have one experimental feature added: When a needed package is not installed, the user is offered its installation. Currently there is support for debuginfo packages, applications that can open a specific file type if none is installed and multimedia codecs for Amarok. The plan is that this feature makes it into 11.3, so please test and provide feedback.

Not sure if it's the same thing, but I think you have feedback here -> http://forums.opensuse.org/get-help-here/applications/437270-install-additi onal-software-check.html

I think I've fixed in KKFD all the problems mentioned in the post, thanks. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org