The README.md should be updated with a sentence or paragraph explaining just a little bit why this repository is deprecated (i.e., what is to replace it) and why abandon this repository’s approach to a projection of Objective C’s framework-API to Rust.

I was looking at the code and only found clearColor. However, I'd like the ability to use custom colors (to change the title bar on OSX).

I can implement this probably if you point me in the right direction.

Getting started with cocoa-rs as an experienced Objective-C Cocoa developer, I tried to modify the example at https://github.com/servo/cocoa-rs/blob/master/examples/hello_world.rs with multiple window style masks, converting the combined value to NSUInteger:

// create Window
let windowStyleMask = NSTitledWindowMask|
                        NSClosableWindowMask|
                        NSMiniaturizableWindowMask|
                        NSResizableWindowMask|
                        NSUnifiedTitleAndToolbarWindowMask|
                        NSFullSizeContentViewWindowMask as NSUInteger;

let window = NSWindow::alloc(nil)
    .initWithContentRect_styleMask_backing_defer_(NSRect::new(NSPoint::new(0., 0.),
                                                                NSSize::new(200., 200.)),
                                                    windowStyleMask,
                                                    NSBackingStoreBuffered,
                                                    NO)

Of course, this didn't work. I feel that cocoa-rs should strive to offer idiomatic interfaces wherever possible, so I looked into the implementation and feel that an elegant approach that preserves strong type information is possible.

https://developer.apple.com/reference/appkit/nsstatusbar/1530619-systemstatusbar?language=objc

extern crate cocoa;

use cocoa::appkit::NSStatusBar;
use cocoa::base::nil;

fn main() {
    unsafe {
        let _ = NSStatusBar::systemStatusBar(nil);
    }
}

> cargo run
   Compiling mac-menu-bar v0.1.0 (file:///Users/corey/dev/rust-mac-menu-bar)
    Finished debug [unoptimized + debuginfo] target(s) in 0.30 secs
     Running `target/debug/mac-menu-bar`
Assertion failed: (CGAtomicGet(&is_initialized)), function CGSConnectionByID, file Services/Connection/CGSConnection.c, line 127.

To use layers in a cocoa application, the application needs to be linked to QuartzCore. What would it take to get that to work?

See https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreAnimation_guide/SettingUpLayerObjects/SettingUpLayerObjects.html

When i press the Quote key, the NSEvent created returns empty string whe calling the characters function.

I'm using:
OS: MacOS Sierra
Keyboard: U.S. International - PC keyboard layout
Rust: from rustup -> rustc 1.19.0 (0ade33941 2017-07-17)

Should it consist only of Cocoa.framework or should/can it bind to all of the OS X SDK?

I'm attempting to run the "hello world" example on OS X 10.10.5. It compiles and runs, resulting in a little window with a "Hello World!" title, but the menu bar doesn't appear: I still have the iTerm menu at the top of the screen. I can Cmd-Tab switch away from and back to the example, but the menu still doesn't appear.

Is this only known to work correctly on certain versions of OS X?

Hi,
I am trying to find some types and I am not sure if they are missing or if I just can't find them.
I am looking for:

• NSURL
• NSModalResponse

Seems a lot of assumptions are made about the widths of certain types that make many usages of the library throw errors when building for 32-bit. For example, nextEventMatchingMask_untilDate_inMode_dequeue_'s mask parameter takes an NSInteger (

This causes, for example, https://github.com/tomaka/glutin to fail to compile under 32-bit rust-windowing/glutin#803 at least, and there may be more errors lurking around in there that this causes.

Right now rust-cocoa defines some CG types (CGFloat, CGPoint, CGLContextObj etc.). Most of these are also defined in the servo/rust-core-graphics repo. Should rust-cocoa not depend on rust-core-graphics instead?

I can't tell how to use this library to create a Cocoa GUI idiomatically. This is all I could piece together from the source and test code:

extern crate cocoa;

use cocoa::base::{nil, ObjCMethodCall};
use cocoa::appkit::{NSApp, NSRect, NSPoint, NSSize};

static NSApplicationActivationPolicyRegular: int = 0i;
static NSTitledWindowMask: int = 1i;
static NSBackingStoreBuffered: int = 2i;

fn main() {
    let app_name = "Hello World!";

    unsafe {
        let app = NSApp();
        app.send("setActivationPolicy:", (NSApplicationActivationPolicyRegular));

        let window = "NSWindow".send("alloc", ()).send(
            "initWithContentRect:styleMask:backing:defer:",
            (
                NSRect {
                    origin: NSPoint {x: 0., y: 0.},
                    size: NSSize {width: 200., height: 200.}
                },
                NSTitledWindowMask,
                NSBackingStoreBuffered,
                false
            )
        );
        window.send("cascadeTopLeftFromPoint:", (NSPoint {x: 20., y: 20.}));
        window.send("setTitle:", (app_name));
        window.send("makeKeyAndOrderFront:", (nil));

        app.send("activateIgnoringOtherApps:", (true));
        app.send("run", ());
    }
}

E.g. inheritance, method overloading and other stuff that explicitly requires ObjC features, which obviously miss in the bindings.

Is there any reasoning for using traits and implementing them onto id rather than creating newtypes such as struct NSString(id)? I've been running into name collisions with the former a lot lately.

We should probably add a few other Servo people too. CC @metajack

#74 changed a use of objc_msgSend to objc_msgSend_fpret, which the docs say is not needed on x86_64. There are comments in the pull request about an alternate fix. Some background on these functions can also be found here http://sealiesoftware.com/blog/archive/2008/11/16/objc_explain_objc_msgSend_fpret.html

Regardless of what the right fix is, the other methods that return CGFloat should also be updated.

I am currently working on a general solution for working with the Objective-C runtime. It would be great to remove the ffi stuff in this repository in favor of using objc-rs. This would then mean that most of the functionaility of rust-cocoa would be appkit related, so a name change might make sense.

My dead-simple application which depends on rust-cocoa crashes when I merge c4b1941. You can reproduce the error with simnalamburt/fate@ba2615e

glium-practice[19076:161627] +[NSOpenGLContext initWithFormat_shareContext:]: unrecognized selector sent to class 0x7fff7682a850

Go here to see the core dump. Sadly, I failed to print stacktrace.

I realise that Objective-C is a very loosely typed language, but it might be easier to work with the API if we enforce some type safety:

pub struct id(libc::intptr_t);
pub const nil: id = id(0);

pub struct NSWindow(id);
pub struct NSString(id);
...

impl Deref<id> for NSWindow { fn deref(&self) -> &id { ... } }
impl Deref<id> for NSString { fn deref(&self) -> &id { ... } }
...

I came up against this when trying to implement invoke_msg_void_NSInteger on NSInteger in #36 because it overlapped with id. It would also improve the documentation.

See #72 for reference.

Does it make sense to implement a Drop trait for NSAutoreleasePool, so it is called whenever NSAutoreleasePool goes out of scope. It turns out that if the user does not call NSAutoreleasePool::drain() / NSAutoreleasePool::release() manually, the memory will be leaked (by the way the examples from the repository do not call drain, release as well).

PyObjc (and possibly RubyCocoa?) use .fwinfo files to generate language bindings around Cocoa and similar objective C libraries:

https://bitbucket.org/ronaldoussoren/pyobjc/raw/6b74fc7e1ba0995038dc5c1f162d1fad860ff175/pyobjc-framework-Cocoa/metadata/raw.AppKit/x86_64-10.10.fwinfo

From what I can tell, PyObjC uses a tool called objective.metadata to generate these files:

https://bitbucket.org/ronaldoussoren/objective.metadata/src/bd0f1b994403?at=default

Has anyone thought about doing automatic binding generation for cocoa-rs? Anyone know of easy strategies?

Hi!

This is not really an issue (or maybe it is?), but how do I implement an NSApplicationDelegate for example, and assign it to NSApp so that I can start responding to events?

It's a bit of a pain manually adding the C-style null-terminator to every slice that's passed into appkit::NSString::init_str. Can we take a cue from base::class and do this?

use std::ffi;

unsafe fn init_str(self, string: &str) -> id {
    let c_string = ffi::CString::from_slice(string.as_bytes());
    self.initWithUTF8String_(c_string.as_ptr())
}

I get the following error when attempting to call initWithFrame_:

error[E0034]: multiple applicable items in scope
  --> src/lib.rs:63:52
   |
63 |                 let text = NSTextField::alloc(nil).initWithFrame_(frame);
   |                                                    ^^^^^^^^^^^^^^ multiple `initWithFrame_` found
   |
   = note: candidate #1 is defined in an impl of the trait `cocoa::appkit::NSView` for the type `*mut objc::runtime::Object`
   = note: candidate #2 is defined in an impl of the trait `cocoa::appkit::NSTextField` for the type `*mut objc::runtime::Object`

Because NSView is implemented for id, are the other definitions of initWithFrame_ redundant? If so, can they be removed?