Proper Mac OS X Applications

[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

[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?

[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]

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

[daniel]

That looks good to me! Can you push it in the github master branch?

[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]

Indeed CloudCompare.app seems better if this is what the user will see.

[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]

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!

[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?