Bug 74011 - BASIC: LibreOffice app uses some nonstandard to launch itself on OS X
Summary: BASIC: LibreOffice app uses some nonstandard to launch itself on OS X
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-24 10:11 UTC by mircea
Modified: 2014-02-22 15:12 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mircea 2014-01-24 10:11:24 UTC
Problem description: 

LibreOffice is all about freedom of choice. We are using it to slowly migrate from Windows systems to OS X. We are using Parallels Desktop to virtualize the Windows environment inside OS X. This vm software included a feature that maps all you OS X apps to small apps inside windows vm. When you double click a .odt file in windows it automatically launches that file in OS X.

Parallels Desktop recursively scans the Applications folder on OS X to build the app links inside the vm. However it is unable to detect LibreOffice as a "valid" os x app and map it to the vm.

I've looked into "Show package contents" inside LibreOffice app and this is true, the insides look totally different than you average Apple app. For example I can't find the LibreOffice binary inside Contents\MacOS\

Steps to reproduce:
1. Install Parallels Desktop
2. Install a windows vm.
3. Enable share mac os applications with windows.

Current behavior:
App uses nonstandard ways of launching itself.

Expected behavior:
There should be some kind of binary in LibreOffice\Contents\MacOS\
              
Operating System: Mac OS X
Version: 4.1.4.2 release
Comment 1 Stephan Bergmann 2014-01-24 11:53:04 UTC
No idea what (if any) the requirements for the executable's name in FOO.app/Contents/MacOS/ are (I guess that's handled by some info.plist anyway), but for historic and backwards-compatibility reasons the relevant executable is named LibreOffice.app/Contents/MacOS/soffice (and starting it via "open LibreOffice.app" or Finder click on LibreOffice.app does work, so whatever is necessary to set this up seems to be done).
Comment 2 mircea 2014-01-24 22:38:25 UTC
You are right. I've checked for the binary and it's still there. 

I don't know what Parallels Desktop is looking for when scanning recursively throughout the Applications folder. All i can say is that all other apps seem to pass the test with flying colors and parallels desktop then creates a small executable inside the vm. You can ise this file to "open with" and select it. 

When you do this, the vm file is opened in the mac app you chose. 

I filed a support request with parallels desktop support team maybe they can shine some light as to why neither LibreOffice nor OpenOffice work while all other apps do. Will get back to you with their response. 

PS. Compared info.plist from Libreoffice with an info.plist from pages and numbers or another app. Main fields are there but a lot of other one are missing.
Comment 3 Niklas Johansson 2014-02-22 15:12:59 UTC
I got the following mail from Mircea:

> Ok. I have news on the subject. Their second level support and developers seem to be aware of the issues and planning a fix. Other apps are affected as well, including native mac apps.
>
> Libreoffice is off the hook. No bug here.

Thus I'm now closing this as Not our bug. Please feel free to reopen this bug if you find out that we do have a bug related to this.