Bug 45922 - xlr filetype not associated with Calc
Summary: xlr filetype not associated with Calc
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-11 02:29 UTC by Samuel
Modified: 2013-12-31 16:21 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
XLR Test File (11.50 KB, application/vnd.ms-works)
2012-10-27 08:51 UTC, Samuel Mehrbrodt (CIB)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel 2012-02-11 02:29:45 UTC
.xlr files are spreadsheets created with versions 6-9 of Microsoft Works.
They open in Calc when using the file-open dialog, but the filetype is not associated with Calc (tested on Ubuntu 11.04).
I guess that it's the same on other OS too.

When someone can give me a hint where to start I could try and fix it by myself.
Comment 1 Samuel 2012-03-03 13:55:18 UTC
Can this be an Easy Hack?
Comment 2 sasha.libreoffice 2012-05-17 05:39:47 UTC
Thanks for bugreport
Please, attach small .xlr file for testing purposes
Comment 3 Samuel 2012-08-29 18:21:15 UTC
Well, I cannot create such a file, because I don't have MS Works, but you can find some on the web: www.google.com/search?q=filetype%3Axlr

I also tested this on Windows, it's also not recognized, but can be opened via File->Open.
Comment 4 Caolán McNamara 2012-10-26 22:21:25 UTC
Yeah IMO this is a plausible easy hack.

So here's a sample commit for adding the info that LibO can handle a mime-type so that Linux systems suggest it as a handler for the format

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a7082e3cd9171105d12c65d8364d29680b8d1801

I'm not actually entirely sure what the equivalent for Windows or MacOSX is, but more than likely examining git log sysui will (eventually) show the equivalent mechanism for those platforms. I suggest putting that aside for the moment and just make this the Linux filetype association bug.

Now that I look I do see that "application/vnd.ms-works" which might be the correct mime-type for the format in our  *writer* .desktop file so it might be that the problem is either on the shared-mime-info side which sniffs the filetype or that the mime-type is too broad and messy and it falls through the cracks somewhere (e.g. that all msworks file types share the same mime-type and they get given to writer first and there's no fallback to try calc if that doesn't work)

So to narrow down the specific problem, can you 
a) attach a sample file here
b) right click on it in nautilus and see what mime-type it detects it as ?
Comment 5 Caolán McNamara 2012-10-26 22:29:13 UTC
caolanm->fridrich: I have a feeling that shared-mime-info doesn't know about the format in order to even hand it to LibO in the first place. 

Here's the how-to to add a mime-type to that
http://cgit.freedesktop.org/xdg/shared-mime-info/tree/HACKING#n31
Comment 6 Samuel Mehrbrodt (CIB) 2012-10-27 08:51:35 UTC
Created attachment 69144 [details]
XLR Test File
Comment 7 Samuel Mehrbrodt (CIB) 2012-10-27 09:09:48 UTC
The mime type is application/x-ole-storage (Gnome tells me), but it seems that this is a generic mime type which can be used for different data, see http://searchwinit.techtarget.com/definition/OLE and http://msdn.microsoft.com/en-us/library/ms693383%28v=vs.85%29.aspx

So we might need to look for the mime type AND the file extension (.xlr) to open it correctly?
Comment 8 Caolán McNamara 2012-10-27 14:03:58 UTC
So shared-mime-info is just detecting it as a generic ole container type. So this turns into "teach shared-mime-info to assign .xlr files their correct mime-type". Follow the link above for how to add another.

It might be the case that just adding <glob pattern="*.xlr"/> to the existing 
freedesktop.org.xml.in under the <mime-type type="application/vnd.ms-works"> section is the right thing to do. At which point it will "just work" to double click on it and get it to be opened in LibreOffice with its existing claims in its .desktop files to support application/vnd.ms-works
Comment 9 Samuel Mehrbrodt (CIB) 2012-10-30 09:02:13 UTC
Thanks for the help, I've created a patch for shared-mime-info at https://bugs.freedesktop.org/show_bug.cgi?id=56575 .

How can this be fixed on Windows?
Comment 10 Samuel Mehrbrodt (CIB) 2012-10-30 17:00:29 UTC
application/vnd.ms-works is in Writer's desktop file, should we move it to startcenter.desktop or so because it can also be opened with Impress or Calc.
Comment 11 Caolán McNamara 2012-10-31 16:00:22 UTC
re windows. I don't know how the file associations work there, but I suspect it'll be something in that same sysui module as well.

re which .desktop for the mime-type. Its a nuisance of this mimetype that its shared by the .wps format and the .xlr format. Ideally there'd be two, and we could put one in calc and one in writer. I don't think there's any great solution. If we leave it in the writer .destop and calc is also installed then it should still "just work".
Comment 12 Marcos Souza 2013-04-30 02:52:05 UTC
So, this can be closed now ?

Is the file association working on working now?
Comment 13 Caolán McNamara 2013-04-30 08:40:42 UTC
Yeah, I suppose in theory there's the issue of the windows association, but I don't really know how that works :-)