date:20171212

Problem with NSWorkspace.shared and uid 0

2017-12-12 Thread sqwarqDev

When using the absolutePathForApplication(withBundleIdentifier:) api, I find 
that if the path is on an external mount, the api will return nil / none if the 
uid is 0, when it will return an actual path when the uid is a valid user login 
id (eg, 501, 502 etc). 

To reproduce, mount a .dmg containing some app that isn’t on the boot drive, 
and insert its bundeID for the value of inputPath in the code below:


import Foundation
import AppKit

let inputPath = “com.some.bundleID"
let pathToApp: String? = 
NSWorkspace.shared.absolutePathForApplication(withBundleIdentifier: inputPath)
let result = pathToApp ?? "nil"
print(result)


In Xcode, if I edit the scheme to debug/run as myself, I’ll get a valid result, 
but if I edit it to run as root, I’ll get back this error msg:

schedule invalidation 

I have also tried querying LaunchServices directly with 

let altPath = LSCopyApplicationURLsForBundleIdentifier(inputPath as CFString, 
)

which again returns successfully as me, but as root gives the error:

Error Domain=NSOSStatusErrorDomain Code=-10814 "kLSApplicationNotFoundErr: E.g. 
no application claims the file”))

It’s been suggested to me that the problem may be that the LS database isn’t 
updated for transient mounts for the root user. That makes sense of the error 
messages, but two questions:

1. Should this be considered a bug, or expected behaviour?
2. Any suggestions for a workaround?


TIA



Best


Phil
@sqwarq




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Richard Charles


> On Dec 12, 2017, at 2:40 PM, Jonathan Mitchell  wrote:
> 
>> On 12 Dec 2017, at 19:56, Richard Charles  wrote:
>> 
>> I always assumed the reason bindings never came over to iOS was they 
>> consumed too much cpu power and were too difficult to understand. It seems 
>> evident that 10 or 20 years from now Apple anticipates the bulk of it 
>> programmers coming out of school will use iPads with the new style 
>> documentation. Cocoa bindings do not fit very well into this picture.
> I am not sure if stringent power concerns were the overriding factor for 
> excluding bindings from iOS. 
> Bindings are driven by observations, which do exist on iOS.

I stand somewhat corrected, I did not know KVO was available on iOS.

> Bindings are actually a fairly essential technology for medium to large scale 
> data driven macOS applications.
> Trying to manually glue hundreds of controls and data paths together quickly 
> becomes a major development obstacle.

Amen to that!

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Jonathan Mitchell

> On 12 Dec 2017, at 19:56, Richard Charles  wrote:
> 
> I always assumed the reason bindings never came over to iOS was they consumed 
> too much cpu power and were too difficult to understand. It seems evident 
> that 10 or 20 years from now Apple anticipates the bulk of it programmers 
> coming out of school will use iPads with the new style documentation. Cocoa 
> bindings do not fit very well into this picture.
I am not sure if stringent power concerns were the overriding factor for 
excluding bindings from iOS. 
Bindings are driven by observations, which do exist on iOS. 
I think that some developers use reactive frameworks such as ReactiveCocoa to 
achieve UI binding on IOS - but I am not sure that would count as a 
simplification.

Cocoa bindings are okay though they lack flexibility and features when compared 
to the likes of WPF bindings.
WPF bindings are just about as tricky to get right - though the use of a GC 
makes life generally easier in a managed world.

Bindings are actually a fairly essential technology for medium to large scale 
data driven macOS applications.
Trying to manually glue hundreds of controls and data paths together quickly 
becomes a major development obstacle.

J

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Background fetch is never called

2017-12-12 Thread Steve Christensen

Did you confirm that there is a UIBackgroundModes key in your app's Info.plist?

UIBackgroundModes

fetch




> On Dec 12, 2017, at 6:23 AM, Viacheslav Karamov  wrote:
> 
> I have configured Background Fetch at the "Capabilities" tab in my Project's 
> settings. Then added to the App delegate:
> 
> -(void)application:(UIApplication *)application 
> performFetchWithCompletionHandler:(void 
> (^)(UIBackgroundFetchResult))completionHandler
> {
> NSLog(@"### Received Backgroudn Fetch ###");
> 
> //Increase Badge Number
> [UIApplication sharedApplication].applicationIconBadgeNumber++;
> 
> 
> completionHandler(UIBackgroundFetchResultNewData);
> }
> 
> - (BOOL)application:(UIApplication *)application 
> didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
> {
> [[UIApplication sharedApplication] 
> setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];
> 
> return YES;
> }
> 
> When I run my simple App on the real device (tested on iPad mini 2 with iOS 
> 10.2 and iPhone 6S running iOS 11.2) nothing happened during long time period 
> (more than 10h). I even tried to add "Remote Notifications" capability and it 
> also didn't help.
> 
> Regards,
> 
> Viacheslav.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Richard Charles

> On Dec 12, 2017, at 12:08 PM, Quincey Morris 
>  wrote:
> 
> I don’t think bindings are fading away. They can’t, while they’re the only 
> way to connect UI elements without custom glue code. However, the design is 
> ancient (IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, 
> and really nothing has changed since then).

It is the documentation of bindings that is fading away and if you are an iOS 
programmer then bindings are irrelevant. Malcolm Crawford had an excellent 
resource on the web for understanding bindings (Cocoa Bindings Examples and 
Hints) but it has disappeared. Malcolm Crawford made his last post to cocoa-dev 
in 2012 and so time marches on.

> What has fallen away (because it never really got off the ground) was the use 
> of *custom* bindings, in part because no one could understand what to do, and 
> because they really needed the IB customization features introduced in Xcode 
> 3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).

Custom programmatic bindings (not integrated with IB) work great but it is 
daunting to figure this out. So I agree.

> In modern terms, bindings are a horrible hack, and that’s why (I assume) they 
> were never taken over to iOS.

I always assumed the reason bindings never came over to iOS was they consumed 
too much cpu power and were too difficult to understand. It seems evident that 
10 or 20 years from now Apple anticipates the bulk of it programmers coming out 
of school will use iPads with the new style documentation. Cocoa bindings do 
not fit very well into this picture.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Quincey Morris

On Dec 12, 2017, at 02:12 , Eric Matecki  wrote:
> 
> In the case of NSTableCellView, neither binding works... I don't get any 
> exception or crash, but nothing is displayed inside my table view (although 
> it's size suggests the four rows are there).

This was a conceptual failure on my part, since I’ve never actually created a 
NSTableCellView manually. The cell view has “imageView" and “textField” 
outlets, but they’re not connected to anything by default, and the cell view 
has no subviews by default. (One or both subviews is present and connected when 
you do this in IB, because IB uses a preconfigured cell view hierarchy.)

If you want to use a text view, you will have to subclass NSTableCellView to 
add a “textView” outlet. or you can use a text field with the existing 
“textField” outlet. Either way, you’ll need to create the text-displaying 
subview, and set the corresponding outlet.

>[view  bind: @"value"  toObject: tableView  withKeyPath: 
> @"objectValue.name"  options: 0];  // wrong, but works

I have no idea why that works, it makes no sense whatever.

You’re still missing some stuff, BTW:

— For proper table view behavior, you really should create the cells by 
invoking "makeView(withIdentifier:owner:)”, so that the table view can manage 
the lifetimes and reusability of the cell views. However, this mechanism is 
intended to work with a NIB for the table cell view. This can either come from 
the table view’s own NIB file (via a private mechanism that IB sets up for you) 
or a freestanding NIB file (which you must register with the table view 
manually). Since you have neither, you will (I guess) need to let the cell 
creation portion of the "makeView(withIdentifier:owner:)” API fail, when a cell 
view isn’t being reused, then create your cell view manually.

Technically, you don’t have to do this, I suppose, but you said you were trying 
to learn what normally goes on, and cell view caching is what normally happens.

— You didn’t embed your table view in a scroll view. 

If it can’t scroll, the table view isn’t much use.

> How do you "ignore" what you don't need in an NSTableCellView ?

As I said, I was confusing two things. Most standard cells created in IB are 
just text, and have no image view.

> And when I add a subview to one, how do I arrange (layout) it's content

The usual ways, which is to say: add layout constraints, or set the frame 
manually if you’re not using autolayout.

> It's still weird (to me) to bind an object's binding to one of it's own 
> properties.

It’s just a special case of a “derived” property. It’s not so unusual for an 
object to observe one of its own properties in order to provide a KVO compliant 
value for another property. Anyway, in this case, it’s conceptually binding to 
a different object (the one referenced by “objectValue”) to get its “name” 
property. The indirection falls out of the division between standard behavior 
and custom behavior that’s built into the table view design.

> Too bad that bindings are fading away

I don’t think bindings are fading away. They can’t, while they’re the only way 
to connect UI elements without custom glue code. However, the design is ancient 
(IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, and really 
nothing has changed since then).

What has fallen away (because it never really got off the ground) was the use 
of *custom* bindings, in part because no one could understand what to do, and 
because they really needed the IB customization features introduced in Xcode 
3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).

In modern terms, bindings are a horrible hack, and that’s why (I assume) they 
were never taken over to iOS.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Background fetch is never called

2017-12-12 Thread Viacheslav Karamov

I have configured Background Fetch at the "Capabilities" tab in my 
Project's settings. Then added to the App delegate:


-(void)application:(UIApplication *)application 
performFetchWithCompletionHandler:(void 
(^)(UIBackgroundFetchResult))completionHandler

{
    NSLog(@"### Received Backgroudn Fetch ###");

    //Increase Badge Number
    [UIApplication sharedApplication].applicationIconBadgeNumber++;


    completionHandler(UIBackgroundFetchResultNewData);
}

- (BOOL)application:(UIApplication *)application 
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{
    [[UIApplication sharedApplication] 
setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];


    return YES;
}

When I run my simple App on the real device (tested on iPad mini 2 with 
iOS 10.2 and iPhone 6S running iOS 11.2) nothing happened during long 
time period (more than 10h). I even tried to add "Remote Notifications" 
capability and it also didn't help.


Regards,

Viacheslav.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Eric Matecki


Hi Richard,

thanks for all this reading !
I'll need a day or two to understand everything therein. Even if they aren't 
that long, there are a lot of subtle details :)

Too bad that bindings are fading away, the concept is great, the implementation 
is not so great from skimming thru these pages

Eric M.

On 12/12/2017 14:02, Richard Charles wrote:



On Dec 12, 2017, at 3:12 AM, Eric Matecki  wrote:

It's still weird (to me) to bind an object's binding to one of it's own 
properties.


I have an applicaiton that extensively uses programmatic and custom bindings. 
The following have helped me understanding bindings.


...


==

Bindings are a bit of a mystery especially programmatic bindings. Perhaps 
because iOS does not have bindings, interest in bindings and information about 
bindings appears to be diminishing.

--Richard Charles


--
Keep intel OUTSIDE my Mac !
Hiii !!! I can see Intel chips creeping around my G5 !

Eric M.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating NSTableView programmatically

2017-12-12 Thread Eric Matecki

Hi,

On 11/12/2017 20:10, Quincey Morris wrote:

I made my own text field class according to this (in NSTableCellView's doc) :

I think you’re still kinda Doing It Wrong™. The standard (and, I believe,
recommended) way to do this is to create an instance of
NSTableCellView, which has the “objectValue” property, along with other
potentially useful behaviors for cell views (such as
identifiers that allow the NSTableView to cache and manage cell views).

I know it's wrong, or at least bad, but NSTextView and NSButton are the
controls I kind of master right now...
I really don't need a textview, as I'm just trying to reproduce the
"Combattant" example.
I still can't get the names to display with NSTableCellView.

Here (at the bottom of the page) :
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
it says :
"""
When you make the connection to the table view’s Content binding, the objectValue property of the NSTableViewCell used as the cell
for the table column is configured such that for each item in the model array, the table updates the objectValue property to the
current row’s Person object

1) Select the text field in the table column cell and create the binding.
All bindings of subviews in the cell are made to the objectValue.
Configure the textField instance’s value binding.

Binding field | Value
---
Bind to:| Table Cell View
Model key path | objectValue.name
"""

So I have this in my NSTableView's delegate, which is my interpretation of the
above :

- (NSView *)tableView:(NSTableView *)tableView
viewForTableColumn:(NSTableColumn *)tableColumn
row:(NSInteger)row
{
#if 0 // this shows the names

cTextView* view = [[cTextView alloc] init]; // cTextView is my custom
NSTextView with just an added objectValue property
[view bind: @"value" toObject: tableView withKeyPath:
@"objectValue.name" options: 0]; // wrong, but works
//[view bind: @"value" toObject: view withKeyPath: @"objectValue.name"
options: 0]; // right, works

#else // this doesn't show the names

NSTableCellView* view = [[NSTableCellView alloc] init];
//[[view textField] setBackgroundColor: [NSColor redColor]]; // just to
be sure to see it when empty... nada
//[[view textField] bind: @"value" toObject: tableView withKeyPath:
@"objectValue.name" options: 0]; // wrong, doesn't work
[[view textField] bind: @"value" toObject: view withKeyPath:
@"objectValue.name" options: 0]; // right?, but doesn't work

#endif
return view;
}

Note that I bind the NSTextView to tableView, while the doc says "the objectValue property of the NSTableViewCell", not of the
tableview... but it works, and I don't understand why... I don't like it when I don't understand what's happening.

It also works when binding to the view, which is expected (I first bound it to
tableView by mistake...).
It's still weird (to me) to bind an object's binding to one of it's own
properties.
I guess it's more or less by chance that it displays the names, and that some
changes in my model won't get correctly propagated...

In the case of NSTableCellView, neither binding works... I don't get any exception or crash, but nothing is displayed inside my
table view (although it's size suggests the four rows are there).

But setting the backgroud of the textfield to red doesn't show any red on the
screen...
(Trying to the set the cell's background gives me a "may not respond to message" warning, and obviously nothing gets red on the
screen).

Something in the "big scheme of things" escapes me, and Apple's doc was not
very helpful until now.

In a very unusual or complex case, you might subclass NSTableCellView to add
properties or behaviors to it, but it’s normally not
necessary. Custom properties, for example, can be carried around by the object
referred to by “objectValue”, and custom behaviors
can sometimes be implemented as part of the delegate.

Instead of using a cell view other than a NSTableCellView or subclass, it’s
usual to *add subviews* for things like text fields
and buttons. That separates the behavior of the cell *as a cell* (such as being
cached for the table view) from the view hierarchy
represented by the cell. However, if your cell just needs to contain a text
field, you don’t need to add one yourself,
because NSTableCellView already contains a NSTextField subview that you can
just *use*. It also contains NSImageView subview that
you can use or ignore.

How do you "ignore" what you don't need in an NSTableCellView ?
And when I add a subview to one, how do I arrange (layout) it's content, so it works with the way the 'free' NSTextField and
NSImageView are arranged (which I ignore) ?

NSTableCellView's doc is rather scarce.

Now I can see all the names :)

One reason to use a NSTableCellView instead of a control sum

Problem with NSWorkspace.shared and uid 0

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Background fetch is never called

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Background fetch is never called

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

9 matches

Site Navigation

Mail list logo

Footer information