Proper Mac OS X Applications

All about Mac OS portage
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Proper Mac OS X Applications

Post by asmaloney »

[No board for Mac OS X? Where's the lovin'?]

I want to start by saying I'm in no way familiar with CMake and its magical incantations. I use qmake for most of my work at the moment.

That said, I wanted a double-clickable Mac application, so I figured out how to munge the CMakeLists to make it happen. If there are any CMake gurus out there, I'd love to get this cleaned up so I can submit it.

Main issues to be solved:
* Push the version number into the Info.plist file from CMake
* Only set up for release, not debug
* I'm sure there are features of CMake I'm missing which would make this nicer. Feels pretty yucky at the moment.
* I haven't compiled any of the CC plugins. Don't know if there's anything to do differently for them

Anyone have the experience to help out with this?

Once we get it done for ccViewer, I'll do it for qCC as well so we can have easier-to-use Mac OS X applications.

Edit: Updated the download to fix Info.plist.

- Andy
Attachments
asmaloney - Mac OS X Application.zip
Patch for Mac OS X application
(88.38 KiB) Downloaded 533 times
Last edited by asmaloney on Wed Feb 20, 2013 1:58 pm, edited 1 time in total.
daniel
Site Admin
Posts: 7332
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: Proper Mac OS X Applications

Post by daniel »

Hi,

I'll move this thread to a dedicated board ;)

And I won't be able to help you on this subject, but I have a few remarks:
  • ccViewer doesn't handle plugins (yet) so the qt.conf file shouldn't be necessary. Moreover, qCC don't need it either as we tell Qt where to look (see MainWindow::loadPlugins()).
  • in Info.plist there are references to 'HSProject.icns' and 'Hemospat': is this normal?
Daniel, CloudCompare admin
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Re: Proper Mac OS X Applications

Post by asmaloney »

I'll move this thread to a dedicated board ;)
:-)
ccViewer doesn't handle plugins (yet) so the qt.conf file shouldn't be necessary. Moreover, qCC don't need it either as we tell Qt where to look (see MainWindow::loadPlugins()).
What about the imageformat plugins for Qt? Without them and the qt.conf file, the Mac application will not work. Since we're putting them into the bundle, we need to tell Qt where to find them.

Actually I just found that there's supposed to be a way to get BundleUtilities to create the qt.conf file. I'll look at that.
in Info.plist there are references to 'HSProject.icns' and 'Hemospat': is this normal?
Uh, errr... nope. Sorry about that. I'd copied it from my work. Will fix it in the download above.

- Andy
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Re: Proper Mac OS X Applications

Post by asmaloney »

Getting better...

This one :
  • eliminates the need for extra files - it's all done within CMakeLists.txt
  • pushes the version info into the Info.plist file (version is hard-coded in the CMakeLists.txt file though)
  • cleans up the code based on examples I found around the internets
Despite the quality time spent with CMake, I still am not even remotely efficient or proficient with its magic, so caveat emptor.

- Andy
Attachments
asmaloney - Mac OS X Application.diff.zip
Patch for Mac OS X application bundling
(1.91 KiB) Downloaded 545 times
daniel
Site Admin
Posts: 7332
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: Proper Mac OS X Applications

Post by daniel »

That looks good to me! Can you push it in the github master branch?
Daniel, CloudCompare admin
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Re: Proper Mac OS X Applications

Post by asmaloney »

Sure - will do.

qCC will require something more because of its plugins and shaders. Since the executable will now be in qCC.app/Contents/MacOS, it won't know where to look. So I'll have to change the code to look in the right place.

Should the app be called qCC.app or CloudCompare.app? I would think the latter would be better...
daniel
Site Admin
Posts: 7332
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: Proper Mac OS X Applications

Post by daniel »

Indeed CloudCompare.app seems better if this is what the user will see.
Daniel, CloudCompare admin
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Re: Proper Mac OS X Applications

Post by asmaloney »

I took a look at it briefly and there's something I haven't been able to solve yet. When moving dynamic libs around on Mac OS X, you have to use otool to fix up any hardcoded paths pointing to other libs. This is not so fun, which is why the bundling functions for CMake deals with it for plugins within the bundle.

The problem comes in with custom plugins. They all depend on libs which now reside in CloudCompare.app/Contents/MacOS, so they need their paths fixed. The two solutions - as far as I can see - are (1) throw them in the bundle like the image format plugins, or (2) try to figure out if it's possible to run otool on them separately so they can point at the new location of the other dynamic libs so they can then exist outside the bundle.

(1) Easier and would keep everything in one place, more like a real Mac app. Disadvantage is that, for end users, adding plugins is not as easy - but how often would a user do that? (Incidentally this is what I do with my application.)
(2) Anti-fun and - if possible - users would have to maintain the file structure in order for the application to find the plugins. Applications on the Mac, however, stand alone in /Applications and then point to their data in ~/Library/Application Support, so, to do it "properly" this option would mean putting the plugins there, which means making an installer. Installers on the Mac are evil.

You can tell which one I recommend :-)

...which leads me to shaders.

My suggestion here - since users are more likely to add shaders - would be to include the standard ones within the bundle, and then to add an additional search path to ~/Library/Application Support/CloudCompare/shaders so if the user has custom ones, they can just put them there.

Thoughts?
daniel
Site Admin
Posts: 7332
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: Proper Mac OS X Applications

Post by daniel »

Well, well, well ... clearly the first solution is the best (this is already what we do with the Windows version). And for shaders, it's not like we have many of them yet: qSSAO and qEDL are in fact plugins, and the 'custom shader' import tool doesn't work yet!
Daniel, CloudCompare admin
asmaloney
Posts: 38
Joined: Tue Feb 19, 2013 9:53 pm
Location: Canada
Contact:

Re: Proper Mac OS X Applications

Post by asmaloney »

Alright - I'll look into it.

At minimum it will mean changes to some of the other CMakeLists.txt to put the plugins and shaders in a different place, and changes to the code to look in the right place, so it will be a larger change than with the viewer.

The other thing I noticed is we need to tell Mac OS X what file formats the viewer & cc accept so users can drag and drop files onto them and have cc & viewer show up in the context menu when users right-click a file.

When I have something I'll submit for review through git if that works for you?
Post Reply