Re: Merging scrolling/clipping with NSStackView

2017-01-20 Thread Jonathan Mitchell 

> On 19 Jan 2017, at 18:25, Quincey Morris 
>  wrote:
> 
> On Jan 19, 2017, at 06:39 , Daryle Walker  wrote:
>> 
>> The inner views should be as tall as they need to be.
> 
> I don’t understand this part. How tall is that?
> 
> I assume you mean that you want the text and table views to be tall enough to 
> show all of their contents, then stacked together and wrapped in a single 
> scroller. Conceptually that makes sense, but:
> 
> 1. The stack view is going to size itself, in the absence of explicit 
> constraints, based on the *intrinsic* sizes of the stacked views, and neither 
> text nor table view is going to report its full height as its intrinsic 
> height. Re-working them to provide that information is going to be very, very 
> painful.
> 
Everything Quincey says is right.
No surprise there then.

However, subclassing NSTableView and NSTextView to provide intrinsicContentSize 
does not have to be awful for a simple scenario (though these sort of things 
can descend into awfulness sometimes…)

Obviously you need to obtain raw NSTableView and NSTextView instances sans 
NSScollView containers.

NSTableView might go something like this:

@implementation TSTableView
 
- (NSSize)intrinsicContentSize
{
NSSize  size   = [super intrinsicContentSize];
NSInteger   nr  = [self numberOfRows];
CGFloat rh  = [self rowHeight];
CGFloat ih  = [self intercellSpacing].height;
size.height = rh * nr + ih * MAX(nr, 1);
return size;
}

For textviews I do something like:

@interface TSTextView : NSTextView

// primitives
@property (assign, nonatomic) CGFloat borderOffsetX;
@property (assign, nonatomic) CGFloat borderOffsetY;
@end


@implementation TSTextView

#pragma mark -
#pragma mark Life cycle

- (instancetype)initWithFrame:(NSRect)frameRect textContainer:(nullable 
NSTextContainer *)container
{
self = [super initWithFrame:frameRect textContainer:container];
if (self) {
[self commonInit];
}
return self;
}

- (nullable instancetype)initWithCoder:(NSCoder *)coder
{
self = [super initWithCoder:coder];
if (self) {
[self commonInit];
}
return self;
}

- (void)commonInit
{
_borderOffsetX = 1;
_borderOffsetY = 3;
self.usesFontPanel = NO;
self.usesFindPanel = NO;

}
#pragma mark -
#pragma mark Auto layout

- (NSSize)intrinsicContentSize
{
NSTextContainer* textContainer = [self textContainer];
NSLayoutManager* layoutManager = [self layoutManager];
[layoutManager ensureLayoutForTextContainer: textContainer];
NSSize size = [layoutManager usedRectForTextContainer: textContainer].size;

return NSMakeSize(NSViewNoInstrinsicMetric, size.height);
}

#pragma mark -
#pragma mark Accessors

- (void)setString:(NSString *)string
{
[super setString:string];
[self invalidateIntrinsicContentSize];
}

#pragma mark -
#pragma mark Text change notifications

- (void)didChangeText
{
[super didChangeText];
[self invalidateIntrinsicContentSize];
}

#pragma mark -
#pragma mark Focus ring

- (void)drawFocusRingMask
{
if (self.editable) {
NSRectFill(self.focusRingMaskBounds);
}
}

- (NSRect)focusRingMaskBounds {
NSRect r = [self bounds];
return NSMakeRect(r.origin.x - self.borderOffsetX, r.origin.y - 
self.borderOffsetY, r.size.width + self.borderOffsetX * 2, r.size.height + 
self.borderOffsetY * 2);
}


___

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: Merging scrolling/clipping with NSStackView

2017-01-20 Thread Quincey Morris 
On Jan 20, 2017, at 02:47 , Jonathan Mitchell  wrote:
> 
> NSTableView might go something like this:
> 
> @implementation TSTableView
> 
> - (NSSize)intrinsicContentSize
> {
>   NSSize  size   = [super intrinsicContentSize];
>   NSInteger   nr  = [self numberOfRows];
>   CGFloat rh  = [self rowHeight];
>   CGFloat ih  = [self intercellSpacing].height;
>   size.height = rh * nr + ih * MAX(nr, 1);
>   return size;
> }

My concern about this approach is timing. It needs to be supported by other 
code that triggers autolayout whenever the number of rows changes. Further, if 
the row height is not fixed (either because the height varies from row to row, 
or because the row height is a logical height influenced by the system-wide 
font size settings), it gets even more complicated.

The text field is less problematic, if for no other reason that a NSTextField 
has the desired behavior and it’s backed by a NSTextView. If the UI could have 
a text field instead of a text view there’d be no 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

Re: Merging scrolling/clipping with NSStackView

2017-01-20 Thread Jonathan Mitchell 

> On 20 Jan 2017, at 21:36, Quincey Morris 
>  wrote:
> 
> On Jan 20, 2017, at 02:47 , Jonathan Mitchell  > wrote:
>> 
>> NSTableView might go something like this:
>> 
>> @implementation TSTableView
>> 
>> - (NSSize)intrinsicContentSize
>> {
>>  NSSize  size   = [super intrinsicContentSize];
>>  NSInteger   nr  = [self numberOfRows];
>>  CGFloat rh  = [self rowHeight];
>>  CGFloat ih  = [self intercellSpacing].height;
>>  size.height = rh * nr + ih * MAX(nr, 1);
>>  return size;
>> }
> 
> My concern about this approach is timing. It needs to be supported by other 
> code that triggers autolayout whenever the number of rows changes. Further, 
> if the row height is not fixed (either because the height varies from row to 
> row, or because the row height is a logical height influenced by the 
> system-wide font size settings), it gets even more complicated.
Absolutely. Getting from raw concept to actual implementation for a particular 
use case can be a painful process.
And sometimes it is just not worth the candle.
I wince at the thought of the number of hours I have spent wrangling with auto 
layout.

___

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

curious: if not file references, what?

2017-01-20 Thread David Young 
This discussion seems to connect with a question I have had: what's the
"proper" way to refer from a first document to a second document, if
the second document may not have a fixed location in the filesystem?
It sounds like "file references" (perhaps these are roughly in
correspondence with an inode number?) are on their way out.  Should one
use some metadata that's indexed by Spotlight?

I ask because in the app that I'm building in my spare time, I would
like someday to create hyperlinks between documents.

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981
___

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: curious: if not file references, what?

2017-01-20 Thread Quincey Morris 
On Jan 20, 2017, at 19:10 , David Young  wrote:
> 
> This discussion seems to connect with a question I have had: what's the
> "proper" way to refer from a first document to a second document, if
> the second document may not have a fixed location in the filesystem?
> It sounds like "file references" (perhaps these are roughly in
> correspondence with an inode number?) are on their way out.

It’s not precisely the answer to the question of file references, but the 
correct way to reference one document from another is to use security scoped 
bookmarks. That throws the task of tracking the referenced file onto the system 
(a bookmark is much the same thing as an alias), plus it incorporates the 
sandbox-puncturing security check that allows you to re-open the referenced 
file when your app is re-launched, assuming the file was chosen by a user 
originally.

Currently, a bookmark might incorporate a file-reference URL and/or a file-path 
URL along with other metadata. If file-reference URLs are deprecated, the 
bookmark can be assumed to continue working regardless, and there should be no 
evil consequences from your point of view.

That’s assuming your app is sandboxed. If not, then just a regular bookmark 
should be fine.

It seems to me that the file-reference *behavior* is unlikely to go away. If 
anything changes, perhaps it will be that a file reference is no longer a kind 
of URL, but some other new class. Think about FileSpecs and FileRefs, which had 
API support for many years (at least 10, IIRC) after they were no longer 
recommended for use.

It’s an interesting question whether file-references use inode numbers. Some 
file systems don’t have them, so (I assume) they’re invented when such a file 
system is mounted, but they’re not necessarily assigned permanently across 
mounts. (I believe Apple documentation says not rely on the file number 
returned by NSURL metadata methods being stable across mounts.) Even when 
they’re baked into the file system, it’s not obvious what the semantics are 
when a volume is copied, or a volume is restored from backup. Perhaps someone 
else on this list is better informed on the subject than I am.

___

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: curious: if not file references, what?

2017-01-20 Thread Charles Srstka 
> On Jan 20, 2017, at 10:24 PM, Quincey Morris 
>  wrote:
> 
> It’s an interesting question whether file-references use inode numbers. Some 
> file systems don’t have them, so (I assume) they’re invented when such a file 
> system is mounted, but they’re not necessarily assigned permanently across 
> mounts. (I believe Apple documentation says not rely on the file number 
> returned by NSURL metadata methods being stable across mounts.) Even when 
> they’re baked into the file system, it’s not obvious what the semantics are 
> when a volume is copied, or a volume is restored from backup. Perhaps someone 
> else on this list is better informed on the subject than I am.

Actually, this is a common misconception; file references do *not* use inode 
numbers; they refer to CNIDs, which are a separate number stored in the catalog 
file. Inodes refer to raw file data on the disk; CNIDs point instead to a 
particular catalog node. You can have two or more hard links that all point to 
a specific file, but they’ll all have separate CNIDs, and if you delete one of 
them, you’ll break any file references pointing to that particular node.

Note that this is all HFS(+)-specific. APFS may be implemented differently, 
although in my limited testing, it appears to behave the same.

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