Re: Purge all remnants of an old incarnation of my app

[2551phil]

Normally, I just do 

defaults delete  

on the command line and that takes care of it. Issuing 

defaults domains

will give you a (comma-separated) print out of all the defaults domains on your 
mac.



Best


Phil


> On 20 Jan 2017, at 03:49, Daryle Walker  wrote:
> 
> I posted this on the Xcode list, but one of the respondents suggested adding 
> it here too….
> 
>> On Jan 15, 2017, at 8:11 PM, Daryle Walker  wrote:
>> 
>> I threw away an app I made in Xcode 7, including clearing its Git space and 
>> replacing it with an empty branch. I created a new app with Xcode 8. 
>> However, I used the same bundle ID for the two apps. When I first ran the 
>> new app, I saw preference mismatch errors. I realized that, since I used the 
>> same ID for both apps, the new app was looking at the old app’s data. I 
>> deleted the preference file and the Xcode derived data folder. But even now, 
>> the new app’s open-recent list has a file I opened in the old app.
>> 
>> I’m asking: where are all the locations used by both Xcode and the system 
>> that automatically leave bundle-ID-marked files after compiling and running?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> 
> ___
> 
> 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/sqwarqdev%40icloud.com
> 
> This email sent to sqwarq...@icloud.com


___

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: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 19 janv. 2017 à 22:18, Daryle Walker  a écrit :
> 
> 
>> On Jan 16, 2017, at 12:08 PM, Charles Srstka  
>> wrote:
>> 
>>> On Jan 14, 2017, at 4:41 AM, Daryle Walker >> > wrote:
>>> 
>>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
>>> file moves. There are file references in macOS, which would be more stable, 
>>> but I read that there’s a bug in the URL class where it would degrade 
>>> file-reference URLs to standard-file URLs, so that’ll be problematic. 
>>> Another solution would to create bookmark data from a file URL and take a 
>>> hash of that. But are multiple bookmark data blocks of the same file URL 
>>> consistent enough for this idea to work?
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type. However, if 
>> you’re using Objective-C, file reference URLs will still work fine, and you 
>> can always make an Objective-C wrapper that stores a file reference URL and 
>> use that from Swift.
> 
> I looked at some code that gives a workaround for the file-reference URL 
> problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
> values, then sprinkles those onto a URL string template. Since UUIDs are 
> 128-bit values, I could just copy a reference ID directly into a UUID.

The file reference URL content is an implementation details and relying on the 
fact that a reference ID is 128 bit is very fragile IMHO, especially as Apple 
is planning to introduce a new FS soon. On APFS they may decide to use 
something completely different for file reference.



___

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: On NSIncrementalStore UUID Uniqueness

[Charles Srstka]

> On Jan 19, 2017, at 3:18 PM, Daryle Walker  wrote:
> 
> 
>> On Jan 16, 2017, at 12:08 PM, Charles Srstka > > wrote:
>> 
>>> On Jan 14, 2017, at 4:41 AM, Daryle Walker >> > wrote:
>>> 
>>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
>>> file moves. There are file references in macOS, which would be more stable, 
>>> but I read that there’s a bug in the URL class where it would degrade 
>>> file-reference URLs to standard-file URLs, so that’ll be problematic. 
>>> Another solution would to create bookmark data from a file URL and take a 
>>> hash of that. But are multiple bookmark data blocks of the same file URL 
>>> consistent enough for this idea to work?
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type. However, if 
>> you’re using Objective-C, file reference URLs will still work fine, and you 
>> can always make an Objective-C wrapper that stores a file reference URL and 
>> use that from Swift.
> 
> I looked at some code that gives a workaround for the file-reference URL 
> problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
> values, then sprinkles those onto a URL string template. Since UUIDs are 
> 128-bit values, I could just copy a reference ID directly into a UUID. 
> However it means existing files would have a different style, possibly 
> overlapping, than new files (which would take a random UUID). Maybe it’ll be 
> better to always use a random UUID, the implementers do in practice.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 

That workaround relies on private implementation details, so I wouldn’t 
recommend it. I’d rather just wrap an NSURL within an Objective-C type and then 
call that from Swift (which is what I do in my code).

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: On NSIncrementalStore UUID Uniqueness

[Charles Srstka]

> On Jan 16, 2017, at 12:48 PM, Quincey Morris 
>  wrote:
> 
> On Jan 16, 2017, at 09:08 , Charles Srstka  > wrote:
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type.
> 
> Does the given justification make any sense to you? It certainly makes no 
> sense to me. Perhaps I’m missing something, but the discussion seems to me to 
> conflate the idea of a reference type in Swift with the concept of 
> “referencing” in the world in general:
> 
>> “The[y] are both technically a different type in spirit[**] and they 
>> actually behave much more like a reference type than a structure.”
> 
> 
> By analogy, this is like saying that the Swift String type is good for 
> representing people’s names, but that Obj-C NSString should be used for 
> representing [US] people’s social security numbers, because a SSN is more 
> like a reference than a value.
> 
> In fact, URLs *are* strings — URLs as defined by the RFC, I mean — and that 
> takes the semantics of relating the string to the resource that the string 
> locates outside the scope of the representation itself.
> 
> Perhaps the problem is that file reference URLs don’t have an eternal, unique 
> string representation — that storing and reconstituting a file reference URL 
> may produce a different string? In that case, it’s the URL (the value, not 
> the type) that’s broken, and it’s just as broken in Obj-C as Swift.
> 
> 
> ** Incidentally, they aren’t a different *type* in spirit. File URLs and file 
> reference URLs are both URLs: uniform [syntactically conformant with the RFC] 
> resource [file, in this case] locators [specifiers of where to find]. The 
> difference is in the semantics of the file system, which really has nothing 
> to do with the syntax of the URL.

This post from Apple clarified their reasoning a bit:

https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html
 


Basically, they wanted to get rid of the optionality on many of URL’s 
properties; in Swift 2, .path was optional, .lastPathComponent was optional, 
and possibly some others as well. Apparently the only times those methods ever 
returned nil was when the URL in question was a file reference URL; in Swift 3, 
those methods are no longer optional, but file reference URLs are no longer 
supported. :-/

The part of the message that I find ominous is where he says “If references 
were still important”. When you start hearing language like that from Apple, 
it’s usually a sign that they consider the feature no longer relevant and soon 
to be axed. File references were always a key differentiator in the Mac user 
experience, and it would be very sad to see them go.

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: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 16, 2017, at 12:08 PM, Charles Srstka  wrote:
> 
>> On Jan 14, 2017, at 4:41 AM, Daryle Walker > > wrote:
>> 
>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
>> file moves. There are file references in macOS, which would be more stable, 
>> but I read that there’s a bug in the URL class where it would degrade 
>> file-reference URLs to standard-file URLs, so that’ll be problematic. 
>> Another solution would to create bookmark data from a file URL and take a 
>> hash of that. But are multiple bookmark data blocks of the same file URL 
>> consistent enough for this idea to work?
> 
> The thing with file reference URLs degrading to file path URLs is in the 
> Swift is actually not a bug, it’s deliberate 
> (https://bugs.swift.org/browse/SR-2728 
> ). The Swift team decided that file 
> reference URLs are not appropriate for the Swift URL value type. However, if 
> you’re using Objective-C, file reference URLs will still work fine, and you 
> can always make an Objective-C wrapper that stores a file reference URL and 
> use that from Swift.

I looked at some code that gives a workaround for the file-reference URL 
problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
values, then sprinkles those onto a URL string template. Since UUIDs are 
128-bit values, I could just copy a reference ID directly into a UUID. However 
it means existing files would have a different style, possibly overlapping, 
than new files (which would take a random UUID). Maybe it’ll be better to 
always use a random UUID, the implementers do in practice.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

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: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 16, 2017, at 3:59 AM, Alastair Houghton  
> wrote:
> 
> On 14 Jan 2017, at 10:41, Daryle Walker  wrote:
>> 
>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
>> file moves. There are file references in macOS, which would be more stable, 
>> but I read that there’s a bug in the URL class where it would degrade 
>> file-reference URLs to standard-file URLs, so that’ll be problematic. 
>> Another solution would to create bookmark data from a file URL and take a 
>> hash of that. But are multiple bookmark data blocks of the same file URL 
>> consistent enough for this idea to work?
> 
> FYI, you can base a UUID off any identifier you please, so if you have *any* 
> stable identifier, you can use that.  The way you do so is:
> 
> 1. Generate a UUID for your namespace, if there isn’t a standard one.  
> (Standard ones exist for domain names, URLs, OIDs and X.500 DNs.  Otherwise 
> just generate a version 1 or 4 UUID, as appropriate.)
> 
> 2. Use that and your identifier to compute an SHA-1 hash.
> 
> 3. Use the SHA-1 hash to generate a version 5 UUID.

I looked at NSIncrementalStore subclasses on GitHub for inspiration. (Couldn’t 
find any NSAtomicStore ones.) While in theory we should take at least 
semi-heroic measures, in practice everyone goes “screw it” and calls the random 
UUID function (from NSProcessInfo). One guy even hard-coded a “1” as the UUID!

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 


___

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: Purge all remnants of an old incarnation of my app

[Daryle Walker]

I posted this on the Xcode list, but one of the respondents suggested adding it 
here too….

> On Jan 15, 2017, at 8:11 PM, Daryle Walker  wrote:
> 
> I threw away an app I made in Xcode 7, including clearing its Git space and 
> replacing it with an empty branch. I created a new app with Xcode 8. However, 
> I used the same bundle ID for the two apps. When I first ran the new app, I 
> saw preference mismatch errors. I realized that, since I used the same ID for 
> both apps, the new app was looking at the old app’s data. I deleted the 
> preference file and the Xcode derived data folder. But even now, the new 
> app’s open-recent list has a file I opened in the old app.
> 
> I’m asking: where are all the locations used by both Xcode and the system 
> that automatically leave bundle-ID-marked files after compiling and running?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 


___

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: Swift: Draw a circle with tic marks at it's edge?

[Quincey Morris]

On Jan 19, 2017, at 05:48 , Eric E. Dolecki  wrote:
> 
> However, the position of the ticks
> is off. Seems like it needs to be moved down 1/2 way and the same to the
> right.

The position of the ticks is correct as you calculated, since you calculated 
relative to the view origin, which is at the upper left of the view bounds 
rect. (If you squint at the image carefully, you can see that it’s correct, 
showing the first and last ticks, with the rest being off the view to the left 
and top.) All you need to do is offset the x and y coordinates by the distances 
to the center of the view.

However, your image demonstrates a subtler bug which is something you need to 
deal with no matter how you end up drawing the view. Note that the visible 
horizontal tick in your image is clipped to the view bounds, so the line 
segment appears to be only half of the correct thickness. To get everything 
drawn properly, your drawing needs to be inset slightly from the edges of the 
view bounds. You have to ensure that there is sufficient inset to provide for:

a. the line thickness, when stroking a path

b. the end caps, when stroking a path

c. anti-aliasing, when drawing near the edges of the view bounds

Considerations such as those are why I suggested earlier as thinking of the 
drawing geometry as something different to the view geometry. Similar 
considerations apply to input, when your view is intended to be responsive to 
touches. If your drawn elements (the parts the user “grabs”) are too close the 
edge of the view, they can be hard to grab because the initial touch has a good 
chance of being passed to a different view.

Even if you’re using pre-rendered images instead of doing the drawing via 
bezier paths, you still have to consider the effects of bounds clipping on your 
drawing and touch interactions.

___

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

[Quincey Morris]

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.

2. Neither text nor table view is *intended* to be full height. Instead, they 
are intended to show a “window” of a fixed height onto a much taller virtual 
height. That’s why they come pre-wrapped in individual scroll views. A table 
view in particular is intended to prepare only the (relatively few) cells that 
are actually visible at any one time. By forcing it to its “full” height, 
you’re forcing it to keep every row in existence permanently. The performance 
might be acceptable if the table is not very large, but it’s still something of 
an abuse. Ditto the text view, although less so.

In such a situation, I think I would do one of the following:

— Rethink my UI so that I don’t have to stack the text and table views in this 
way.

— Use only a table view, and place the text view as the first row of the table. 
(With view-based table views, it’s easy to have more than one prototype cell 
view.) It would still be a bit messy, since it would be a variable-row-height 
table, but it’s likely less work than trying to achieve the same effect using 
stack view constraints.

— Use a (new-style) NSCollectionView, using two sections and custom flow 
layouts for the sections.

___

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: Swift: Draw a circle with tic marks at it's edge?

[Eric E. Dolecki]

Okay - Paintcode to the rescue. I made my art in Illustrator, and I can
support up to 45 values @ the moment (each segment an 8º rotation). I
if/else the hell out of whether or not a line gets stroked based on the
number of ticks. At least my artwork for the dial looks good now. Thanks
for that suggestion. If I ever need more than 45 values, I'll probably need
to revisit this solution, but I should be okay.

On Thu, Jan 19, 2017 at 8:48 AM Eric E. Dolecki  wrote:

> [image: knob.jpg]
>
> I have this Class that I am testing out. However, the position of the
> ticks is off. Seems like it needs to be moved down 1/2 way and the same to
> the right. I tried doing this with a shape layer and moving that - but it
> didn't change the appearance. Also, it seems like the spacing between ticks
> is way off (very far apart). I am looking for a solution to this current
> problem, please.
>
> class Disc: UIView {
>
> // Defaults.
> private var myOuterRadius: CGFloat = 100.0
> private var myInnerRadius: CGFloat = 90.0
> private var myNumberOfTicks: Int = 5
>
> override func draw(_ rect: CGRect)
> {
> let strokeColor = UIColor.black
> let tickPath = UIBezierPath()
> for i in 0.. let angle = CGFloat(i) * CGFloat(2 * M_PI) /
> CGFloat(myNumberOfTicks)
> let inner = CGPoint(x: myInnerRadius * cos(angle), y:
> myInnerRadius * sin(angle))
> let outer = CGPoint(x: myOuterRadius * cos(angle), y:
> myOuterRadius * sin(angle))
> print(angle, inner, outer)
> tickPath.move(to: inner)
> tickPath.addLine(to: outer)
> }
> tickPath.close()
> tickPath.lineCapStyle = .round
> strokeColor.setStroke()
> tickPath.lineWidth = 2
> tickPath.stroke()
> }
>
> init(width: CGFloat, numTicks: Int)
> {
> super.init(frame: CGRect(x: 0, y: 0, width: width, height: width))
> myOuterRadius = width / 2
> myInnerRadius = (width / 2) - 10
> myNumberOfTicks = numTicks
> self.backgroundColor = UIColor(netHex: 0xEE)
> self.layer.cornerRadius = CGFloat(width / 2)
> self.layer.masksToBounds = true
> }
>
> required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has
> not been implemented") }
> }
>
___

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

[Jonathan Mitchell]

> On 19 Jan 2017, at 14:39, Daryle Walker  wrote:
> 
> Right now, my window has a table view sitting on top of a text view. Those 
> templates from Interface Builder have those NSViews surrounded by a clip view 
> surrounded by a scroll view. But I want to flip that around; put the table 
> and text views together in a stack view, and surround that with clip and 
> scroll views as necessary. 
> 
> The stack view should be as wide as the window. The table and text views 
> should be as wide as their stack view. The inner views should be as tall as 
> they need to be. (The text view should be one line high if there's no text.) 
> I'm thinking of putting a horizontal line between the inner views
> 
> Any ideas how to do this?
> 
Adding the subviews to the NSStackView should be standard fare.
However, I always find getting the constraints correctly configured painful.

The trick with stack views and multiple subviews, IMHO, is to ensure that the 
subviews correctly constrain their height.
You may also need to constrain the bottom of the last subview to the bottom of 
the stackview, depending on how you want things to lay out.

For scrolling I use an NSStackView subclass 
(https://github.com/mugginsoft/TSStackView) that includes the following to 
embed it in a scroll view.
Looks like I had to use a flipped NSClipView to get things to work out.

The subclass is getting on a bit so parts of it may be redundant if you are 
targeting the more recent versions of MacOS.

#pragma mark -
#pragma mark Embedding
- (NSScrollView *)scrollViewContainer
{
NSScrollView *scrollView = nil;

if (self.scrollViewAllocated) {
scrollView = [self enclosingScrollView];
}
else {
self.scrollViewAllocated = YES;

// allocate scroll view
scrollView = [[NSScrollView alloc] initWithFrame:NSMakeRect(0, 0, 100, 
100)];
scrollView.translatesAutoresizingMaskIntoConstraints = NO;

// allocate flipped clip view
TSClipView *clipView = [[TSClipView alloc] 
initWithFrame:scrollView.contentView.frame];
scrollView.contentView = clipView;
NSAssert(scrollView.contentView.isFlipped, @"ScrollView contenView must 
be flipped? Use TSClipView");

// configure the scrollview
scrollView.borderType = NSNoBorder;
scrollView.hasHorizontalScroller = YES;
scrollView.hasVerticalScroller = YES;
scrollView.autohidesScrollers = YES;

// stackview is the document
scrollView.documentView = self;

// constrain stackview to match dimension of scrollview
NSDictionary *viewsDict = NSDictionaryOfVariableBindings(self);
NSString *vfl = nil;
if (self.orientation == NSUserInterfaceLayoutOrientationVertical) {
vfl = @"H:|-0-[self]-0-|";
} else {
vfl = @"V:|-0-[self]-0-|";
}
self.stackViewConstraints = [NSLayoutConstraint 
constraintsWithVisualFormat:vfl options:0 metrics:nil views:viewsDict];

[scrollView addConstraints:self.stackViewConstraints];
}

return scrollView;
}

@interface TSClipView : NSClipView

@end

@implementation TSClipView

- (BOOL)isFlipped
{
return YES;
}
@end

HTH

Jonathan


___

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

Merging scrolling/clipping with NSStackView

[Daryle Walker]

Right now, my window has a table view sitting on top of a text view. Those 
templates from Interface Builder have those NSViews surrounded by a clip view 
surrounded by a scroll view. But I want to flip that around; put the table and 
text views together in a stack view, and surround that with clip and scroll 
views as necessary. 

The stack view should be as wide as the window. The table and text views should 
be as wide as their stack view. The inner views should be as tall as they need 
to be. (The text view should be one line high if there's no text.) I'm thinking 
of putting a horizontal line between the inner views

Any ideas how to do this?

Sent from my iPhone
___

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: Swift: Draw a circle with tic marks at it's edge?

[Eric E. Dolecki]

[image: knob.jpg]

I have this Class that I am testing out. However, the position of the ticks
is off. Seems like it needs to be moved down 1/2 way and the same to the
right. I tried doing this with a shape layer and moving that - but it
didn't change the appearance. Also, it seems like the spacing between ticks
is way off (very far apart). I am looking for a solution to this current
problem, please.

class Disc: UIView {

// Defaults.
private var myOuterRadius: CGFloat = 100.0
private var myInnerRadius: CGFloat = 90.0
private var myNumberOfTicks: Int = 5

override func draw(_ rect: CGRect)
{
let strokeColor = UIColor.black
let tickPath = UIBezierPath()
for i in 0..___

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

MKMapView hybrid mode app hang problem

[Devarshi Kulshreshtha]

I have MKMapView on layout, if I enable Standard Mode and quickly perform
basic operations on it such as - zoom - in / out, pan it works fine but if
I perform same operations on MKMapView with hybridFlyover mode enabled CPU
utilisation reaches 100% and my app hangs.

Any ideas on how can resolve it?

-- 
Thanks,

Devarshi
___

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