Re: PDF image template comes out too small
OK, if I open the PDFs in Preview, it says that the icons are 8x8 pts instead of 16x16. Exporting at a different DPI in Designer doesn't change this, but if I export from a document that itself has a different DPI (72 vs 144), then that can fix it. So I guess I have at thing or two to learn about working with Affinity Designer. On Wed, Jun 1, 2016 at 12:30 PM, Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Jun 1, 2016, at 10:55 , David Catmull wrote: > > > On OS X. I have an NSSegmentedControl in my xib, with my template images > assigned to the segments by specifying the image names. > > > It’s a bit hard to tell what’s going on if it’s all done in IB. You might > consider adding code to examine the images on the segments to see what’s > going on. > > I would try re-exporting the PDFs at a larger size (say 192 x 192, which > is a factor of 12). There may be an issue scaling the PDF *up* to get a > retina resolution of 32 x 32 px for 16 x 16 pt. > > This is going to be a problem if you really want the images to be 16 x 16 > pt regardless of the size of the control. If that is the case, I think it’s > better to provide them in an image catalog with 1x, 2x and/or 3x as > necessary. > > ___ 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
What type category should I use for my model in Swift?
[Warning: rambling] In Objective-C, you pretty much have to use a class for you model (in your MVC Cocoa app). But in Swift, you have the option to use a struct/enum or a non-NSObject class too. My model in mind is dumb data, so a struct seems appropriate. But your various Cocoa subclass would need to reference the model, and using a struct means it’s by value instead of reference, so coordinating changes would get harder. I’m guessing that I could use something like view-models, and only those VMs access the model, and always through referencing the containing object (like a NSDocument subclass). But a reference type, even a non-NSObject one, still seems easier. And I may want to use KVO or Core Data, which require NSObject subclasses. — 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: What type category should I use for my model in Swift?
> On Jun 2, 2016, at 8:55 AM, Daryle Walker wrote: > > [Warning: rambling] > > In Objective-C, you pretty much have to use a class for you model (in your > MVC Cocoa app). But in Swift, you have the option to use a struct/enum or a > non-NSObject class too. > > My model in mind is dumb data, so a struct seems appropriate. But your > various Cocoa subclass would need to reference the model, and using a struct > means it’s by value instead of reference, so coordinating changes would get > harder. > > I’m guessing that I could use something like view-models, and only those VMs > access the model, and always through referencing the containing object (like > a NSDocument subclass). But a reference type, even a non-NSObject one, still > seems easier. And I may want to use KVO or Core Data, which require NSObject > subclasses. In practical terms, a model typically both has value and reference types. If you take a game example, the data that describes the capabilities of a unit is value data, but the unit itself has identity and is thus a reference type. Also “Dumb” vs “Smart” data doesn’t really translate well to value vs reference – you can have “smart” structs and “dumb” classes (a Box class is a typical example of a “dumb" class – its entire purpose is to grant identity to a value type) – its really a matter of if you need identity or not. I would highly recommend you experiment and do what feels for your case. -- David Duncan ___ 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: What type category should I use for my model in Swift?
On Jun 2, 2016, at 08:55 , Daryle Walker wrote: > > My model in mind is dumb data, so a struct seems appropriate. The thing is, though, that Swift value objects are no dumber than reference objects (that is, structs can have behavior just like classes). Conversely, in Swift, the lack of behavior doesn’t really make structs a better choice for dumb data representation. > But your various Cocoa subclass would need to reference the model, and using > a struct means it’s by value instead of reference, so coordinating changes > would get harder. I think the question you need to ask yourself is whether the data represents the value of something, or whether it represents (a unique) something. Consider a document-based application where the document files where (for simplicity) the contents of each file is a simple string. It’s true that a string is a value, so that would seem to suggest that the data model should simply be a String (value). However, the String represents the contents of its *file*, which is a unique thing — a copy of a file is a different file, even if the contents are the same value. That means the correct data model in this case is a class (reference) with a String property (value). Note that you can “simulate” the latter with the former, if you do some combination of (a) passing the String variable around by reference [!], or (b) mutating the string via accessor functions that implicitly reference [!] the string. But, generally, if you approach it this way, you may as well have used a reference object to begin with. It seems to me there are cases where you it’s hard to decide whether something is a unique thing within your app design or not. In those circumstances, the correct answer is probably to use the representation that is most convenient to code for. ___ 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
On getting the wrong file type
The NSDocument file handler methods are passed a UTI string of the file's (supposed) type. What error are you supposed to throw when you get an unrecognized UTI? Or can you punt up to super for that default handling? 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: On getting the wrong file type
On Jun 2, 2016, at 12:26 , Daryle Walker wrote: > > The NSDocument file handler methods are passed a UTI string of the file's > (supposed) type. What error are you supposed to throw when you get an > unrecognized UTI? Or can you punt up to super for that default handling? You don’t say which methods you mean. (Depending on context, “handler” could mean NSDocument action method, NSDocumentController method, some delegate, file coordinator, etc.) You should not get any file type except those you put in your document file types in your info.plist. So, you could force a crash if you get something unrecognized, or (in the simple case of having only a single document type) you can just ignore the type completely. In Obj-C I used to be religious about checking this sort of thing early and often, because the dynamism could sometimes propagate incorrect behavior a long way. In Swift, because of the stricter type checking, unexpected values tend to blow up much earlier, so I’ve stopped bothering to put in explicit checks for things that are just going to explode naturally. (The price you pay is that such things are poorly reported when they occur, but OTOH they are never supposed to occur.) ___ 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: How can I make NSString.stringEncodingForData fail?
I worked around this by making the encodings list a method argument, defaulted to the values mentioned. Then I could test by running the method with an encoding that I know will fail. Sent from my iPhone > On May 29, 2016, at 3:23 AM, Daryle Walker wrote: > > I'm about to test code that uses this method. My encodings are: ASCII, UTF-8, > ISO Latin-1, then MacRoman. I think this covers all potential octet values. > My "guard" blocks (I'm using Swift.) are for a 0 return and if the optional > returned NSString can't be converted to a String. > > Can I cause some fail cases, or is that so unlikely that I should assert on > non-zero return and use "!" on the optional? > > 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/darylew%40mac.com > > This email sent to dary...@mac.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: When can String.enumerateSubstringsInRange ever pass in NIL?
But with your way, the method can't be reasonably unit-tested since a NIL may come up randomly. That seems pointless since you can synthesize the string from the other parameters anyway. Sent from my iPhone > On May 30, 2016, at 5:42 AM, Quincey Morris > wrote: > >> On May 29, 2016, at 22:31 , Ken Thomases wrote: >> >> I think the documentation for SubstringNotRequired is sufficient design >> contract: >> >> "NSStringEnumerationSubstringNotRequired >> "A way to indicate that the block does not need substring, in which case nil >> will be passed. This is simply a performance shortcut." > > This contract is of the form “if A then B”, from which it is NOT generally > valid to conclude “if not-A then not-B”. Plausibly, you can read a hidden > “only” into the documentation, but I’d still suggest not relying on it, since > it seems unnecessary. > ___ 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 getting the wrong file type
I'm writing about the load- and save-NSData methods of NSDocument that are supplied when selecting a (non-Core Data) Document-based project template. Sent from my iPhone > On Jun 2, 2016, at 3:57 PM, Quincey Morris > wrote: > >> On Jun 2, 2016, at 12:26 , Daryle Walker wrote: >> >> The NSDocument file handler methods are passed a UTI string of the file's >> (supposed) type. What error are you supposed to throw when you get an >> unrecognized UTI? Or can you punt up to super for that default handling? > > You don’t say which methods you mean. (Depending on context, “handler” could > mean NSDocument action method, NSDocumentController method, some delegate, > file coordinator, etc.) > > You should not get any file type except those you put in your document file > types in your info.plist. So, you could force a crash if you get something > unrecognized, or (in the simple case of having only a single document type) > you can just ignore the type completely. > > In Obj-C I used to be religious about checking this sort of thing early and > often, because the dynamism could sometimes propagate incorrect behavior a > long way. In Swift, because of the stricter type checking, unexpected values > tend to blow up much earlier, so I’ve stopped bothering to put in explicit > checks for things that are just going to explode naturally. (The price you > pay is that such things are poorly reported when they occur, but OTOH they > are never supposed to occur.) > > ___ 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
