Launchpad has imported 11 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=40354.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-08-24T08:21:11+00:00 William Jon McCann wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/0 ------------------------------------------------------------------------ On 2011-08-24T08:27:32+00:00 Pino Toscano wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/1 ------------------------------------------------------------------------ On 2011-08-24T12:37:13+00:00 Bugzilla-x wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/2 ------------------------------------------------------------------------ On 2011-08-24T12:58:52+00:00 Pino Toscano wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/3 ------------------------------------------------------------------------ On 2011-08-24T13:24:25+00:00 Bugzilla-x wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/4 ------------------------------------------------------------------------ On 2011-08-24T13:45:39+00:00 Pino Toscano wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/5 ------------------------------------------------------------------------ On 2011-08-25T01:25:25+00:00 Bugzilla-x wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/6 ------------------------------------------------------------------------ On 2011-08-25T01:43:10+00:00 David Faure wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/7 ------------------------------------------------------------------------ On 2011-08-25T02:12:48+00:00 Bugzilla-x wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/8 ------------------------------------------------------------------------ On 2011-08-25T23:24:40+00:00 Alexander Larsson wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/9 ------------------------------------------------------------------------ On 2018-10-13T10:34:37+00:00 Gitlab-migration wrote: -- 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/desktop-file- utils/+bug/873470/comments/33 ** Changed in: desktop-file-utils Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to desktop-file-utils in Ubuntu. https://bugs.launchpad.net/bugs/873470 Title: File-roller is associated with .docx,.xlsx,.pptx files instead of LibreOffice Status in desktop-file-utils: Unknown Status in desktop-file-utils package in Ubuntu: Fix Released Status in desktop-file-utils source package in Oneiric: Fix Released Bug description: In a fresh oneiric installation, the default association for .docx is file-roller altough file-roller cannot open .docx files and libreoffice is installed. TESTCASE: - download the file from comment #3 - double click on it from nautilus - before the update it opens with file-roller, after the update with libreoffice To manage notifications about this bug go to: https://bugs.launchpad.net/desktop-file-utils/+bug/873470/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
