File-roller is associated with .docx,.xlsx,.pptx files instead of LibreOffice

I clicked on an .odp file (it has a presentation icon) and it opened in file roller and gave an error that it couldn't read it because it didn't have zip support or something. In any case I never want to open these in file roller. Maybe Evince or Documents. But probably Impress.

Would be best if we could tell the user the app isn't installed and offer the option to get it.

Sounds like this is a problem of file-roller claiming to support zip while it cannot?
What is the relation with shared-mime-info, and why should it be a bug in it?

(In reply to comment #1)
> Sounds like this is a problem of file-roller claiming to support zip while it
> cannot?

Nothing to do with that. OpenOffice documents are zip files with a bunch of files in it. We advertise that fact in shared-mime-info.

file-roller is launched because we don't have LibreOffice or OpenOffice installed so the file manager looks for the next best handler: the zip file handler.

Aside from debugging, it should never be opened within file-roller.

> What is the relation with shared-mime-info, and why should it be a bug in it?

So I think we should just remove the sub-class of zip in this case, but it would probably break mime detection.

(In reply to comment #2)
> (In reply to comment #1)
> > Sounds like this is a problem of file-roller claiming to support zip while it
> > cannot?
>
> Nothing to do with that. OpenOffice documents are zip files with a bunch of
> files in it. We advertise that fact in shared-mime-info.
>
> file-roller is launched because we don't have LibreOffice or OpenOffice
> installed so the file manager looks for the next best handler: the zip file
> handler.

Thanks for the clarification, given the bug description was not clear about it.

> > What is the relation with shared-mime-info, and why should it be a bug in it?
>
> So I think we should just remove the sub-class of zip in this case, but it
> would probably break mime detection.

This sounds like an (ugly) ad-hoc solution just to solve this specific case.
I'm pretty sure there could be (now or in the future) more cases when you want to handle a mime type but not one or more specific subclasses of it, so my suggestion would be discussing it in the xdg ml for a better solution (most probably at application level, out of shared-mime-info).

(In reply to comment #3)
> > So I think we should just remove the sub-class of zip in this case, but it
> > would probably break mime detection.
>
> This sounds like an (ugly) ad-hoc solution just to solve this specific case.
> I'm pretty sure there could be (now or in the future) more cases when you want
> to handle a mime type but not one or more specific subclasses of it, so my
> suggestion would be discussing it in the xdg ml for a better solution (most
> probably at application level, out of shared-mime-info).

What other mime-types have that problem? I can't see any, so it's not that bad a solution.

(In reply to comment #4)
> What other mime-types have that problem?

None, just like the .odp mime has no problem either.

> I can't see any, so it's not that bad a solution.

The solution is bad because the zip inheritance is perfectly fine from a shared-mime-info point of view (it represents mime types, after all).
If the problem is not letting a specific user-level file archiver application see openoffice documents as zip, then let's find an application-level solution for this (and any other potentially similar case in which you want to handle a mimetype but not some mimes inheriting from it, for any reason you want).
I personally don't think there's nothing wrong in having some file archiver opening any kind of zip files, if the user wants to.

(In reply to comment #5)
> (In reply to comment #4)
> > What other mime-types have that problem?
>
> None, just like the .odp mime has no problem either.

It very obviously does otherwise we wouldn't have this bug report.

> > I can't see any, so it's not that bad a solution.
>
> The solution is bad because the zip inheritance is perfectly fine from a
> shared-mime-info point of view (it represents mime types, after all).

Even if it's technically correct, we currently have 2 uses for sub-class-of, either it's a functional sub-class (video/mp4 is a sub-class of video/quicktime, so an app that handles quicktime should handle mp4), or it's a detection sub-class (like in the case of XML and ZIP file based file types).

> If the problem is not letting a specific user-level file archiver application
> see openoffice documents as zip, then let's find an application-level solution
> for this (and any other potentially similar case in which you want to handle a
> mimetype but not some mimes inheriting from it, for any reason you want).
> I personally don't think there's nothing wrong in having some file archiver
> opening any kind of zip files, if the user wants to.

I don't think it's wrong either, and you can still do that by renaming the file to .zip and opening it.

Two years ago, Alexander Larsson mentionned to me (in passing at Desktop Summit) an idea to solve this exact problem: his idea was to introduce the concept of private inheritance in s-m-i, so that one could say "opendocument files inherit privately from zip", i.e. the fact that it's zip is an implementation detail.

We could then have two ways to check if mimetype A inherits from mimetype B: including or excluding private inheritance.

When looking for an application that handles mimetype A (for launching the app), we would exclude it.

But when the application itself would check "is this file's mimetype supported by one of my plugins" then it would include it.

And when a filemanager wants to populate the "right click / open with ..." submenu, it could also include it, so that people could actually launch an archive program to inspect an opendocument file.

Same thing with application/octet-stream: the implied inheritance from all files could be private, so that associating an hex editor with that mimetype doesn't make it launch by default, but makes it available in the "open with..." submenus.

(In reply to comment #7)
> Two years ago, Alexander Larsson mentionned to me (in passing at Desktop
> Summit) an idea to solve this exact problem: his idea was to introduce the
> concept of private inheritance in s-m-i, so that one could say "opendocument
> files inherit privately from zip", i.e. the fact that it's zip is an
> implementation detail.

Fair enough. And I'm guessing this should be worked on in xdgmime first then.

I'm pretty busy with other stuff so I can't work on this atm unfortunately, but I think such private inheritance is a good approach. There are still reasons we want to know e.g. that some document type is really a zip file, but we clearly don't always want to expose the zip:ness of such files.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdgmime/issues/24.