Re: Issue with NSTokenFieldCell in NSTableView and bindings..

[Jerry Krinock]

> On 2015 Nov 11, at 19:36, Samuel Williams  
> wrote:
> 
> I'm trying to do something which in theory is rather simple: Use a
> NSTokenFieldCell in a NSTableView and bind the table column value to the
> token field.
> 
> 1/ The binding doesn't seem to propagate the value back to the model.

Known bug since the beginning of NSTokenField in 2004.

> 2/ Occasional crashes when editing the column.

Haven’t seen that, but I probably wouldn’t have seen it, because when user 
attempts to edit the token field cell in my apps’ tables, my workaround for the 
known bug is that it opens a popover instead.

> I've put a sample app together with a README which includes screenshots
> outlining the issues and filed a bug report with Apple (
> https://github.com/ioquatix/TableViewTokenCellTest).

Prepare for “Closed as a duplicate” :(

> I was wondering the following:a/ I've filed a bug report but this a blocker 
> for a commercial app I'm
> working on. I have some code level support requests available. Does this seem 
> like a reasonable issue to bring to Apple at that level?

Yes, but a likely result is that you’ll be told that Engineering has concluded 
this should be handled as a bug report, and the incident will be credited back 
to your account.  But you’ve already done the hard part of making the demo 
project, so it’s worth considering for a minute.

> b/ Has anyone run into these issues and found any solutions? I'm thinking
> one option might be to try and use a view based table-view rather than a
> cell based one.

I plan on coverting to view-based for other reasons.  Currently, I’m still 
cell-based.  It is quite possible that putting it in a view, which means you’d 
be using NSTokenField instead of NSTokenFieldCell, would fix the problem.


___

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

how to change the name of my variable in main.storyboard to BrowseAirports? This is what I want to call in the code when I type the code to connect to my web view?

[Scott Berry]

Hello there,

I want to call my web view BrowseAirports in storyboard so that I can refer to 
this in my code telling the webView what to do??
___

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: Customising NSFontManager

[Graham Cox]

Thanks- main() is the only place that works. I tried run() and even init() of 
the application, but even they were too late.

It does prove my working theory - that NSTextView is accessing NSFontManager 
directly rather than using the sender passed to -changeFont:, even though 
Apple’s docs tell the rest of us to do it that way. It’s a pity, because it 
means that I now need a ”thick” shim instead of a “thin” one to intercept font 
changing operations sent to text views (by which I mean I now have to subclass 
NSFontManager instead of passing a simple object as sender that can intercept 
the callback to -[ convertFont:]. Bah.

Am I alone in thinking the design of the font changing mechanism is simply 
horrible? No wonder the Font Panel itself is so horrible, with all of the 
different text properties and attributes conflated into an indistinct porridge 
of settings that are hard to separate out. Just look at NSFontAction to see 
what I mean.


—Graham





> On 12 Nov 2015, at 1:07 PM, Ken Thomases  wrote:
> 
> Probably best to put it in main().
> 
> The app delegate is typically instantiated in the MainMenu NIB (or 
> storyboard, I guess).  Therefore, there's no possibility that any method will 
> be invoked on it until that NIB is loaded.  If the NIB contains a placeholder 
> for the shared font manager or anything which uses it (like the Font menu), 
> then you can't get in front of it reliably in methods of the app delegate.  
> So, you have to make the call before the NIB is loaded.  main() is the 
> easiest place for that.
> 
> If that doesn't work, you may need to use a custom subclass of NSApplication 
> and put it in an override of -run, before calling through to super.
> 
> Regards,
> Ken
> 


___

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

Images in NSOutlineView disappear on dataReload

[Nick]

Hello
I've encountered a strange behavior in a source list NSOutlineView.
Basically, whenever I call "reloadData", an image, that was set for a
currently selected row (NSTableCellView's imageview.image), disappears (I
set image in outlineView:viewForTableColumn:item:). When I select the row,
the image appears again, as on the pictures:

Select a row, press "Button" to reloadData (the image disappears)
http://i.imgur.com/l4rmOrl.png
Select the row again (the image appears again)
http://i.imgur.com/LrC1BVy.png


I tried to "troubleshoot" this in various ways, even using F-Script (which
revealed that NSOutlineView changes NSTableCellView's imageview.image class
automatically from NSImage to an "internal" class NSSidebarImage after
reload). But other than that I cannot understand, why the image disappears.
Is there anything wrong with my code (although it is almost identical to
Apple's outline view sample code), or is it a bug in the AppKit?

Here's a very simple sample code that shows the problem. I just created a
new XCode project, added a Source List control to the window, and set
outline view's dataSource and delegate to my AppDelegate (also created the
IBOutline for the Source List and call it sidebarOutlineView).

Anyway, thank you for taking a look at this!

@interface AppDelegate ()
@property (weak) IBOutlet NSWindow *window;
@property NSArray *topLevel;
@property NSDictionary *topLevelToSecondLevelDict;
@property (weak) IBOutlet NSOutlineView *sidebarOutlineView;
@end


@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
self.topLevel = @[@{@"title": @"Header1",
@"isRootItem": @YES},
@{@"title": @"Header2",
@"isRootItem": @YES}
   ];

NSArray *subitems1 = @[@"11", @"12"];
NSArray *subitems2 = @[@"21", @"22"];
self.topLevelToSecondLevelDict = @{@"Header1": subitems1,
   @"Header2": subitems2};

[_sidebarOutlineView reloadData];

[NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:0];
[_sidebarOutlineView expandItem:nil expandChildren:YES];
[NSAnimationContext endGrouping];
}


- (id)outlineView:(NSOutlineView *)outlineView child:(NSInteger)index
ofItem:(id)item {

if(!item) {
return self.topLevel[index]; //returns an NSDictionary, that
corresponds to the root item
} else {
return [self.topLevelToSecondLevelDict[[item
objectForKey:@"title"]][index]
copy];
}
}


- (BOOL)outlineView:(NSOutlineView *)outlineView isItemExpandable:(id)item {
if([item isKindOfClass:[NSDictionary class]]) {
return YES;
} else {
return NO;
}
}


- (NSInteger) outlineView:(NSOutlineView *)outlineView
numberOfChildrenOfItem:(id)item {
if(!item) {
return self.topLevel.count;
} else {
return [self.topLevelToSecondLevelDict[[item objectForKey:@"title"]]
count];
}
}


- (BOOL)outlineView:(NSOutlineView *)outlineView isGroupItem:(id)item {
return [self.topLevel containsObject:item];
}


- (NSView *)outlineView:(NSOutlineView *)outlineView
viewForTableColumn:(NSTableColumn
*)tableColumn item:(id)item {
if ([self.topLevel containsObject:item]) {
NSTableCellView *result = [outlineView
makeViewWithIdentifier:@"HeaderCell"
owner:self];
result.textField.stringValue = [[item objectForKey:@"title"] copy];
return result;
} else  {
NSTableCellView *result = [outlineView
makeViewWithIdentifier:@"DataCell"
owner:self];
result.textField.stringValue = [item copy];
NSString *parentTitle = [[outlineView parentForItem:item]
objectForKey:@"title"];
if([parentTitle isEqualToString:@"Header1"]) {
result.imageView.image = [NSImage imageNamed:
NSImageNameHomeTemplate];
} else if([parentTitle isEqualToString:@"Header2"]) {
result.imageView.image = [NSImage imageNamed:
NSImageNameListViewTemplate];
} else {
NSLog(@"Error!");
}
return result;
}
}


- (IBAction)button:(id)sender {
[self.sidebarOutlineView reloadData];
}

@end
___

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: Identify image file count in directory

[Gary L. Wade]

Try going down a level to the BSD layer APIs for directory contents traversal.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Nov 13, 2015, at 8:28 AM, Jonathan Taylor  
> wrote:
> 
> Hi all,
> 
> I want to be able to identify quickly (programatically) how many image files 
> reside in a particular directory. At present I call:
>  [NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil];
> and then examine the type suffixes (which in comparison is very quick). When 
> looking at a directory over a network or on an external drive, the 
> NSFileManager call can take several seconds for a directory containing 18k 
> files of which half are images.
> 
> These sorts of numbers are in fact a common use case for me, and I would like 
> to avoid this delay. This is for preview information in an NSOpenPanel, so I 
> don't want to make things this unresponsive - but at the same time it is very 
> useful to have access to this information for the preview.
> 
> Can anybody advise on a quicker way of achieving what I want to achieve? The 
> fact that 'ls' takes almost as long makes me think this is probably a fairly 
> insurmountable problem, but at the same time the quantity of information 
> transferred (of the order of 200k of data) should not take 2 seconds to 
> transfer, so in that sense it doesn't seem unreasonable to try and see if 
> there is a faster way.
> 
> I would prefer to get the filenames themselves, but I could settle for just a 
> count of the total number of files (of any kind) in the directory *and* the 
> ability to get the paths of just the first few files in the directory, if 
> there might be a faster way of doing that.
> 
> Thanks for any suggestions
> Jonny

___

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

Identify image file count in directory

[Jonathan Taylor]

Hi all,

I want to be able to identify quickly (programatically) how many image files 
reside in a particular directory. At present I call:
  [NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil];
and then examine the type suffixes (which in comparison is very quick). When 
looking at a directory over a network or on an external drive, the 
NSFileManager call can take several seconds for a directory containing 18k 
files of which half are images.

These sorts of numbers are in fact a common use case for me, and I would like 
to avoid this delay. This is for preview information in an NSOpenPanel, so I 
don't want to make things this unresponsive - but at the same time it is very 
useful to have access to this information for the preview.

Can anybody advise on a quicker way of achieving what I want to achieve? The 
fact that 'ls' takes almost as long makes me think this is probably a fairly 
insurmountable problem, but at the same time the quantity of information 
transferred (of the order of 200k of data) should not take 2 seconds to 
transfer, so in that sense it doesn't seem unreasonable to try and see if there 
is a faster way.

I would prefer to get the filenames themselves, but I could settle for just a 
count of the total number of files (of any kind) in the directory *and* the 
ability to get the paths of just the first few files in the directory, if there 
might be a faster way of doing that.

Thanks for any suggestions
Jonny
___

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: Voiceover support

[Glenn L. Austin]

> On Nov 13, 2015, at 5:09 AM, Daniel Phillips  wrote:
> 
> I work at Trainline on their iOS app. We had some customer feedback recently 
> and unfortunately someone booked a ticket for the wrong date because we 
> botched our voiceover support! 
> Safe to say our app as it stands is using accessibility solely for UI Testing 
> purposes and any voiceover functionality is purely coincidence. 
> 
> I've been adding voiceover support and my question is, to what level do you 
> suggest I go with it. By which I mean, we have a lot of data on screen, 
> departure times, departure station name, a label showing the duration of 
> travel in an abbreviated format etc etc. 
> 
> These labels could all be on say a single table view cell.
> 
> I just added support for the following: "2h 25m, direct" to read out "2 hours 
> and 25 minutes. Direct train."
> 
> And then I began work on the departure/arrival time. Then it hit me, I don't 
> really know what I'm going for. It currently reads out something like "10:20. 
> London. 14:36. Manchester", but having added a nicer support in the previous 
> duration example, I'm tempted to have voiceover read something like 
> "Departing 10:20 from London. Arriving 14:36 at Manchester"
> 
> Of course there's no limit on what you could do with this, but I wanted your 
> thoughts on how far is too far. I want to make sure they get all the info, 
> but is being too chatty a bad thing?
> 
> Would love your feedback.
> 
> Daniel

Voiceover is your user interface to those who have difficulties viewing the 
information.  If you have a rich visual interface, your auditory interface 
should be equivalent.

Not everyone has eyes to see, some have to depend upon their ears.  Get your 
user interface people involved as well -- they need to realize that snazzy 
interface means zero to someone who can't see it.  Bring blindfolds if 
necessary.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Voiceover support

[Daniel Phillips]

I work at Trainline on their iOS app. We had some customer feedback recently 
and unfortunately someone booked a ticket for the wrong date because we botched 
our voiceover support! 
Safe to say our app as it stands is using accessibility solely for UI Testing 
purposes and any voiceover functionality is purely coincidence. 

I've been adding voiceover support and my question is, to what level do you 
suggest I go with it. By which I mean, we have a lot of data on screen, 
departure times, departure station name, a label showing the duration of travel 
in an abbreviated format etc etc. 

These labels could all be on say a single table view cell.

I just added support for the following: "2h 25m, direct" to read out "2 hours 
and 25 minutes. Direct train."

And then I began work on the departure/arrival time. Then it hit me, I don't 
really know what I'm going for. It currently reads out something like "10:20. 
London. 14:36. Manchester", but having added a nicer support in the previous 
duration example, I'm tempted to have voiceover read something like "Departing 
10:20 from London. Arriving 14:36 at Manchester"

Of course there's no limit on what you could do with this, but I wanted your 
thoughts on how far is too far. I want to make sure they get all the info, but 
is being too chatty a bad thing?

Would love your feedback.

Daniel

Sent from my iPad
___

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

Full Screen and weird grey bar

[Andreas Mayer]

Hello,

I just implemented fullscreen behavior for one of my applications.

Moving the mouse to the top of the screen will show the menu bar with the 
window's title bar below, just like expected. But then the title bar is 
immediately overlaid by a blank grey bar:

http://harmless.de/images/other/bar1.png


When I move the mouse pointer about 15 pixel below that bar, it will vanish 
again and show the title bar beneath:

http://harmless.de/images/other/bar2.png

Moving the mouse upwards again will re-display the grey bar.


It must be something I'm doing; when I try it in split screen, only my half 
will show the grey bar. :-/

Any idea what the problem could be?


Regards,

Andreas
___

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: Yet another autolayout question

[Dragan Milić]

On pet 13.11.2015., at 11.00, Ken Thomases wrote:

> Hmm.  Oh well.
> 
> Your screencast of the failing case shows that you have some additional views 
> (boxes, it looks like) in the hierarchy, and you haven't explained fully the 
> constraints involved.

Just to put some light onto this… I’ve just discovered everything works 
perfectly fine and as expected if I replace that instance of (subclassed) 
AVPlayerView with a simple custom NSView subclass (which just fills itself with 
a single colour) that implements intrinsicContentSize property. So, I suppose 
the culprit here is not my constraints, but those within the AVPlayerView, 
which apparently limits its size and breaks hugging and compression resistance 
properties.

-- Dragan
___

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: Yet another autolayout question

[Dragan Milić]

On pet 13.11.2015., at 11.00, Ken Thomases wrote:

> Your screencast of the failing case shows that you have some additional views 
> (boxes, it looks like) in the hierarchy, and you haven't explained fully the 
> constraints involved.

I put those boxes just to give me some visual indication of how subviews are 
being resized. Their occupy their superviews completely, with a simple set of 
constraints:

* box.leading = superview.leading
* box.trailing = superview.trailing
* box.top = superview.top
* box.bottom = superview.bottom

So, I believe they don’t matter in this case.

> No, you misunderstand.
> 
> The holding priority is how "strongly" the slider keeps its position, in 
> general.  If you put a view into one pane and set its width and height at, 
> say, priority 750, and add constraints to keep its edges all around equal to 
> its superview's, then the user would be unable to drag the divider at all.
> 
> Suppose the split view allowed the user to drag the divider.  What happens 
> when the user lets go?  The holding priority is less than the priorities of 
> the view's size constraints, so the view would push or pull the divider and 
> return to its desired size.  Since the divider won't stay where the user put 
> it, it's best to not allow the user to drag it.
> 
> In all probability, the drag is actually implemented by adjusting a 
> constraint whose priority is the holding priority, so it stops as dictated by 
> that priority.

Ah okay, I didn’t realise that, but as I think of it, it does sound logical. 
However, even then I don’t understand why my particular case is failing. Let’s 
forget about the vertical splitView at the moment, and see what happens in the 
right of the window. Also, let’s say the superview of the playerView is high 
enough, so the previewView is on its intrinsic size. The holding priority of 
the top subview (containing the playerView) is 240 and for the bottom subview 
260. The playerView content resistance priority in both directions is 230.

As I drag the slider up, the vertical margins between the playerView and its 
superview are getting smaller, since the (required) constraints are set for 
them to be 20 or bigger. Once that limit is reached and they are required, they 
can’t go any smaller, so the size of the playerView comes into play. Since its 
compression resistance priority (230) is lower than that splitView's subview 
holding priority (as you’ve said, some invisible constraint implementing the 
drag with priority 240), I would expect the previewView to start shrinking. 
While doing so, maintaining its aspect ratio should not be a problem, since 
horizontal margins (their constraints) are set to be 20 or bigger.

-- Dragan
___

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: Yet another autolayout question

[Ken Thomases]

On Nov 13, 2015, at 3:43 AM, Dragan Milić  wrote:
> 
> Thanks for the suggestion, but unfortunately that didn’t help :-(

Hmm.  Oh well.

Your screencast of the failing case shows that you have some additional views 
(boxes, it looks like) in the hierarchy, and you haven't explained fully the 
constraints involved.


> What I fail to understand is why splitView’s subviews holding priorities 
> would matter at all, especially while dragging its slider. If I understand 
> documentation correctly, holding priorities of splitView’s subviews matter 
> only when the splitView is being resized (in affecting direction) as a whole, 
> that is as a consequence or its superview/window being resized. Why would 
> holding priorities matter when a slider is being dragged by a user?

No, you misunderstand.

The holding priority is how "strongly" the slider keeps its position, in 
general.  If you put a view into one pane and set its width and height at, say, 
priority 750, and add constraints to keep its edges all around equal to its 
superview's, then the user would be unable to drag the divider at all.

Suppose the split view allowed the user to drag the divider.  What happens when 
the user lets go?  The holding priority is less than the priorities of the 
view's size constraints, so the view would push or pull the divider and return 
to its desired size.  Since the divider won't stay where the user put it, it's 
best to not allow the user to drag it.

In all probability, the drag is actually implemented by adjusting a constraint 
whose priority is the holding priority, so it stops as dictated by that 
priority.

Regards,
Ken


___

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: Yet another autolayout question

[Dragan Milić]

On pet 13.11.2015., at 05.18, Ken Thomases wrote:

> Try, as an experiment, leaving out the aspect ratio constraint.  If that 
> changes the split view behavior, try putting it back but at a priority lower 
> than the split view holding priorities.
> 
> I suspect the problem is that, as the video player is forced to shrink, it 
> can't maintain its _exact_ aspect ratio (in part because the auto layout 
> system tries to maintain whole-pixel sizes).  Since the aspect ratio 
> constraint is at a higher priority than the split view holding priorities, 
> auto layout prefers to break those before breaking it.  Once it does decide 
> to break the aspect ratio constraint, it still tries to get as close as 
> possible, which is why the player does maintain its aspect ratio as far as 
> the eye can tell.

Thanks for the suggestion, but unfortunately that didn’t help :-(  What I fail 
to understand is why splitView’s subviews holding priorities would matter at 
all, especially while dragging its slider. If I understand documentation 
correctly, holding priorities of splitView’s subviews matter only when the 
splitView is being resized (in affecting direction) as a whole, that is as a 
consequence or its superview/window being resized. Why would holding priorities 
matter when a slider is being dragged by a user?

-- Dragan
___

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