Re: runModalForWindow is disabling my menus

[Felipe Monteiro de Carvalho]

On Sat, Sep 5, 2015 at 8:49 PM, Stephane Sudre  wrote:
> Which feature of a modal window are you looking for?

Disabling all other windows in the app and staying on top of them.

> Because having
> all the menu items being enabled in the case of a modal dialog does
> not match the nature of the modal mode (i.e. restricted mode).

In Mac OS X maybe, but in Linux and Windows there is no problem in a
modal window having a menu, so its not like its a conceptual problem.

>> Each menu item has itself as target and a method to respond to the action.
> Why not have at least a shared object as the target?

Why does this make any difference? The target supposedly is just a
method of an object, I don't see why Cocoa cannot call it. The object
must remain in memory. And if the object is in memory the method can
be called.

So you are saying that it would work if the target is not the menu item itself?

-- 
Felipe Monteiro de Carvalho
___

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: runModalForWindow is disabling my menus

[dangerwillrobinsondanger]

> On Sep 6, 2015, at 5:20 PM, Felipe Monteiro de Carvalho 
>  wrote:
> 
> In Mac OS X maybe, but in Linux and Windows there is no problem in a
> modal window having a menu, so its not like its a conceptual problem.
No. It IS a conceptual problem. 
That is not how Cocoa apps work. 
Don't try to fight the frameworks or do something that users won't expect 
because apps don't work like that on OS X. 
Find a different way that fits the platform. 
If you need a menu in your modal window use an NSPopUpButton 
___

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: runModalForWindow is disabling my menus

[Stephane Sudre]

On Sun, Sep 6, 2015 at 10:20 AM, Felipe Monteiro de Carvalho
 wrote:
> On Sat, Sep 5, 2015 at 8:49 PM, Stephane Sudre  wrote:
>> Which feature of a modal window are you looking for?
>
> Disabling all other windows in the app and staying on top of them.
>
>> Because having
>> all the menu items being enabled in the case of a modal dialog does
>> not match the nature of the modal mode (i.e. restricted mode).
>
> In Mac OS X maybe, but in Linux and Windows there is no problem in a
> modal window having a menu, so its not like its a conceptual problem.
>
>>> Each menu item has itself as target and a method to respond to the action.
>> Why not have at least a shared object as the target?
>
> Why does this make any difference? The target supposedly is just a
> method of an object, I don't see why Cocoa cannot call it. The object
> must remain in memory. And if the object is in memory the method can
> be called.

IMHO, it would just be cleaner both from a code and architecture (MVC)
point of view. Because the final target of your action is not the menu
item.

>
> So you are saying that it would work if the target is not the menu item 
> itself?

Usually, the FirstResponder object would be the target of the menu
item action so that if you implement the action in your window/dialog
controller or in another potential first responder in the dialog, the
menu item will be enabled (even without a validateMenuItem:
implementation).
___

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

Getting started with Cocoa Bindings in My Project?

[Alex Hall]

Hello list,
I've got a Mac app that has a table with a data source. Every few minutes, the 
data source updates itself, and when that happens, I call 
myTableView.reloadData(). This is a prime candidate for Cocoa bindings, so I 
thought I'd learn how that mechanism works, and make my code much prettier at 
the same time. It hasn't worked so far.

I understand the theory, I think. Where I'm getting lost is adapting what I've 
read to my own app. My data model is a dictionary of arrays, and the table is 
showing only one array at a time. I'm *not* trying to map the whole dictionary 
to the table at once; the model has a pointer that selects the current array in 
use, and then works on *only* that array. Methods in my view controller 
(specifically, menu items) change that pointer, letting the user move from 
array to array. The table, again, only ever shows one array at a time. It is a 
single-column table, not editable, not multi-selectable.

Since I'm using arrays, albeit retrieved from a dictionary, I thought an 
NSArrayController would do the job. I'm not sure what to enter for the key 
path, though. My view controller has a reference to both my table and my data 
model object, so I thought I'd give it the current array. I tried making the 
key path dataModel.myDict[datamodel.currentArray], but Xcode informed me that 
"myDict[dataModel" is not a valid key. Why it pulled just that part of what I'd 
actually entered, I'm not sure.

I then made a computed property in my view controller, so I could give the 
array controller a single-level property name but still get at the desired 
array. That failed too, but with slightly different error messages. This time, 
I saw
[Swift._SwiftDeferredNSArray persistentStoreCoordinator]: unrecognized selector 
sent to instance 0x6083ddc0

and then "an uncaught exception was raised", and then the first error again, 
for the same object.

I'm thoroughly confused now, and I'm not really sure where to start searching 
for answers, because I don't think I fully understand the problems I'm having. 
Now that I've rambled on about the background, I'll try to summarize what I'm 
having the most trouble with, conceptually and practically:

* I'm using Swift. Will that be a problem? I made both the computed property in 
my view controller and the dictionary of lists in my model "dynamic", and I 
made the object class of which my array's contents are instances subclass 
NSObject. Is there anything else I should do or know specific to Swift?
* MVC I get, but why are my binding choices for my NSArrayController only 
controllers themselves? That is, why do I need to hook up my controller to my 
model *through another controller*? Should I not just give the 
NSArrayController my model directly?
* When binding my NSTableView to my array controller, what, exactly, do I use 
for keys for both the table as a whole and the table cell? Again, I only have 
one column, if that matters.
* When and if I get all this working, do i still need my data source/delegate? 
It sounds like bindings replace that, but if so, where do my table cells get 
generated? Right now I use that function to set the textField.stringValue of 
the cell to the correct item in the current array; where would that happen in a 
bindings context?
* Assuming for a moment that my key is correct, and I want to bind to the array 
currently in use by the model, how would I do that? A dictionary lookup returns 
an optional, so for the moment--just to get things going--I'm forcing it to 
unwrap. Ideally, though, I'd include some way of handling a nil. How do 
bindings work with optionals?

At the end of the day, I want what bindings promises: my model updates, and 
each time it does (a row changes, is added, or is removed) my table updates to 
reflect that change. I'm using reloadData(), but I thought bindings would be 
far more elegant, extensible, and simple. I think it will be once I really 
understand how to use this system, but until then, it's seeming like way more 
trouble than it's worth. I really want to grasp this concept, though, and I'm 
still researching and reading. I'm hoping that being able to ask specific 
questions about my specific model will help to clarify what general-purpose 
explanations haven't. Thanks in advance for your help and patience.



--
Have a great day,
Alex Hall
mehg...@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: Swift generics, circular type declarations, and segfaults, oh my!

[has]

On 05/09/2015 07:07, Charles Srstka wrote:
On Sep 4, 2015, at 7:59 PM, Quincey Morris 
> wrote:


On Sep 4, 2015, at 16:31 , has > wrote:


At risk of derail...


Do you mean “derail” or “detail”? I feel like I’m drowning in details.


Yeah, this is why I kept the original posts light on specifics. 
Obviously adding these details didn't help clarify at all - but see 
Charles' final paragraph below.




What I mean is, in:

TextEdit().documents[1].text.words.get()

the instances represented by ‘TextEdit()’, 'TextEdit().documents[1]’, 
'TextEdit().documents[1].text’ are just setting the context for what 
the instance represented by 'TextEdit().documents[1].text.words’ is 
being asked to retrieve.




Basically. Each of those intermediates describes a valid query in 
itself; you just keep chaining var/method calls until you build up the 
query you actually want. Internally, it's just adding to a linked list 
of AE records (in pseudocode):


[every word [text [document 1 [application "TextEdit"

The final 'get' command packs that query into a 'getdata' Apple event 
and sends it off to the app to evaluate. Kinda like sending XPath 
queries over XML-RPC.




The way I’m reading it, he or she is wrapping an application’s 
scripting dictionary, creating a Swift object to wrap each construct 
that would represent a noun, so to speak, in AppleScript. However, 
these entities are expensive to obtain, involving IPC, so s/he’s 
loading them lazily.


Nope (he). Apple event IPC isn't a proxy object-based system like DO; 
it's not OOP at all. (Dictionaries are a lie.) The AE bridge only models 
queries, not 'classes'. So I only need to define a few classes, one to 
represent each type of query: root node, one-to-one relationship, 
one-to-many relationship, insertion point.


What this means is that the objects are all going to have some number 
of properties that, when the user accesses them, will necessitate 
creating a new wrapper object.


Yes. And because some properties (vars) represent one-to-one 
relationships, others represent one-to-many, they need to instantiate 
different query classes: ObjectSpecifier/ElementsSpecifier. Which is why 
I can't just use Self - e.g. the ObjectSpecifier representing the 'text' 
property needs to return an ElementsSpecifier to represent the 'words' 
elements.




I’m not the most knowledgeable about AppleScript, but what it sounds 
like from s/he’s saying is that the relationships between the 
AppleScript objects fall into three main categories, and for each type 
of object, there will be only one specific class to which each of the 
three relationships can point, so the object should be representable 
by a Swift generic with three parameterized types. However, if an 
object points to more of the same type of object, this results in 
something like Foo, and this causes either the compiler or the 
runtime to crash since it’s apparently not built to handle a generic 
being passed an object of its own type (honestly, this sounds like 
something warranting a Radar). S/he is asking if anyone knows of any 
way around this.


Yes! Exactly this. And yeah, I'm getting that sinking Radar feeling too. 
But since I'm relatively new to Swift, I'm just holding out a vain hope 
that there's some sort of solution that's embarrassingly obvious to 
everyone else but me.


Thanks,

has
___

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: "Computed segue" in iOS?

[Mike Abdullah]

Ideally, you use different cells for the different data elements, and wire them 
up to the appropriate segue, letting the system take care of most of it for you.

If you need something more complex, it’s time to trigger the segues 
programatically. You can wire up multiple segues from your source View 
Controller to other VCs.

Probably simples from there is to implement the UITableViewDelegate method 
which tells you a cell was selected and trigger the segue from it. But an 
alternative can be to wire up a single segue from the cell itself, and override 
-shouldPerformSegueWithIdentifier: to return NO and trigger a different segue 
instead.

> On 5 Sep 2015, at 01:03, Carl Hoefs  wrote:
> 
> iOS 8.4.1
> 
> I need to segue from a UITableView to different view controllers depending 
> which element in the table is touched (some elements are videos that need to 
> be displayed/edited, some are data files that need to be graphed, etc.).
> 
> Is it possible to have a "computed segue" in iOS such that I can segue 
> intelligently to the appropriate view controller based on some criteria? Or 
> must I use a "stopgap" view controller invoked by the UITableView that will 
> do the content analysis and then perform a segue to the appropriate view 
> controller?
> 
> -Carl
> 
> 
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.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: Getting started with Cocoa Bindings in My Project?

[Ken Thomases]

On Sep 6, 2015, at 10:59 AM, Alex Hall  wrote:

> Since I'm using arrays, albeit retrieved from a dictionary, I thought an 
> NSArrayController would do the job. I'm not sure what to enter for the key 
> path, though. My view controller has a reference to both my table and my data 
> model object, so I thought I'd give it the current array. I tried making the 
> key path dataModel.myDict[datamodel.currentArray], but Xcode informed me that 
> "myDict[dataModel" is not a valid key. Why it pulled just that part of what 
> I'd actually entered, I'm not sure.

Bindings is built on top of key-value coding (KVC) and key-value observing 
(KVO).  The model key path that a binding is bound to has to be, of course, a 
key path.  A key path is a series of keys separated by periods.  So, 
"dataModel.myDict[datamodel.currentArray]" looks like a path consisting of 
three keys, "dataModel", "myDict[datamodel", and "currentArray]".  Obviously, 
that's not right.

KVC can't do a two-stage lookup.  You effectively wanted it to parse 
datamodel.currentArray as a key path and get is value and then use that value 
as a key in a second key path, dataModel.myDict..  It 
doesn't do that.

KVC can traverse dictionaries, basically by treating them like an object with 
properties where the keys of the dictionary as the names of the properties.  It 
does not support the bracket syntax you tried to use and it does not support 
getting the key from a subexpression.


> I then made a computed property in my view controller, so I could give the 
> array controller a single-level property name but still get at the desired 
> array.

A computed property can work, but you need to do extra work to make it 
KVO-compliant.  Basically, KVO needs to be told what the computed property is 
based on so that when those underlying properties change it can emit change 
notifications for the computed property, too.

The easiest approach is to provided a class method named 
keyPathsForValuesAffecting which returns a set of key 
paths for the input properties.  In Objective-C, this might look like:

+ (NSSet*) keyPathsForValuesAffectingMyComputedProperty
{
return [NSSet setWithObjects:@"inputProperty1", "otherInputProperty", nil];
}

In Swift, I expect this needs to be "dynamic", too.

> That failed too, but with slightly different error messages. This time, I saw
> [Swift._SwiftDeferredNSArray persistentStoreCoordinator]: unrecognized 
> selector sent to instance 0x6083ddc0

Could your array controller be configured in Entity mode (for Core Data) rather 
than Object mode?


> * I'm using Swift. Will that be a problem? I made both the computed property 
> in my view controller and the dictionary of lists in my model "dynamic", and 
> I made the object class of which my array's contents are instances subclass 
> NSObject. Is there anything else I should do or know specific to Swift?

I'm not an expert, but I don't think there's anything else you need to do.

> * MVC I get, but why are my binding choices for my NSArrayController only 
> controllers themselves? That is, why do I need to hook up my controller to my 
> model *through another controller*? Should I not just give the 
> NSArrayController my model directly?

Array controllers are what Apple calls "mediating controllers".  View, window, 
and app controllers are "coordinating controllers".  Surely, it's natural for 
the model to be owned by a controller.  I mean, something is holding a strong 
reference to it.  Anyway, it's not a mediating controller's job to own the 
model, only to mediate between the view and another controller.

It is technically possible to make an array controller manage an array that it 
owns, but I don't see it as a good idea.  Why does it bother you?

> * When binding my NSTableView to my array controller, what, exactly, do I use 
> for keys for both the table as a whole and the table cell? Again, I only have 
> one column, if that matters.

From what you wrote below, I guess you're using a view-based table view rather 
than a cell-based one.  The way you set up bindings differs for the two cases.

For view-based tables, you bind the table view's Content binding to the array 
controller, controller key path "arrangedObjects".  You would not typically 
specify a model key path here, but you could if the table was not representing 
the elements of that array itself but rather some sub-property of the elements. 
 Usually, though, the table represents the elements and individual cell views 
select a property to show.  You bind the table view's Selection Indexes to the 
array controller, controller key path "selectionIndexes", no model key path.  
You bind the table view's Sort Descriptors to the array controller, controller 
key path "sortDescriptors", no model key path.

The table view uses the elements it gets via the Content binding to set the 
objectValue for each cell view, if the cell view has a setter for an 
objectValue property.  NSTableCellView does.  So do NSC

Re: Swift generics, circular type declarations, and segfaults, oh my!

[Charles Srstka]

On Sep 6, 2015, at 12:25 PM, has  wrote:
> 
> Yes! Exactly this. And yeah, I'm getting that sinking Radar feeling too. But 
> since I'm relatively new to Swift, I'm just holding out a vain hope that 
> there's some sort of solution that's embarrassingly obvious to everyone else 
> but me.

If it were me, I’d want to file a Radar ASAP, while the ABI is still malleable. 
Things like this might be a lot harder to fix later on.

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: Getting started with Cocoa Bindings in My Project?

[Charles Srstka]

> On Sep 6, 2015, at 1:14 PM, Ken Thomases  wrote:
> 
> The easiest approach is to provided a class method named 
> keyPathsForValuesAffecting which returns a set of key 
> paths for the input properties.  In Objective-C, this might look like:
> 
> + (NSSet*) keyPathsForValuesAffectingMyComputedProperty
> {
>return [NSSet setWithObjects:@"inputProperty1", "otherInputProperty", nil];
> }
> 
> In Swift, I expect this needs to be "dynamic", too.

Here’s the template for the keyPathsForValues… method in Swift:

private dynamic class func keyPathsForValuesAffecting<#name#>() -> Set {
return [<#dependency#>]
}

Note that in Objective-C, Xcode will autocomplete this method for you, but in 
Swift, it won’t. This gets fun when you realize that the above method is pretty 
easy to mistype and/or misremember, so what I suggest you do is copy and paste 
the code above into an Xcode code snippet, and give a keyword you can type that 
will autocomplete to it (I use ‘keyPaths’, so every time I start typing 
keyPaths, it’ll autocomplete to the above. It’s pretty helpful).

The “private” is so that it doesn’t show up in the public interface or 
generated Obj-C headers, because it’s pretty much unnecessary clutter there. 
The only code that will be calling this method is the KVC system, and it’ll be 
using -respondsToSelector: rather than the public interface anyway.

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

NSXMLDocument - XSLT version

[Jonathan Mitchell]

It seems that NSXMLDocument only supports XSLT v 1.0.
In particular I am interested in the date format support that is part of XSLT 2.

I have found extension code such as this:

http://exslt.org/date/functions/format-date/

But it seems rather old school.
Is there a better approach out there?

Sample NSDocument XSLT console output:

compilation error: element stylesheet
xsl:version: only 1.0 features are supported
xmlXPathCompOpEval: function current-dateTime not found
XPath error : Unregistered function
xmlXPathCompiledEval: evaluation failed
runtime error: element value-of
XPath evaluation returned no result.


Thanks

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

Re: Swift generics, circular type declarations, and segfaults, oh my!

[Quincey Morris]

On Sep 6, 2015, at 10:25 , has  wrote:
> 
> Each of those intermediates describes a valid query in itself; you just keep 
> chaining var/method calls until you build up the query you actually want.

Yes, that’s what I thought. I was trying to say that from an API perspective, 
it’s not necessary that the specifier objects (the predicates, so to speak) are 
the same objects as the IPC managers (the queries). It’s just that combining 
both behaviors into the same object is an economy of scale, since there are so 
many customized classes involved. Similarly, the question of creating brand new 
objects isn’t really significant to your API. It’s more of a policy decision 
that simplifies other implementation details. But …

> I'm getting that sinking Radar feeling too. But since I'm relatively new to 
> Swift, I'm just holding out a vain hope that there's some sort of solution 
> that's embarrassingly obvious to everyone else but me.

I’ve been thinking about the implications of this for a couple of days now. Of 
course, you should file a Radar if you see some compiler behavior that looks 
like it ought to work. But I think there’s a higher order problem that’s worth 
noting.

In my experience (which is to say, after a couple of months spent converting a 
fair-sized app from Obj-C to Swift), converting an Obj-C implementation to 
directly an “equivalent” Swift implementation is a lousy experience with poor 
results. There are several waves of consequences from the attempt:

1. You struggle to find a Swift equivalent of your Obj-C code. It takes forever.

2. You find your equivalent code ends up wordier and somehow more "unfactored" 
than the Obj-C code, even though it is somehow “the same”. You hate using it.

3. You fiddle with the Swift implementation (leaving Obj-C behind, finally) to 
make it a bit more streamlined. It takes forever.

4. You crash the compiler AND SourceKit, because you’ve ventured into uncharted 
territory in order to hide an Obj-C-derived mess behind Swift syntax. You have 
to look for workarounds at least until the next Xcode beta.

You seem to be in the process of trying to produce a Swift equivalent of your 
existing Obj-C implementation. You even state your abstract problems (how to 
arrange vendor methods in ObjectSpecifiers, for example) in Obj-C terms — as a 
subclassing problem, rather than a behavioral problem, which in Swift will tend 
to lead you first in the direction of protocols rather than subclasses. (But 
merely defining a protocol for each of your subclasses is not an improvement 
here.)

So, here’s what I suggest:

— Avoid the temptation to over-generalize in Swift. Capabilities like generics, 
overloading and even protocols (protocol extensions) seem to offer a magical 
veil to hide complexity. They don’t.

— Start with simple, straightforward solutions to your class APIs. Need three 
return types? Write three different methods.

— Write code that uses your class APIs as early as possible. (I’m talking about 
a small cluster of related classes, typically, not all the classes in the app.) 
Note what hurts to use, what’s too ugly, and what’s too verbose.

— Throw away your APIs and redesign them to be pleasant to use. Repeat this 
step as often as necessary.

— Use what feels natural in Swift, and take the time to experiment until you 
find it. Leave Obj-C behind.

Admittedly, I’ve retreated from your original topic to a matter of philosophy. 
Feel free to ignore the opinion if it doesn’t work for you, but again I assure 
you I speak from painful experience.



___

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 generics, circular type declarations, and segfaults, oh my!

[Charles Srstka]

> On Sep 6, 2015, at 3:19 PM, Quincey Morris 
>  wrote:
> 
> (But merely defining a protocol for each of your subclasses is not an 
> improvement here.)

It does, however, seem to avoid the crash:

class ObjectBase {
required init() {}
}

protocol MyProtocol {
func foo()
func bar()
func baz()
}

class MyObject: ObjectBase, MyProtocol {
func foo() { print("foo") }
func bar() { print("bar") }
func baz() { print("baz") }

required init() {}
}

let obj = MyObject()

compiles and runs without errors.

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: Swift generics, circular type declarations, and segfaults, oh my!

[Jonathan Mitchell]

> On 6 Sep 2015, at 21:19, Quincey Morris  
> wrote:
> 
> I’ve been thinking about the implications of this for a couple of days now. 
> Of course, you should file a Radar if you see some compiler behavior that 
> looks like it ought to work. But I think there’s a higher order problem 
> that’s worth noting.
> 
> In my experience (which is to say, after a couple of months spent converting 
> a fair-sized app from Obj-C to Swift), converting an Obj-C implementation to 
> directly an “equivalent” Swift implementation is a lousy experience with poor 
> results. There are several waves of consequences from the attempt:
> 
> 1. You struggle to find a Swift equivalent of your Obj-C code. It takes 
> forever.
> 
> 2. You find your equivalent code ends up wordier and somehow more 
> "unfactored" than the Obj-C code, even though it is somehow “the same”. You 
> hate using it.
> 
> 3. You fiddle with the Swift implementation (leaving Obj-C behind, finally) 
> to make it a bit more streamlined. It takes forever.
> 
> 4. You crash the compiler AND SourceKit, because you’ve ventured into 
> uncharted territory in order to hide an Obj-C-derived mess behind Swift 
> syntax. You have to look for workarounds at least until the next Xcode beta.
> 
Very interesting indeed. This is the sort of ‘from the trenches' report we need.

I did a few days work on my own fair substantially app with regard to Swift 
integration / conversion and made a reluctant gut instinct decision to stay 
with Obj-C (even though I really wanted to utilise Swift). There was just too 
much stuff (KVO, bindings etc) that didn’t feel like a good fit with Swift 
within an established project.

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

Getting a Popover's frame

[Jonathan Hull]

Hello,

I have a UIPopoverPresentationController and I would like to get the popover’s 
frame in either window coordinates or the presenting controller’s view’s 
coordinates.

A little background:  The popover contains a custom color picker, and after it 
opens, several passthrough views representing “pickable” colors are shown to 
allow the user to match the color of other objects on the screen.  I need the 
popover’s frame so I can move any of these views which would be covered by the 
popover to a location where the user can see them.

Any help is appreciated.  Let me know if I need to clarify anything about the 
question or provide additional details…

Thanks,
Jon
___

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 generics, circular type declarations, and segfaults, oh my!

[Jonathan Hull]

I am wondering if the compiler feature which might allow this (and several 
other things) would be to allow implementors of a protocol to adhere to it with 
a more restrictive type (either a subclass or an implementer/inheritor of a 
returned protocol).

For example:

protocol Thing {
var noise:String {get}
}

protocol MyProtocol {
func returnAThing()->Thing
}

class SquishyThing:Thing {
var noise:String {return “Squish”}
var squishiness:Int = 3
}

class PoppingThing:Thing {
var noise:String {return “Pop”}
var poppability:Float = 4.2 
}

class SquishyVendor:MyProtocol {
func returnAThing()-> SquishyThing {return SquishyThing()}
}

class PoppingVendor:MyProtocol {
func returnAThing()-> PoppingThing {return PoppingThing()}
}


This would allow you to say things like:

mySquishyVendor.returnAThing.squishiness = 6
myPoppingVendor.returnAThing.poppability = 2.8

instead of:

(mySquishyVendor.returnAThing as! SquishyThing).squishiness = 6
(myPoppingVendor.returnAThing as! PoppingThing).poppability = 2.8


Is there an obvious problem caused by this which I am missing?  I can think of 
3 or 4 places where it would shrink my code quite a bit.

Thanks,
Jon



> On Sep 6, 2015, at 1:50 PM, Charles Srstka  wrote:
> 
>> On Sep 6, 2015, at 3:19 PM, Quincey Morris 
>>  wrote:
>> 
>> (But merely defining a protocol for each of your subclasses is not an 
>> improvement here.)
> 
> It does, however, seem to avoid the crash:
> 
> class ObjectBase {
>   required init() {}
> }
> 
> protocol MyProtocol {
>   func foo()
>   func bar()
>   func baz()
> }
> 
> class MyObject: ObjectBase, MyProtocol {
>   func foo() { print("foo") }
>   func bar() { print("bar") }
>   func baz() { print("baz") }
>   
>   required init() {}
> }
> 
> let obj = MyObject()
> 
> compiles and runs without errors.
> 
> 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/jhull%40gbis.com
> 
> This email sent to jh...@gbis.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: Getting started with Cocoa Bindings in My Project?

[Alex Hall]

Thanks for the help, both you and Charles. I want to try to summarize the 
procedure as I now understand it, to make sure I have it all straight. No sense 
going and doing a bunch of work if I'm still missing something vital or don't 
have it right.

My first step is to make a KVO-compliant backing store, because Swift arrays 
won't do the job. As you said, my goal of updating an array and having my table 
automagically update itself to match the array just won't happen. What I need 
is a class that implements the methods described in the link you provided,so 
that bindings will work correctly. Obviously I can use an array internally, but 
the interface of the class *must* offer the necessary methods. I'll call this 
new class MyKVOCClass, because I'm terrible at naming things.

Next, remember that my model is a dictionary of arrays right now. The model has 
a single variable that can change to point at any of the arrays in the 
dictionary; the table is to display only that selected array (the table is 
view-based, one column, no multi-selecting, no editing). As the currently 
selected array changes, the table should update. I'll change this to be a 
dictionary of MyKVOCClass objects instead, so that when the array inside the 
selected object updates, the bound controller knows about it and can take 
action. Thus, instead of my model being [String:[MyObject]], it will be 
[String:MyKVOCClass]. The class will handle subscripting like an array, plus 
implement all the KVO stuff.

Next is the problem of accessing the current MyKVOCClass object from the view 
controller, where my model is instantiated. I'll need a computed property for 
this, which I'll call currentModelArray. This should return a reference to the 
currently active array in my model. You both suggested I implement
private func keyPathsForValuesAffectingCurrentModelArray() -> Set {}
in addition, so that as I change the value of the currently selected object in 
my model, the controller is notified. At least, that's how I understand the 
purpose of this method. The set this method returns contains strings; are those 
all the possible values the computed property can ever hold, or are they 
something else entirely? I'm just not clear on which strings to provide 
here--what you referred to as "input properties".

Alright, we have a KVO-compliant storage system in my model, and we have a 
properly configured computed property that will tell the controller (here 
referring to the ArrayController) where in my model to look. Time to connect 
things.

First, I'd look at the bindings inspector for the array controller. I'd set it 
to use my view controller, because it likes to default to Shared User Defaults 
Controller. Then I'd set the key to be the computed property I made earlier. 
Sorry if my terms aren't quite right; I've been working on other aspects of 
this project, so have removed the ArrayController from it for the moment and 
haven't yet put it back in, because things break when I do that. :)

Next I'd  look at the bindings for my table. I'd want to set the controller to 
my ArrayController, I don't know the specific words I'd use for keys here, but 
I'd *not* use any of my own variables, correct? This is all properties of the 
controller itself. This lets the controller figure out things like how many 
rows there are, what's selected, and so on.

Finally, repeat the previous step, but for the table cell. As before, I'm now 
using all properties of the controller, nothing *I* made anywhere. This uses 
the methods in my MyKVOCClass to get the actual data, then auto-generates the 
cells as needed. I'm not sure how this would work for a cell that's more than a 
text field, but that's a different topic, I guess. :)

That's how I understand the whole procedure. I thought it would be easier to 
just say what I've got then to try to keep replying in-line. Thanks again for 
the responses!
> On Sep 6, 2015, at 14:14, Ken Thomases  wrote:
> 
> On Sep 6, 2015, at 10:59 AM, Alex Hall  wrote:
> 
>> Since I'm using arrays, albeit retrieved from a dictionary, I thought an 
>> NSArrayController would do the job. I'm not sure what to enter for the key 
>> path, though. My view controller has a reference to both my table and my 
>> data model object, so I thought I'd give it the current array. I tried 
>> making the key path dataModel.myDict[datamodel.currentArray], but Xcode 
>> informed me that "myDict[dataModel" is not a valid key. Why it pulled just 
>> that part of what I'd actually entered, I'm not sure.
> 
> Bindings is built on top of key-value coding (KVC) and key-value observing 
> (KVO).  The model key path that a binding is bound to has to be, of course, a 
> key path.  A key path is a series of keys separated by periods.  So, 
> "dataModel.myDict[datamodel.currentArray]" looks like a path consisting of 
> three keys, "dataModel", "myDict[datamodel", and "currentArray]".  Obviously, 
> that's not right.
> 
> KVC can't do a two-stage lookup.  You e

Re: Getting started with Cocoa Bindings in My Project?

[Ken Thomases]

On Sep 7, 2015, at 12:01 AM, Alex Hall  wrote:

> My first step is to make a KVO-compliant backing store, because Swift arrays 
> won't do the job. As you said, my goal of updating an array and having my 
> table automagically update itself to match the array just won't happen. What 
> I need is a class that implements the methods described in the link you 
> provided,so that bindings will work correctly. Obviously I can use an array 
> internally, but the interface of the class *must* offer the necessary 
> methods. I'll call this new class MyKVOCClass, because I'm terrible at naming 
> things.

It's not particularly that the class must offer the necessary methods.  It's 
that your code must use those methods to modify the array or KVO is not aware 
of the changes you make.

It sounds like you're suggesting making a class just to be an array-like thing 
that is KVO-compliant.  That sounds to me like you're heading down the wrong 
road.  The class which needs to be KVO-compliant is the thing which currently 
holds the arrays (even if a bit indirectly).  That brings us to the next point…

> Next, remember that my model is a dictionary of arrays right now. The model 
> has a single variable that can change to point at any of the arrays in the 
> dictionary; the table is to display only that selected array (the table is 
> view-based, one column, no multi-selecting, no editing).

Can you explain in some more concrete terms why this level of dynamism is 
required?  What does the dictionary represent in some real-world sense or 
"business logic"?  What do the various arrays represent?  Is there a fixed set 
of arrays or is that variable?  What makes one of the arrays current and what 
does that signify (other than that's the one shown in the table)?  What other 
implications does it have?  What do the arrays have in common?  Why, other than 
happenstance or convenience, does it make sense for them to all be part of the 
same controller?

I'm asking because this design strikes me as one which will cause trouble and 
I'm looking for handholds for a suggested refactoring.  I'll wait for more info 
before getting into the other stuff.

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

recent applications list question

[Rick C.]

Hi,

I’m setting LSUIElement to 1 and using [NSApp 
setActivationPolicy:NSApplicationActivationPolicyRegular] to transform to 
visible depending upon user preferences.  However, this seems to have the 
effect of not having my app show up in the Recent Applications list.  Does 
anyone know if there is a workaround?  Thanks…

rc
___

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