Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create macos app bundles from build script #2270

Closed
wants to merge 19 commits into from
Closed

Conversation

bjeurissen
Copy link
Member

./build app_bundles

will create the necessary app bundle wrappers for macos

Running a subsequent

./build

will revert to 'normal' binaries.

@maxpietsch
Copy link
Member

maxpietsch commented Feb 1, 2021

App integration seems to work after symlinking to /Applications.

The logic is slightly modified making app bundles persistent: build app bundles if they are requested or if old app bundles exist and if it is necessary to update them because mrview or shview are updated.

I modified build so that scripts that replace the binaries have the same date to avoid needless relinking. While at it, also preventing recreating the app bundles if their binaries did not change.

This allows using plain old ./build without forcing (a subsequent) ./build app_bundle call if app bundles are used.

➜  ./build app_bundles
...
Creating macOS app bundle for mrview
Creating macOS app bundle for shview
➜  touch src/gui/mrview/colourmap_menu.cpp
➜  ./build
(1/2) [CC] tmp/src/gui/mrview/colourmap_menu.o
(2/2) [LB] bin/mrview
Creating macOS app bundle for mrview
➜ ./build
➜  
➜  ./build clean
...
delete app: bin/MRView.app
delete app: bin/SHView.app

@bjeurissen
Copy link
Member Author

Great! Thanks! I was struggling a bit with figuring out the mechanics of the build script...

@maxpietsch
Copy link
Member

How about integrating symlink_app_bundles into set_path?

@bjeurissen
Copy link
Member Author

How about integrating symlink_app_bundles into set_path?

I just had the exact same thought! It avoids clutter...

@maxpietsch
Copy link
Member

Couldn't find documentation so tried it out: If the app exist in both /Applications and in ~/Applications spotlight shows both together with the resolved symbolic link location
image
and double click integration picks up the one in the user's home.

@bjeurissen
Copy link
Member Author

bjeurissen commented Feb 3, 2021

It should work on linux now as well. Tested only on ubuntu 20.04.2.

In summary, what ./set_path now does is:

  • on macos:
    • without -remove
      • add mrtrix bin directory to the PATH variable in the appropriate dot files in ~
      • create symbolic links to mrtrix application bundles in ~/Applications
    • with -remove
      • remove mrtrix bin directory from the PATH variable in the appropriate dot files in ~
      • remove symbolic links to mrtrix application bundles in ~/Applications
  • on linux:
    • without -remove
      • add mrtrix bin directory to the PATH variable in the appropriate dot files in ~
      • run xdg-* install commands
    • with -remove
      • remove mrtrix bin directory from the PATH variable in the appropriate dot files in ~
      • run xdg-* uninstall commands

@bjeurissen
Copy link
Member Author

Couldn't find documentation so tried it out: If the app exist in both /Applications and in ~/Applications spotlight shows both together with the resolved symbolic link location
image
and double click integration picks up the one in the user's home.

Thanks! I think that works out fine!

@bjeurissen
Copy link
Member Author

bjeurissen commented Feb 3, 2021

@jdtournier: one thing I did notice, is that nii.gz and mif.gz are not handled on Linux, despite them being mentioned in the XML file. Is this supposed to work?

It is not handled on macos either, apart from being able to right click .gz files and choosing to open them with mrview, because I also registered .gz.

@jdtournier
Copy link
Member

OK, running ./set_path works on Linux as far as I can tell. I don't get the right icons in the file manager for the .nii.gz files, but that's presumably because the .gz mime types overrides that. It does open correctly in mrview though, so that's good.

What doesn't work is running ./set_path remove. Nothing seems to happen: the PATH is still there in ~/.bashrc, the icons are still registered, the mime types are still listed, and the mrview application is also still available. But the output suggests this should all have been dealt with. Not sure what's going on...

@bjeurissen
Copy link
Member Author

What doesn't work is running ./set_path remove. Nothing seems to happen: the PATH is still there in ~/.bashrc, the icons are still registered, the mime types are still listed, and the mrview application is also still available. But the output suggests this should all have been dealt with. Not sure what's going on...

it should be ./set_path -remove. ./set_path remove will add the PATH info to the file remove

@bjeurissen
Copy link
Member Author

OK, running ./set_path works on Linux as far as I can tell. I don't get the right icons in the file manager for the .nii.gz files, but that's presumably because the .gz mime types overrides that. It does open correctly in mrview though, so that's good.

If you double-click a nii.gz it opens in mrview? That does not happen on my ubuntu installation. I just opens in archive manager... And there is also no option to right-click and choose MRview like there is on macos. Where could these different behaviors originate from?

@jdtournier
Copy link
Member

What desktop environment are you running in? I'm on Gnome 3.38, and that offers a right-click option to open with another application...

@jdtournier
Copy link
Member

it should be ./set_path -remove. ./set_path remove will add the PATH info to the file remove

🤦

Everything works perfect... Only suggestion is to somehow document how to use the command. Not sure how best to do this, but obvious thing would be to print out purpose and usage with anything that looks like the -help option...?

@bjeurissen
Copy link
Member Author

bjeurissen commented Feb 3, 2021

What desktop environment are you running in? I'm on Gnome 3.38, and that offers a right-click option to open with another application...

Gnome 3.36.8. I have that option, but then I have to manually select MRview from the list of applications

@jdtournier
Copy link
Member

I have to manually select MRview from the list of applications

I did too, the first time. But presumably you only have to set this once, right?

@Lestropie
Copy link
Member

With the increased scope of set_path, is "set_path" still an appropriate name? It's starting to look more like an "installation" of sorts...

@jdtournier
Copy link
Member

Yes, you're right that set_path no longer reflects all it does. Not sure we should rename it to anything that suggests installation as such though - I'd take that as suggesting copying the executables into some standard location, whereas this script leaves them in place. It's more like 'registering' the software with the system. Not sure what term would be appropriate here...

@bjeurissen
Copy link
Member Author

bjeurissen commented Feb 4, 2021

On my ubuntu system, this is placed on my desktop:

Screenshot from 2021-02-04 13-08-37

But it does not use the right icon and when I click it, it just opens in a text editor. This is not supposed to happen, right?

That said, I don't like it when stuff is added to my desktop, so could we just drop the xdg-desktop-icon call? Still puzzled why it does not work though ...

@jdtournier
Copy link
Member

OK, I don't see any icons on my desktop since GNOME shell running on Wayland doesn't support showing them... Must say I've not really missed them, but it does mean I'd not noticed this as a problem. You could easily ditch the xdg-desktop-icon call, the important one is the xdg-desktop-menu call, I think.

@bjeurissen
Copy link
Member Author

OK, I don't see any icons on my desktop since GNOME shell running on Wayland doesn't support showing them... Must say I've not really missed them, but it does mean I'd not noticed this as a problem. You could easily ditch the xdg-desktop-icon call, the important one is the xdg-desktop-menu call, I think.

Yes, and that one works :)

@bjeurissen
Copy link
Member Author

Just tested with latest dev and seems to be in pretty good shape (especially thanks to the commits by @maxpietsch)!

Maybe still requires a few linux users double checking that ./set_path operates as expected. I agree that the name set_path is not ideal, but keeping it is also convenient.

Also, I was thinking we could remove the app_bundles option and always enable the mode when building for macOS.

@daljit46
Copy link
Member

daljit46 commented Jun 7, 2024

Closing since #2739 was merged.

@daljit46 daljit46 closed this Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants