Some of these as casts are mighty scary. We should audit for overflows when casting to and from CFIndex and uint, for example.

Are you planning to make a release soon? The improvements on master would help me make progress.

Issue by paulrouget
Friday Mar 17, 2017 at 08:08 GMT
Originally opened as servo/core-graphics-rs#78

I'm trying to animate a Cocoa nsview via its layer. But with no luck. What would it take to make it work?

I'm trying for example to set the opacity of a layer. All the conditions to enable core animation are met.

This code crashes:

let content_view: id = msg_send![nswindow, contentView];
let layer: id = msg_send![content_view, layer];
let transform: CGAffineTransform = msg_send![layer, affineTransform];
msg_send![layer, setAffineTransform:transform];

And this code behaves in a strange way:

let content_view: id = msg_send![nswindow, contentView];
let layer: id = msg_send![content_view, layer];
let opacity: CGFloat = msg_send![layer, opacity];
// opacity is equal to 0.
let opacity: CGFloat = 0.5;
msg_send![layer, setOpacity:opacity];
// view disappear
let opacity: CGFloat = msg_send![layer, opacity];
// opacity is still equal to 0.

It seems currently the only way to create e.g. an NSWindowDelegate is through objc::declare::ClassDecl interface:

let superclass = Class::get("NSObject").unwrap();
let mut decl = ClassDecl::new("MyWindowDelegate", superclass).unwrap();
decl.add_method ...

Should this crate expose trait NSWindowDelegate and make the creation of such delegate more type-safe?

Like servo/core-graphics-rs#89 and to fix servo/core-text-rs#62 this issue will track the work to remove the compiler warnings for zero-sized structs.

We should look at removing the other warnings as well.

Issue by snuk182
Wednesday Jun 21, 2017 at 09:51 GMT
Originally opened as servo/cocoa-rs#165

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

Issue by fkaa
Sunday Feb 28, 2016 at 16:40 GMT
Originally opened as servo/cocoa-rs#117

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.

This is an idea I'm thinking about these days, we should be able to not retain things when using the get rule, instead we should be able to rely on lifetimes.

use std::ops::{Deref, Drop};

pub trait Release {
    unsafe fn release(&self);
}

pub struct Retained<T>(T) where T: Release;

impl<T: Release> Drop for Retained<T> {
    fn drop(&mut self) {
        unsafe {
            self.0.release();
        }
    }
}

enum Opaque {}
pub struct CFURL(Opaque);
pub struct CFURLRef(*const CFURL);

impl Release for CFURLRef {
    unsafe fn release(&self) {
        ...
    }
}

impl Deref for CFURLRef {
    type Target = CFURL;

    fn deref(&self) -> &CFURL {
        unsafe { &*self.0 }
    }
}

With additional traits for casting to supertype CFTypeRef, we should be able to provide functions going from &CFString to Retained<CFStringRef>.

We should be able to do something similar to what we have for CFArray. This will make using it more ergonomic.

I try to run cargo test in master with nightly, it failed to run with SIGSEGV:

running 1 test
test appkit::test::test_nsapp ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/foundation-6ee5b1d765ac12f6

running 8 tests
test foundation::nsdictionary::test_get ... ok
error: process didn't exit successfully: `/Users/user/Sandbox/rust-root/core-foundation-rs/target/debug/deps/foundation-6ee5b1d765ac12f6` (signal: 11, SIGSEGV: invalid memory reference)

Maybe related to rust-windowing/winit#428 ?

CFArrays can contain what ever you want to put in them, one just needs to supply an appropriate set of callbacks (CFArrayCallbacks) for working with them. For example, it would be valuable to be able to cast a CFArray<*c_void> to a CFArray<CFTypeRef> or even a CFArray<CFDictionary>. Unfortunately, there doesn't seem to be anyway to typecheck what is inside a CFArray so the casting would need to be unsafe.

Issue by dawsonfi
Thursday Sep 07, 2017 at 02:23 GMT
Originally opened as servo/cocoa-rs#168

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)

Hey there!

I'm interesting in using these functions (and other security-scoped bookmark functions) from a Rust library of mine. What needs to be done in terms of enabling these in this library?

Issue by cmr
Tuesday May 12, 2015 at 17:54 GMT
Originally opened as servo/cocoa-rs#86

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

Issue by frewsxcv
Saturday Nov 26, 2016 at 21:20 GMT
Originally opened as servo/cocoa-rs#147

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?

Was there a bug/problem we had missed? Why was it yanked so soon after publishing?

Issue by frewsxcv
Wednesday Dec 14, 2016 at 00:52 GMT
Originally opened as servo/cocoa-rs#149

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.

The commit dc4599d with version v0.4.4 was merged and passed tests, but crates.io still shows 0.4.3.

Did publishing fail, or is it just delayed?

servo/core-graphics-rs#77 was a work-in-progress that looked like a reasonable solution.

Issue by cmr
Tuesday May 12, 2015 at 17:54 GMT
Originally opened as servo/cocoa-rs#86

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

I'd like to add a feature to Cargo itself that requires macOS 10.8, but Cargo supports 10.7 as well.

I'm afraid that exposing kCFURLIsExcludedFromBackupKey (10.8+) will cause link errors on macOS 10.7.

Can it be linked using #[linkage = "extern_weak"]? It seems to be an unstable feature. Is it OK to add #![feature(linkage)] to this crate?

Issue by jrmuizel
Friday Aug 12, 2016 at 20:13 GMT
Originally opened as servo/core-graphics-rs#55

Serialize impl serializes using the name of the font. This obviously won't work for fonts created from data.

Rather than having consumers pass in a stringly-typed dictionary for new_from_variations, it would be nice to provide a strong builder API that encapsulates that process.

Issue by demurgos
Sunday Dec 03, 2017 at 20:46 GMT
Originally opened as servo/cocoa-rs#179

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

Issue by jrmuizel
Wednesday Mar 15, 2017 at 23:04 GMT
Originally opened as servo/core-graphics-rs#77

These are useful if you don't want to copy the data. Thoughts?

This change is 

jrmuizel included the following code: https://github.com/servo/core-graphics-rs/pull/77/commits

Issue by nox
Thursday Oct 13, 2016 at 12:39 GMT
Originally opened as servo/core-graphics-rs#58

This is a work in progress.

This change is

nox included the following code: https://github.com/servo/core-graphics-rs/pull/58/commits

Issue by yupferris
Thursday Jul 28, 2016 at 18:52 GMT
Originally opened as servo/cocoa-rs#140

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 (https://github.com/servo/cocoa-rs/blob/bce77bf83b10dd6ec54bb8ce897baeb5f5b24d46/src/appkit.rs#L312), but the bitflags that are meant to be used there are backed by a libc::c_ulonglong, which is not compatible in 32-bit builds.

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.

Issue by jrmuizel
Saturday Jan 27, 2018 at 15:05 GMT
Originally opened as servo/core-text-rs#78

This change is 

jrmuizel included the following code: https://github.com/servo/core-text-rs/pull/78/commits

I wish CFString had implementations for Eq and PartialEq using CFStringCompare. Ord and PartialOrd could also be done using the same function! :)

Issue by azah
Wednesday Dec 06, 2017 at 00:27 GMT
Originally opened as servo/cocoa-rs#180

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.

Issue by yupferris
Thursday Jul 28, 2016 at 18:52 GMT
Originally opened as servo/cocoa-rs#140

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 (https://github.com/servo/cocoa-rs/blob/bce77bf83b10dd6ec54bb8ce897baeb5f5b24d46/src/appkit.rs#L312), but the bitflags that are meant to be used there are backed by a libc::c_ulonglong, which is not compatible in 32-bit builds.

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.

Issue by fkaa
Sunday Feb 28, 2016 at 16:40 GMT
Originally opened as servo/cocoa-rs#117

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.

I am playing around with rust-core-foundation and encountered an ICE when using the dictionary's "each" iteration. The following snippet (part of an unsafe block) illustrates the issue:

let dicPtr: _c_void = CFArrayGetValueAtIndex(arrRef, i as CFIndex);
let dicRef: CFDictionaryRef = cast::transmute::<_c_void, CFDictionaryRef>(dicPtr);
io::println(fmt!("Dic count: %?", CFDictionaryGetCount(dicRef))); // works fine!

let dic: CFDictionary<CFStringRef,CFTypeRef> = CFDictionary::wrap_owned(dicRef);
for dic.each |key, val| { // internal compiler error: unknown tag found in side tables: 5e

}

This results in the following ICE:

error: internal compiler error: unknown tag found in side tables: 5e
rust: task failed at 'explicit failure', /Volumes/Users/xxx/rust/rust/src/libsyntax/diagnostic.rs:93
rust: task failed at 'explicit failure', /Volumes/Users/xxx/rust/rust/src/librustc/rustc.rc:353
rust: domain main @0x7fc96180ba10 root task failed

I realise that this issue is more related to the Rust compiler than this wrapper, but my Rust knowledge is insufficient to pinpoint the problem any closer than this.

EDIT: I was able to reduce the problem to the following code:

extern mod core_foundation;

use core_foundation::base::{CFTypeRef};
use core_foundation::string::{CFStringRef};
use core_foundation::dictionary::{CFDictionary};

fn main() {
    let _dic = CFDictionary::new::<CFStringRef, CFTypeRef>([]);  
}

We can do like CFDictionary.

<T> in this line is no longer valid in Rust master:
https://github.com/mozilla-servo/rust-core-foundation/blob/1f43d00330/base.rs#L57

Having a dummy parameter of type Option<Self> could work, but refactoring across repositories this will be a pain. (Not to mention how ugly it is.)

Issue by jtomschroeder
Thursday Feb 02, 2017 at 17:33 GMT
Originally opened as servo/cocoa-rs#154

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?

Issue by mitchmindtree
Sunday Feb 05, 2017 at 08:19 GMT
Originally opened as https://github.com/servo/cocoa-rs/issues/155

The NSEvent::eventType method produces the value 21 when spotlight is opened or one of the items on the system menu tray are opened (e.g. battery status, wifi). The value has no associated variant within the NSEventType enum and thus segfaults when a user attempts to match against a NSEventType of value 21. This was causing a segfault in winit. I've added a commit to winit that side-steps this bug, however this should be properly fixed upstream in this crate. I've been unable to find any documentation on NSEventTypes of value 21 just yet.

AFAIK, the links attribute in Cargo only exist because on some platforms, linking multiple times to a single thing is a recipe for failure. I don't think that is the case for macOS frameworks, and having Cargo fail because two core-foundation-sys versions are used in a single project is a PITA (see #96).

We should probably not use links if we can afford to make do without it.

Cc @tomaka for the initial paper cut, @alexcrichton for his Cargo knowledge and to confirm or infirm what I just wrote.

Issue by demurgos
Sunday Dec 03, 2017 at 20:46 GMT
Originally opened as servo/cocoa-rs#179

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

Issue by rthomas
Thursday Jul 27, 2017 at 16:52 GMT
Originally opened as servo/core-graphics-rs#89

This is related to servo/core-text-rs#62 to remove the warnings when building.

The offending types for core-text are CGAffineTransform and CGContextRef.

Other warnings in the crate should also be cleaned up or silenced. The method for the two listed types can be found at rust-lang/rust#27303

I was trying to follow Implementing the Full-Screen Experience and looks like some of the useful APIs are missing.

E.g. I don't see NSApplicationPresentationOptions which allow things like hiding the dock and controlling cmd+tab behavior. Should we add those?

currently all of the interfaces are implemented as traits on Id. This means there's no type safety between objects. We should probably use something like the foreign_obj_type! macro from https://github.com/gfx-rs/metal-rs/blob/master/src/lib.rs to improve things here.

Because its Cargo.toml contains a links attribute, it is impossible to use core-foundation-sys v0.2 and core-foundation-sys v0.3 in the same project.

There is absolutely no reason why the version of core-foundation-sys should match the version of core-foundation.

Issue by application-developer-DA
Tuesday Apr 04, 2017 at 16:07 GMT
Originally opened as servo/core-graphics-rs#81

I've noticed several problems when worked with the code:

1. Some inconsistencies in coding style: the order of use statements varies between files (it would be better to use the same style / order everywhere; one of the possible styles).
2. When multiple functions/structures/types are imported from the module, both use something::{str1, test, example} and use something::{ str1, test, example } styles are used, it would be nice to stick to one of the versions.
3. Sometimes the text width is more than 100 characters.
4. There is a lot of boilerplate code in each module when it comes to TCFType trait implementation. I think it makes sense to use impl_TCFType! macro from core-foundation-sys or something similar.

The NSEvent::eventType method produces the value 21 when spotlight is opened or one of the items on the system menu tray are opened (e.g. battery status, wifi). The value has no associated variant within the NSEventType enum and thus segfaults when a user attempts to match against a NSEventType of value 21. This was causing a segfault in winit. I've added a commit to winit that side-steps this bug, however this should be properly fixed upstream in this crate. I've been unable to find any documentation on NSEventTypes of value 21 just yet.

Issue by frewsxcv
Saturday Nov 26, 2016 at 21:20 GMT
Originally opened as servo/cocoa-rs#147

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?

Issue by application-developer-DA
Tuesday Apr 04, 2017 at 11:55 GMT
Originally opened as servo/cocoa-rs#161

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).

I'm writing bindings for spotlight APIs and there are functions like MDItemCopyAttribute that return CFTypeRef and it'd be nice to have a safe way to turn that into the concrete type (like CFString). If there was something like fn TCFType::from_CFType(cftype: &CFType) -> Option<Self> presumably I could write code like:

let cf_type = unsafe { CFType::wrap_under_get_rule(MDItemCopyAttribute(...)) };
let cf_str = CFString::from_CFType(&cf_type).unwrap();

Should this be *mut __CFDictionary?

CFDictionarySetValue takes a CFMutableDictionary as a parameter and so we shouldn't be calling it on immutable CFDictionaries.