mrmekon / fruitbasket Goto Github PK

See my fork. My primary usage was to bundle another executable, rather than bundling the current executable and then immediately launching the bundle. This is because I want to distribute a rust program to mac users in the form of a .app bundle. The current API requires the end user to run an executable (instead of .app).

My fork above moves the src_exe variable in self_bundle() and build() to the function's parameters. The code that immediately launches the bundle is now from a method of FruitApp instead of Trampoline.

The code for the bundler program would be like:

fn main() {
    fruitbasket::Trampoline::new("myapp", "myapp", "com.me.myapp")
    .resource(icon)
    .self_bundle("path/to/myapp", fruitbasket::InstallDir::Custom("dist".to_string()))
    .unwrap();
}

When the bundler program is run, it will bundle the myapp executable into a .app, which can be double clicked to launch.

The main app needs to be modified like this so that the resource path can be accessed etc:

fn main() {
    let app = fruitbasket::FruitApp::new();
    let bundle_path = std::path::Path::new("dist/myapp.app");
    fruitbasket::FruitApp::launch_bundle(bundle_path);

    let path = fruitbasket::FruitApp::bundled_resource_path("icon", "");
    original_main(path);

    fruitbasket::FruitApp::terminate(0);
}

I think letting the user to pass in src_exe will make this library more flexible - it's up to them if they want to bundle the current executable or another executable. Please let me know your thoughts on this.

Hello!
Would it be possible to publish the most recent version on crates.io if it's considered stable enough? I depend on this crate for handling file open functionality on Mac OS (woelper/oculante#16) and would be very happy if I could remove the git dependency! Thanks in advance!

Currently, HiDPI support can be declared to macOS by specifying two properties in the plist:

	.plist_key("NSHighResolutionCapable", "True")
	.plist_key("NSPrincipleClass", "NSApplication")

Without these two properties, macOS will default to displaying your application in 1x mode and scaling it up on Retina displays. This makes it really blurry and honestly looks bad.

Compare this, the default:

To this, with the properties:

As you can see, there is a shockingly large difference between the two, and the first one definitely doesn't look very appealing.

Even though fruitbasket is not itself a GUI library, it's still used in applications that do use GUI libraries, so perhaps there should be a method in the builder specifically for this. Something like fn hidpi(&mut self, doit: bool). You'd be hard-pressed to find a Mac without a Retina display these days, and not everyone knows the HiDPI trick.

What are your thoughts on this? Is this within the scope of fruitbasket to provide these convenience methods, even though they have nothing to do with fruitbasket itself? I'd argue that it is, since fruitbasket is intended to bootstrap applications that often need these properties, but I'd love to hear your thoughts on the matter.

v0.8.0 is currently broken on stable, due to afcb6df. Can a new version be published to make this change go live?

I just ran into an issue and it took me a while to figure out what was happening. In #15, @mrmekon helpfully points out that output from the child process is not piped to the original stdout/stderr of the parent process, which causes the output to essentially be lost. Debug prints cannot be seen when launching from IntelliJ, since the app is handed off to macOS and then the parent process terminated.

I'm opening this issue to both represent the issue I just had, and act as something for their pull request to close, because it's always nice to close a real issue with a pull request :D

Hi! First off, awesome crate - thanks so much for making it.

I want to register a custom URI protocol to my app (i.e. CFBundleURLTypes), but the plist api in fruitbasket doesn't appear to support this directly, or by allowing arrays instead of just strings.
https://github.com/mrmekon/fruitbasket/blob/master/src/osx.rs#L380

Basically, I need to represent something like this:

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>My Proto</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>myproto</string>
        </array>
    </dict>
</array>

Do you have ideas on the best way to go about this?

2020-07-13 10:51:35.982 rust-fruitbasket-test[5183:19013837] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 2. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
2020-07-13 10:51:35.982 rust-fruitbasket-test[5183:19013837] There was an error parsing the Info.plist for the bundle at URL <0x7fee68001320>: NSCocoaErrorDomain - 3840

This happens when you use spaces in the name. Fruitbasket doesn't quote the name in the plist, causing the parser to get confused. When there are no spaces in the name, the plist parser doesn't get confused. When you put double quotes in the name (as in "\"Fruitbasket Test\"") it doesn't get confused because it's quoted in the plist, but then it names the app bundle with those quotes as well.

This is actually more of a question, but I am very happy to contribute an example once I can work out if this is possible.
There is already a nice example how to register URL callbacks, but I am unable to find a way to register and handle opening filetypes.

I've read https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/DocumentInteraction_TopicsForIOS/Articles/RegisteringtheFileTypesYourAppSupports.html#//apple_ref/doc/uid/TP40010411-SW1 and believe I can add all the relevant plist entries, but I am unsure about actually handling application:openFile: events. Would this be something that is possible using fruitbasket?

I believe it would be helpful to have a core-foundation example (as in, that one project created solely for Servo's use, but that is also useful for general purposes) as those are the bindings I plan on using for my own projects.

As those seem to be the only bindings out there for macOS (as far as I know), it's only natural that it's what you'd use after fruitbasket, in my opinion. (assuming you're directly making a native macOS app)

It may still be a little opinionated, but I would like to request an example showing how to use core-foundation with fruitbasket.

I've been checking out this x-platform image viewer on a Mac and it has a peculiar issue: you can register it as a PNG file handler, and it works for the first image, but then if the app is already opened, you can't open a second PNG file, it shows a warning window instead, complaining that "App cannot open files in the “PNG image format”"

woelper/oculante#33

Do you have an example of a Mac app that uses your framework and is able to register itself successfully as the default document type handler? That might help the dev find out what's wrong with his app
Or maybe you have an idea what's wrong :)

Thanks