Re: NSTextfield focus in contextual menu
On Thu, Jan 17, 2013, at 12:07 PM, Tamas Nagy wrote:
> Well, I came up with a solution. I subclassed NSTextfield with
>
> -(void)viewDidMoveToWindow {
>
> [self selectText:self];
> }
>
> and no it works as expected. When the menu pops out, the focus is on the
> textfield.
Glad it works, but don't forget to call super here.
Also, please file a bug asking for a true view-based menu implementation
so that such user interfaces are more reliable in future operating
systems. Without bugs, the Apple folks can't know who's trying to push
the system in certain directions.
--Kyle Sluder
___
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
Issue with Core Data Mapping Model
Hi, I am building a mapping model between two versions of my Core Data model, and I am encountering a strange issue: * If I define six of the seven entity mappings I need in the mapping model, migrating the data works as expected. * When I add the seventh entity mapping, the migration fails with this error: Persistent store migration failed, missing mapping model. * If I delete that seventh entity mapping, the migration works again. * I am trying to do the migration by calling addPersistentStoreWithType:… on the NSPersistentStoreCoordinator. * Reading in both the source and destination models with NSManagedObjectModel initWithContentsOfURL:... works as expected. * Reading in the NSMappingModel with initWithContentsOfURL:… works as expected. * With the seventh entity mapping added, reading in the mapping model with [NSMappingModel mappingModelFromBundles:@[bundle] forSourceModel:source destinationModel:dest] returns null. Using git I've confirmed that the only file I am changing is the mapping model file; I am not changing the models themselves. I would appreciate any thoughts on how to debug this further. Thank you. John ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
All good thoughts, but hold the phone. I think I have a mishmash a lot of old deprecated info plist keys and outright misapprehensions in my Info.plist, especially under CFBundleDocumentTypes and UTExportedTypeDeclarations. I think the file extension swapping will behave correctly once I've gotten it fixed. I will post an update tomorrow. I don't think your number 2 will be workable, since we're sandboxed/PowerBoxed here. If the NSSavePanel gives me a security scoped URL to a give file system path, I may not be able to write to a variant of that path. -Tom On Jan 17, 2013, at 4:57 PM, Quincey Morris wrote: > On Jan 17, 2013, at 16:20 , Thomas Bunch wrote: > >> Yes, in fact, I do exactly this. It's kind of suboptimal, in that >> NSSavePanel will first give you a warning: >> >> >> “Foo.oplx” already exists. Do you want to replace it?” and so on… the user >> will probably reflexively accept that one. >> >> Then we check and see that you're asking to dump a folder of web stuff, that >> the folder exists, that its contents don't look like a bucket of HTML and we >> pop up a second “That seems like a really bad idea, really really blow that >> away?” sheet. > > Working backwards, it seems to me you really, really want to retain this last > behavior in any situation where you're writing a folder to replace a folder. > Even if the extensions behaved the way they should, you could easily get a > situation where the user selected an entirely unrelated folder, and > "reflexively" accepted the warning about that replacement. > > If that's so, the extension behavior is somewhat a red herring. When you're > exporting multiple types via a single dialog, writing one of the types on top > of one of the other types is probably something you should always check for. > > A couple of other thoughts: > > 1. Is there any value in configuring your save panel to hide the "show/hide > extension" checkbox, and to always display extensions. That will, > incidentally, ensure that the saved item will show its extension in the > Finder, regardless of what the user normally does. You could then go ahead > and use '.htmld' without ever misleading the user that it wasn't there. > > 2. You could probably arrange to keep the "htmld" behavior in the dialog, and > rename the folder to remove the "htmld" at the end of the save. (You'd have > to use a NSDocument "perform…" method to ensure you re-set the document's > fileURL at the right time afterwards.) The drawback, of course, is that the > un-extensioned folder may already exist, and you don't know what the user > wants you to do about that. You *might* be able to mitigate that problem via > the save panel delegate's validate method. > > 3. Is there any value in the idea of exporting folders of stuff (that is, > exporting things that don't have a unique UTI) via a separate menu item that > doesn't involve choosing a type in its save panel? > ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
On Jan 17, 2013, at 16:20 , Thomas Bunch wrote: > Yes, in fact, I do exactly this. It's kind of suboptimal, in that NSSavePanel > will first give you a warning: > > > “Foo.oplx” already exists. Do you want to replace it?” and so on… the user > will probably reflexively accept that one. > > Then we check and see that you're asking to dump a folder of web stuff, that > the folder exists, that its contents don't look like a bucket of HTML and we > pop up a second “That seems like a really bad idea, really really blow that > away?” sheet. Working backwards, it seems to me you really, really want to retain this last behavior in any situation where you're writing a folder to replace a folder. Even if the extensions behaved the way they should, you could easily get a situation where the user selected an entirely unrelated folder, and "reflexively" accepted the warning about that replacement. If that's so, the extension behavior is somewhat a red herring. When you're exporting multiple types via a single dialog, writing one of the types on top of one of the other types is probably something you should always check for. A couple of other thoughts: 1. Is there any value in configuring your save panel to hide the "show/hide extension" checkbox, and to always display extensions. That will, incidentally, ensure that the saved item will show its extension in the Finder, regardless of what the user normally does. You could then go ahead and use '.htmld' without ever misleading the user that it wasn't there. 2. You could probably arrange to keep the "htmld" behavior in the dialog, and rename the folder to remove the "htmld" at the end of the save. (You'd have to use a NSDocument "perform…" method to ensure you re-set the document's fileURL at the right time afterwards.) The drawback, of course, is that the un-extensioned folder may already exist, and you don't know what the user wants you to do about that. You *might* be able to mitigate that problem via the save panel delegate's validate method. 3. Is there any value in the idea of exporting folders of stuff (that is, exporting things that don't have a unique UTI) via a separate menu item that doesn't involve choosing a type in its save panel? ___ 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: Changing color in NSColorPanel without message
On 18/01/2013, at 11:13 AM, Andy Lee wrote: > The OP actually wants to *suppress* changing of color. But good to know. Yep, I misremembered - helps to actually re-read the OPs message before commenting... :| However, it does incidentally solve that problem, in most cases, because the messages to FR are passed on to the object that is actually causing the change in the first place, and so it can be ignored. The main problem I've run into with that is that there can be "colateral damage", in that if you have a multiple selection and other objects can respond to -changeColor:, or you have unrelated colorwells selected, they can suddenly find themselves set to the colour of the newly clicked object. I think the underlying problem is that the color panel is designed primarily as an input device, used to SET a colour property of an object which in turn is expected to be represented by a colorwell. There are many other use-cases but these appear to be afterthoughts and the color-well situation takes priority. A typical case is when you want to set the colour of a chunk of selected text. That can be done easily by responding to the color panel, but if there's a selected colorwell anywhere, that gets that colour as well, which may supply the same colour to some totally unrelated object. Since that can be anywhere in your app's interface, it's not always obvious that this accidental synchronisation has taken place. There is no API to get the "current" colorwell to turn it off, or to turn all of them off at once, to prevent this. I've coded solutions to that myself by creating an object with a dummy invisible colorwell that I can select, which causes all others to be deselected so I can get the exclusive attention of the color panel. The final problem, which as I understand it is the OP's, is that if you want to use the color panel as an output device, to display the colour of something selected, you must take steps to redirect its action to a dummy target to prevent it sending up the responder chain, AND to turn off any colorwells that might be active to prevent them receiving the change as well, causing the same copying of a colour from one object to something completely unrelated via a colorwell. The same solution (an object with a dummy invisible colorwell) solves this too allowing you to turn off all other colorwells. --Graham ___ 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
Programmatically Determining the Rendered Size of an NSTextView
I am implementing a print merge function in my application, so I essentially need to take a template in an NSTextView, interpolate values, then add it to a growing view of some kind to be later printed. I have everything working well except how to concatenate the multiple "views" into a single view. What I find is that it all boils down to needing to know the size that any given NSTextView will grow itself into given a width. Basically whatever it does when it is being printed, but via code. Of course, I could just print every document individually but this could be thousands and thousands and seems unmanageable from a usability standpoint. Anyone have an idea how to do this? Pointers to docs/blogs/WWDC sessions welcome. TIA, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
Yes, in fact, I do exactly this. It's kind of suboptimal, in that NSSavePanel will first give you a warning: “Foo.oplx” already exists. Do you want to replace it?” and so on… the user will probably reflexively accept that one. Then we check and see that you're asking to dump a folder of web stuff, that the folder exists, that its contents don't look like a bucket of HTML and we pop up a second “That seems like a really bad idea, really really blow that away?” sheet. I think just giving this UTType a file extension is better than that experience, but having NSSavePanel properly maintain the extension (or lack thereof) would be better still. Though I could easily imagine having multiple export types whose Mime type is public.folder. -Tom On Jan 17, 2013, at 3:22 PM, Quincey Morris wrote: > On Jan 17, 2013, at 14:12 , Thomas Bunch wrote: > >> Launch, take your "document" (very much a stub), File -> Export…, "My Flat >> Format". Now File -> Export… again but this time pick "My HTML Folder >> Export". If you have your file extensions visible you'll see at this point >> that the extension is ".mff". Even so, the typical user will blow away their >> document at this point without a second thought. > > Can't you detect this situation in the save code itself? If you're actually > replacing a file with a folder, at least if file extensions were hidden when > the save panel closed, you might want to abort the save. If you're replacing > a folder with a folder … well, you'd have to decide if it's important that > the existing folder has an extension, or doesn't appear to be the kind of > folder contents you're replacing it with. > > Or, just look at the UTI for what you're replacing. If it's something your > app recognizes, you might want to avoid replacing it with a generic folder. > ___ 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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 6:44 PM, Graham Cox wrote: > > On 18/01/2013, at 9:19 AM, Andy Lee wrote: > >> o at least for color wells, changeColor: isn't the mechanism causing them to >> change color when you set the color panel's color. I would think they must >> be listening for the notification -- but I tried telling the color well to >> stop observing that notification and it *still* changed color. > > > Coming late to this discussion and may not have anything relevant to add, but > I have used these classes fairly extensively, including special custom > subclasses. > > Colorwells have some sort of per-application non-public controller that > allows only one to be active at a time - if you click on one, any other > already selected no matter where it is in your interface will be deselected. I never noticed that! And I just quickly confirmed it. Seems kind of rude that selecting a color well in one window can take first responder status away from a color well in a different window. > I believe this controller (which may just be some private class methods) is > also responsible for handling the interaction between the colorwell(s) and > the color panel. This bypasses the public interfaces AND the notification. In > other words, there is a private API that allows the color panel to know which > colorwell is the active one and directly set its colour. It sure behaves that way. Another possibility is that the mystery controller listens for the notification. This would mean the color panel sticks to its documented ways of updating other objects -- target-action, changeColor:, and notification -- and it's only the controller that has a backdoor relationship with NSColorWell. > For the OP's case though, hacking around with this mechanism is probably > unnecessary. To get some object to respond to -changeColor:, even if it's not > in the responder chain, is easy as long as you can get some object that is in > the responder chain (such as the view that is displaying them) to punt the > call down to it, by retargeting the method, for example, or using invocation > forwarding. I've used that approach extensively and it's pretty general - if > you have objects that can be selected that are displayed in some view, you > can get that view to be aware of the selected items and pass messages down to > them as if they were part of the responder chain. It's a very generic and I > think quite elegant approach. The selectable objects themselves can be > written *as if* they were first-class responders and rely on some higher > level controller or view to ensure they actually do receive the messages sent > to FR. The OP actually wants to *suppress* changing of color. But good to know. --Andy ___ 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: Changing color in NSColorPanel without message
On 18/01/2013, at 9:19 AM, Andy Lee wrote: > o at least for color wells, changeColor: isn't the mechanism causing them to > change color when you set the color panel's color. I would think they must be > listening for the notification -- but I tried telling the color well to stop > observing that notification and it *still* changed color. Coming late to this discussion and may not have anything relevant to add, but I have used these classes fairly extensively, including special custom subclasses. Colorwells have some sort of per-application non-public controller that allows only one to be active at a time - if you click on one, any other already selected no matter where it is in your interface will be deselected. I believe this controller (which may just be some private class methods) is also responsible for handling the interaction between the colorwell(s) and the color panel. This bypasses the public interfaces AND the notification. In other words, there is a private API that allows the color panel to know which colorwell is the active one and directly set its colour. For the OP's case though, hacking around with this mechanism is probably unnecessary. To get some object to respond to -changeColor:, even if it's not in the responder chain, is easy as long as you can get some object that is in the responder chain (such as the view that is displaying them) to punt the call down to it, by retargeting the method, for example, or using invocation forwarding. I've used that approach extensively and it's pretty general - if you have objects that can be selected that are displayed in some view, you can get that view to be aware of the selected items and pass messages down to them as if they were part of the responder chain. It's a very generic and I think quite elegant approach. The selectable objects themselves can be written *as if* they were first-class responders and rely on some higher level controller or view to ensure they actually do receive the messages sent to FR. --Graham ___ 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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 5:47 PM, Ken Thomases wrote: > On Jan 17, 2013, at 4:19 PM, Andy Lee wrote: > >> On Jan 17, 2013, at 4:45 PM, Andy Lee wrote: >> >>> On Jan 17, 2013, at 2:53 PM, Ken Thomases wrote: >>> On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: > Is it possible to programmatically change color (using -setColor:) in > NSColorPanel without it sending a changeColor: message to the first > responder? > > We'd like it to just reflect a color change without telling the responder > chain about it. I believe that NSColorPanel dispatches the -changeColor: action method using -[NSApplication sendAction:to:from:]. Therefore, you should be able to use a custom application object (subclass of NSApplication) with an override of that method which short-circuits for that selector (perhaps only under certain circumstances). >>> >>> Ooh! I tried overriding targetForAction:to:from: and targetForAction:, >>> assuming they were getting called. But I didn't think to try >>> sendAction:to:from:. Will give that a shot. >> >> Didn't work. >> >>> Note that even if this works, it doesn't suppress the >>> NSColorPanelColorDidChangeNotification, so there may still be unwanted side >>> effects of setting the color panel's color. >> >> NSColorWell doesn't implement changeColor:, yet when a color well is first >> responder it changes to match the color panel. >> >> I tried a subclass of NSColorWell that implements changeColor: as a no-op. >> The method got called, but the color well changed color anyway. >> >> So at least for color wells, changeColor: isn't the mechanism causing them >> to change color when you set the color panel's color. I would think they >> must be listening for the notification -- but I tried telling the color well >> to stop observing that notification and it *still* changed color. > > There are two issues here. One is whether -changeColor: is the method that's > invoked to effect a color change when a different color is selected in a > color panel. The other is how that method is invoked (whether by > -[NSApplication sendAction:to:from:]). > > There's also a confounding factor that NSColorWell and NSColorPanel may be > intimately connected in a way that other classes are not. > > As I understood it, Melvin was concerned that an arbitrary text view was > having its color changed. It seems like quite a different scenario than the > color in the color well that invoked the color panel. No, it's the same scenario. I happened to use the color well to bring up the color panel, but that doesn't matter. What matters is that the color well was first responder on the key window at the time I called setColor: on the color panel, which I did via a pushbutton action. > The color well may indeed have intimate knowledge about the color panel or > vice-versa, but I doubt there's any non-generic mechanism by which the text > view's color was changed. If there were, it would have to be documented so > that one's own view classes (including custom text view subclasses) could > participate. Both changeColor: and the notification are indeed triggered. I haven't tested target-action but I'm sure it works too. > For one thing, it's apparently a known solution to implement -changeColor: in > various subclasses to disable it. Oh, wow, sure, that would do it. > So, that answers the question of whether (for things other than color wells) > the change goes through -changeColor:. Your experiments seems to indicate > that that's not the case for NSColorWell, Yup. Also note the API makes no claim about what mechanism is used for any given control. It could be changeColor: today and notifications or some secret backdoor tomorrow. I can't think why it would change, but it's theoretically possible. > but it seems to be the case for other responders. > > It remains to be seen if the invocation of -changeColor: is dispatched via > -sendAction:to:from:. It is. I overrode sendAction:to:from: in my application subclass. > I actually looked at the disassembly of the AppKit (on Snow Leopard) to see > that it does, although it's always possible I missed something. One could > put a breakpoint on -[NSTextView changeColor:] and look at the backtrace to > see. Again, on Snow Leopard this technique shows it's called from > -sendAction:to:from:. I would assume changeColor: is always sent to the first responder regardless of the class of the current first responder. It wouldn't make sense to first check what kind of object the first responder is, and send the message or not accordingly. Rather, let the responder chain sort it out. The mystery here (unless I messed up my tests) is how color wells get updated and why they should be different from other controls in this respect. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not p
Re: Using NSSavePanel to export to UTTypeFolder without a file extension.
On Jan 17, 2013, at 14:12 , Thomas Bunch wrote: > Launch, take your "document" (very much a stub), File -> Export…, "My Flat > Format". Now File -> Export… again but this time pick "My HTML Folder > Export". If you have your file extensions visible you'll see at this point > that the extension is ".mff". Even so, the typical user will blow away their > document at this point without a second thought. Can't you detect this situation in the save code itself? If you're actually replacing a file with a folder, at least if file extensions were hidden when the save panel closed, you might want to abort the save. If you're replacing a folder with a folder … well, you'd have to decide if it's important that the existing folder has an extension, or doesn't appear to be the kind of folder contents you're replacing it with. Or, just look at the UTI for what you're replacing. If it's something your app recognizes, you might want to avoid replacing it with a generic folder. ___ 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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 4:19 PM, Andy Lee wrote: > On Jan 17, 2013, at 4:45 PM, Andy Lee wrote: > >> On Jan 17, 2013, at 2:53 PM, Ken Thomases wrote: >> >>> On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: >>> Is it possible to programmatically change color (using -setColor:) in NSColorPanel without it sending a changeColor: message to the first responder? We'd like it to just reflect a color change without telling the responder chain about it. >>> >>> I believe that NSColorPanel dispatches the -changeColor: action method >>> using -[NSApplication sendAction:to:from:]. Therefore, you should be able >>> to use a custom application object (subclass of NSApplication) with an >>> override of that method which short-circuits for that selector (perhaps >>> only under certain circumstances). >> >> Ooh! I tried overriding targetForAction:to:from: and targetForAction:, >> assuming they were getting called. But I didn't think to try >> sendAction:to:from:. Will give that a shot. > > Didn't work. > >> Note that even if this works, it doesn't suppress the >> NSColorPanelColorDidChangeNotification, so there may still be unwanted side >> effects of setting the color panel's color. > > NSColorWell doesn't implement changeColor:, yet when a color well is first > responder it changes to match the color panel. > > I tried a subclass of NSColorWell that implements changeColor: as a no-op. > The method got called, but the color well changed color anyway. > > So at least for color wells, changeColor: isn't the mechanism causing them to > change color when you set the color panel's color. I would think they must be > listening for the notification -- but I tried telling the color well to stop > observing that notification and it *still* changed color. There are two issues here. One is whether -changeColor: is the method that's invoked to effect a color change when a different color is selected in a color panel. The other is how that method is invoked (whether by -[NSApplication sendAction:to:from:]). There's also a confounding factor that NSColorWell and NSColorPanel may be intimately connected in a way that other classes are not. As I understood it, Melvin was concerned that an arbitrary text view was having its color changed. It seems like quite a different scenario than the color in the color well that invoked the color panel. The color well may indeed have intimate knowledge about the color panel or vice-versa, but I doubt there's any non-generic mechanism by which the text view's color was changed. If there were, it would have to be documented so that one's own view classes (including custom text view subclasses) could participate. For one thing, it's apparently a known solution to implement -changeColor: in various subclasses to disable it. So, that answers the question of whether (for things other than color wells) the change goes through -changeColor:. Your experiments seems to indicate that that's not the case for NSColorWell, but it seems to be the case for other responders. It remains to be seen if the invocation of -changeColor: is dispatched via -sendAction:to:from:. I actually looked at the disassembly of the AppKit (on Snow Leopard) to see that it does, although it's always possible I missed something. One could put a breakpoint on -[NSTextView changeColor:] and look at the backtrace to see. Again, on Snow Leopard this technique shows it's called from -sendAction:to:from:. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Changing color in NSColorPanel without message
On Jan 17, 2013, at 2:53 PM, Ken Thomases wrote: > On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: > >> Is it possible to programmatically change color (using -setColor:) in >> NSColorPanel without it sending a changeColor: message to the first >> responder? >> >> We'd like it to just reflect a color change without telling the responder >> chain about it. > > I believe that NSColorPanel dispatches the -changeColor: action method using > -[NSApplication sendAction:to:from:]. P.S. You were right about this. --Andy ___ 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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 4:45 PM, Andy Lee wrote: > On Jan 17, 2013, at 2:53 PM, Ken Thomases wrote: > >> On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: >> >>> Is it possible to programmatically change color (using -setColor:) in >>> NSColorPanel without it sending a changeColor: message to the first >>> responder? >>> >>> We'd like it to just reflect a color change without telling the responder >>> chain about it. >> >> I believe that NSColorPanel dispatches the -changeColor: action method using >> -[NSApplication sendAction:to:from:]. Therefore, you should be able to use >> a custom application object (subclass of NSApplication) with an override of >> that method which short-circuits for that selector (perhaps only under >> certain circumstances). > > Ooh! I tried overriding targetForAction:to:from: and targetForAction:, > assuming they were getting called. But I didn't think to try > sendAction:to:from:. Will give that a shot. Didn't work. > Note that even if this works, it doesn't suppress the > NSColorPanelColorDidChangeNotification, so there may still be unwanted side > effects of setting the color panel's color. NSColorWell doesn't implement changeColor:, yet when a color well is first responder it changes to match the color panel. I tried a subclass of NSColorWell that implements changeColor: as a no-op. The method got called, but the color well changed color anyway. So at least for color wells, changeColor: isn't the mechanism causing them to change color when you set the color panel's color. I would think they must be listening for the notification -- but I tried telling the color well to stop observing that notification and it *still* changed color. I bet behind the scenes a different mechanism is being used to update color wells than is provided to us devs in the API. Not target-action (I set the target to nil), not changeColor:, not the notification -- I even checked whether the color well is using KVO on the @"color" property of the color panel. If none of these mechanisms, I wonder how. Apple *really* doesn't want us to do this. --Andy ___ 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
Using NSSavePanel to export to UTTypeFolder without a file extension.
Hi folks, NSSavePanel does not like UTTypes with no file extension. Under PowerBox, I can't find a good workaround. One of OmniPlan's export types is a directory full of HTML and associated resources. Being an old NeXT guy, I immediately called this a .htmld file, but when the feature was debuted, the file extension was universally reviled. The most salient feedback was that real users tend to have file extensions hidden, and when they deploy this export to a web server they don't tend to realize that the file extension is part of the URL and compose their hyperlinks accordingly. People just want a directory with no file extension. I'm certain I'm not the only one who has encountered this issue, but Google is not providing anything useful. If you set things up in a way that ought to work (says I) you set yourself up for potential data-loss. When you switch file types on the NSSavePanel, the file extension is managed for you. If one of your exportable types has no file extension, it just leaves the extension from the prior selected file type. When people are exporting reports and so forth, they are quite accustomed to blowing away the previous revision of the report. In this case, the inevitable result is that they will replace their document, foo.oplx, with a directory called foo.oplx that in fact contains HTML and friends. To see this in action, download and build the following sample project: https://www.dropbox.com/s/vqun19at5efzjrc/NSSavePanel-kUTTypeFolder.zip Launch, take your "document" (very much a stub), File -> Export…, "My Flat Format". Now File -> Export… again but this time pick "My HTML Folder Export". If you have your file extensions visible you'll see at this point that the extension is ".mff". Even so, the typical user will blow away their document at this point without a second thought. Remember that we're under PowerBox here, so the URL returned by the save panel is the one we must use. There is no sanitizing it later. This might be a good time to agitate for -[NSDocument changeSaveType:] to be made public. With recent changes to NSSavePanel (especially observing its accessoryPanel's frame) this is less critical now, and in fact there is nothing you can do here to rectify the issue at hand. Did I remember to ask a question? Right… has anyone managed to get NSSavePanel to work properly with exportable types that have no extension. And if not, has a successor to the .htmld extension emerged that has traction? Thanks. -Tom ___ 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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 2:53 PM, Ken Thomases wrote: > On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: > >> Is it possible to programmatically change color (using -setColor:) in >> NSColorPanel without it sending a changeColor: message to the first >> responder? >> >> We'd like it to just reflect a color change without telling the responder >> chain about it. > > I believe that NSColorPanel dispatches the -changeColor: action method using > -[NSApplication sendAction:to:from:]. Therefore, you should be able to use a > custom application object (subclass of NSApplication) with an override of > that method which short-circuits for that selector (perhaps only under > certain circumstances). Ooh! I tried overriding targetForAction:to:from: and targetForAction:, assuming they were getting called. But I didn't think to try sendAction:to:from:. Will give that a shot. Note that even if this works, it doesn't suppress the NSColorPanelColorDidChangeNotification, so there may still be unwanted side effects of setting the color panel's color. --Andy (for some reason obsessed with Melvin's 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: CALayer renderInContext changes zPosition of some child layers
On Jan 5, 2013, at 7:29 AM, David Duncan wrote: > On Jan 3, 2013, at 12:46 AM, Markus Spoettl wrote: > >> […] >> I've been debugging this one for quite a while until I realized that missing >> layers are not missing but somehow their zPosition got messed up so they >> ended up below another sibling layer. >> >> Since the affected layers need to be siblings in the same parent layer I >> can't fix this by making them sub-layers to enforce the hierarchy. >> >> Why does this happen and how can I fix it? > > > My best guess would be that -renderInContext: always renders in the same > order you get from the -sublayers array, without the zPosition sorting you > get on display. This is probably a bug, but your best work around would be to > sort the sublayers array yourself rather than relying upon zPosition to do so. I agree. The Core Animation Programming Guide says this: “The zPosition property specifies the z-axis component of the layer's position. The zPosition is intended to be used to set the visual position of the layer relative to its sibling layers. It should not be used to specify the order of layer siblings, instead reorder the layer in the sublayer array.” … but renderInContext: seems to have a more or less opposite philosophy. -Tom ___ 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: NSTextfield focus in contextual menu
Well, I came up with a solution. I subclassed NSTextfield with
-(void)viewDidMoveToWindow {
[self selectText:self];
}
and no it works as expected. When the menu pops out, the focus is on the
textfield.
Tamas
On Jan 17, 2013, at 8:54 PM, Kyle Sluder wrote:
> On Thu, Jan 17, 2013, at 11:38 AM, Tamas Nagy wrote:
>> Hi List,
>>
>> I have an application (10.6>) where are have a contextual menu with an
>> NSTextfield. What I'm trying is when I displaying the menu with [NSMenu
>> popupContextual…] making the NSTextfield focused, but without luck.
>>
>> I tried setting [mytextfield becomeFirstResponder] and [mytestfield
>> selectText:nil] before the popup method called, but it not works - I'm
>> not sure this is technology even possible.
>
> Sadly, views-in-menus is a generally broken technology. It's good for
> drawing custom content, but that's about it.
>
> If you want to do this, you'll probably want to build a custom
> NSMenu-lookalike. This is how Spotlight is implemented, for example.
>
> Alternatively, you may be able to subclass -[NSApplication sendEvent:]
> and feed the right data to the text field on your menu. I've heard
> rumblings that this is how Xcode implements its typeahead searching in
> menus.
>
> --Kyle Sluder
___
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: NSTextfield focus in contextual menu
Thanks for the info and the tips Kyle! Tamas On Jan 17, 2013, at 8:54 PM, Kyle Sluder wrote: > On Thu, Jan 17, 2013, at 11:38 AM, Tamas Nagy wrote: >> Hi List, >> >> I have an application (10.6>) where are have a contextual menu with an >> NSTextfield. What I'm trying is when I displaying the menu with [NSMenu >> popupContextual…] making the NSTextfield focused, but without luck. >> >> I tried setting [mytextfield becomeFirstResponder] and [mytestfield >> selectText:nil] before the popup method called, but it not works - I'm >> not sure this is technology even possible. > > Sadly, views-in-menus is a generally broken technology. It's good for > drawing custom content, but that's about it. > > If you want to do this, you'll probably want to build a custom > NSMenu-lookalike. This is how Spotlight is implemented, for example. > > Alternatively, you may be able to subclass -[NSApplication sendEvent:] > and feed the right data to the text field on your menu. I've heard > rumblings that this is how Xcode implements its typeahead searching in > menus. > > --Kyle Sluder ___ 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: NSTextfield focus in contextual menu
On Thu, Jan 17, 2013, at 11:38 AM, Tamas Nagy wrote: > Hi List, > > I have an application (10.6>) where are have a contextual menu with an > NSTextfield. What I'm trying is when I displaying the menu with [NSMenu > popupContextual…] making the NSTextfield focused, but without luck. > > I tried setting [mytextfield becomeFirstResponder] and [mytestfield > selectText:nil] before the popup method called, but it not works - I'm > not sure this is technology even possible. Sadly, views-in-menus is a generally broken technology. It's good for drawing custom content, but that's about it. If you want to do this, you'll probably want to build a custom NSMenu-lookalike. This is how Spotlight is implemented, for example. Alternatively, you may be able to subclass -[NSApplication sendEvent:] and feed the right data to the text field on your menu. I've heard rumblings that this is how Xcode implements its typeahead searching in menus. --Kyle Sluder ___ 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: Changing color in NSColorPanel without message
On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: > Is it possible to programmatically change color (using -setColor:) in > NSColorPanel without it sending a changeColor: message to the first responder? > > We'd like it to just reflect a color change without telling the responder > chain about it. I believe that NSColorPanel dispatches the -changeColor: action method using -[NSApplication sendAction:to:from:]. Therefore, you should be able to use a custom application object (subclass of NSApplication) with an override of that method which short-circuits for that selector (perhaps only under certain circumstances). 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
NSTextfield focus in contextual menu
Hi List, I have an application (10.6>) where are have a contextual menu with an NSTextfield. What I'm trying is when I displaying the menu with [NSMenu popupContextual…] making the NSTextfield focused, but without luck. I tried setting [mytextfield becomeFirstResponder] and [mytestfield selectText:nil] before the popup method called, but it not works - I'm not sure this is technology even possible. Thanks for any thoughts, Tamas ___ 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: Thread synchronization via queue
On Jan 17, 2013, at 10:22 AM, Kyle Sluder wrote: > On Jan 17, 2013, at 2:09 AM, Charles Srstka wrote: > >> You could start a run loop in a dispatch queue, schedule the NSInputStream >> on that runloop, and then have the delegate methods block/unblock your >> reading thread via a lock/semaphore/etc. > > Do not start a runloop in a block submitted to a dispatch queue. You do not > own the thread that your block is executing on, therefore you should not > mutate thread state. For all you know, if you dispatch_async from a > background thread, your block will execute on the main thread. Ah, good point. I shouldn't have written that post at 4 AM. That's not really the only problem with that post; in actuality, there's no reason that the NSInputStream would have to be on another thread at all. You could just schedule it on the main run loop; since all it would be doing would be sending signals to the worker thread anyway, it's unlikely that it would take much time from the thread it's running in. 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: Thread synchronization via queue
On Jan 17, 2013, at 2:09 AM, Charles Srstka wrote: > You could start a run loop in a dispatch queue, schedule the NSInputStream on > that runloop, and then have the delegate methods block/unblock your reading > thread via a lock/semaphore/etc. Do not start a runloop in a block submitted to a dispatch queue. You do not own the thread that your block is executing on, therefore you should not mutate thread state. For all you know, if you dispatch_async from a background thread, your block will execute on the main thread. --Kyle Sluder ___ 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: Thread synchronization via queue
On Jan 17, 2013, at 2:40 AM, Rick Mann wrote: > I can't change the complex process to work in discrete chunks. But you have access to the writing process source so that you can add a few lines of code for synchronization stuff? If so, this is kind of a classic case for a condition variable; there are Cocoa classes (NSConditionVariable iirc) for it; and I'd be surprised if there isn't something in GCD... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
tappable strings
I have some NSAttributedStrings which I'm currently using a UILabel to draw. They are made up of several elements, words in more than one language, and I want the strings to be tappable and to know where in the string I tapped. I looked at NSStringDrawingContext which gives you some overall information about drawing a string, but not where the individual characters ended up. Is this something I have to drop down to Core Text for? I'd love not to if I can avoid it but will if I have to. I tried using individual labels stuffed together but the spacing sucked and I'm using autolayout and that really seems to work better if the entire line is one UI element. ___ 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: Using a document bundle file type with core data
On Jan 17, 2013, at 5:42 AM, Mike Abdullah wrote: > > On 17 Jan 2013, at 03:38, David Brittain wrote: > >> The code in this blog article enables saving core data files to a package: >> >> http://cutecoder.org/featured/asynchronous-core-data-document/ >> >> Take a look at the writeSafelyToURL implementation in the gist at the >> bottom. I haven't tried saving to a bundle myself, but found the >> article helped me solve some problems with core data and documents. > > The code in that article is a bit buggy. I did a rewrite, based off our > internal code here: > > https://github.com/karelia/BSManagedDocument > > Read through the header for full details, and make sure you work with the > ksmanageddocument branch for now. There are a lot of tricky edge cases > involved in this. About 4 years of discovering them has gone into this! That is some great work. Thank you! ___ 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: Thread synchronization via queue
.. and if what you want is to use this to block a separate thread, you can do that too. Just make the read block grab some data for you and put it in a block variable ready for you to process, then call it with dispatch_sync. You'll block until there's data and when it returns the chunk is there for you to use. Work on it, then dispatch yourself another read block to get the next bit. On 17 Jan, 2013, at 7:02 PM, Roland King wrote: > There's quite a few things you can try in GCD. > > One of them (and this is designed in email so I'm sure this is going to get > holes poked all over it but might make for a fun discussion) is to make one > worker dispatch_queue on which all of your work happens, that protects your > NSMutableData from multiple access. That's a serial queue. You make two more > queues, a reader and a writer and you use dispatch_set_target_queue on each > of them to your 'real' queue which means they will send their work there. > > The code which wants to read tosses a read block with whatever fragment > handler you have onto the read queue, it finds data, processes as much as it > wants. it then tosses another similar read block onto the same queue to > process the next chunk. If however the read it just did depleted the data to > zero and there's no more, before it exists it suspends its own read queue > leaving the block it just queued waiting. > > The writer does something similar. When there's data to write it tosses a > write block onto the write queue. That appends data to the NSMutableData. > Also, if it sees that the data was empty before it appended, it resumes the > read queue before exiting the write block and the next reader block will > start. > > You start with the data empty and the read queue suspended with one read > block on it. As soon as the writer writes, the read queue unsuspends and you > start reading. > > That idea probably needs refining and it does depend exactly what you > currently have on the other side and whether it would work as callback > blocks. > > There's probably ways to do that with dispatch_semaphore too and probably if > you try hard with one of the dispatch_sources. > > > > On 17 Jan, 2013, at 5:40 PM, Rick Mann wrote: > >> I've got a situation where I have a complicated process that periodically >> pulls some bytes out of an NSMutableData. Eventually, it gets to the end of >> the NSMutableData. At that point, I need the process to block while it waits >> for a separate process (thread) to give it more data. What I need is a >> semaphored queue for a producer-consumer type of relationship. >> >> I don't think there's any way to pull this off using GCD, is there? I can't >> change the complex process to work in discrete chunks. It needs to chug >> through the data until it reaches a stopping point, and that might require >> several waits on more data. >> >> -- >> Rick >> >> >> >> >> ___ >> >> 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/rols%40rols.org >> >> This email sent to r...@rols.org > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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: Thread synchronization via queue
There's quite a few things you can try in GCD. One of them (and this is designed in email so I'm sure this is going to get holes poked all over it but might make for a fun discussion) is to make one worker dispatch_queue on which all of your work happens, that protects your NSMutableData from multiple access. That's a serial queue. You make two more queues, a reader and a writer and you use dispatch_set_target_queue on each of them to your 'real' queue which means they will send their work there. The code which wants to read tosses a read block with whatever fragment handler you have onto the read queue, it finds data, processes as much as it wants. it then tosses another similar read block onto the same queue to process the next chunk. If however the read it just did depleted the data to zero and there's no more, before it exists it suspends its own read queue leaving the block it just queued waiting. The writer does something similar. When there's data to write it tosses a write block onto the write queue. That appends data to the NSMutableData. Also, if it sees that the data was empty before it appended, it resumes the read queue before exiting the write block and the next reader block will start. You start with the data empty and the read queue suspended with one read block on it. As soon as the writer writes, the read queue unsuspends and you start reading. That idea probably needs refining and it does depend exactly what you currently have on the other side and whether it would work as callback blocks. There's probably ways to do that with dispatch_semaphore too and probably if you try hard with one of the dispatch_sources. On 17 Jan, 2013, at 5:40 PM, Rick Mann wrote: > I've got a situation where I have a complicated process that periodically > pulls some bytes out of an NSMutableData. Eventually, it gets to the end of > the NSMutableData. At that point, I need the process to block while it waits > for a separate process (thread) to give it more data. What I need is a > semaphored queue for a producer-consumer type of relationship. > > I don't think there's any way to pull this off using GCD, is there? I can't > change the complex process to work in discrete chunks. It needs to chug > through the data until it reaches a stopping point, and that might require > several waits on more data. > > -- > Rick > > > > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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: Using a document bundle file type with core data
On 17 Jan 2013, at 03:38, David Brittain wrote: > The code in this blog article enables saving core data files to a package: > > http://cutecoder.org/featured/asynchronous-core-data-document/ > > Take a look at the writeSafelyToURL implementation in the gist at the > bottom. I haven't tried saving to a bundle myself, but found the > article helped me solve some problems with core data and documents. The code in that article is a bit buggy. I did a rewrite, based off our internal code here: https://github.com/karelia/BSManagedDocument Read through the header for full details, and make sure you work with the ksmanageddocument branch for now. There are a lot of tricky edge cases involved in this. About 4 years of discovering them has gone into this! ___ 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: Thread synchronization via queue
On Jan 17, 2013, at 4:01 AM, Rick Mann wrote: > On Jan 17, 2013, at 1:56 , Charles Srstka wrote: > >> On Jan 17, 2013, at 3:40 AM, Rick Mann wrote: >> >>> I've got a situation where I have a complicated process that periodically >>> pulls some bytes out of an NSMutableData. Eventually, it gets to the end of >>> the NSMutableData. At that point, I need the process to block while it >>> waits for a separate process (thread) to give it more data. What I need is >>> a semaphored queue for a producer-consumer type of relationship. >>> >>> I don't think there's any way to pull this off using GCD, is there? I can't >>> change the complex process to work in discrete chunks. It needs to chug >>> through the data until it reaches a stopping point, and that might require >>> several waits on more data. >> >> Could NSInputStream and NSOutputStream possibly provide what you need? > > Hmm, good idea, but it looks like they don't provide blocking reads, which is > basically what I need. They're callback-based. You could start a run loop in a dispatch queue, schedule the NSInputStream on that runloop, and then have the delegate methods block/unblock your reading thread via a lock/semaphore/etc. 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: Thread synchronization via queue
On Jan 17, 2013, at 1:56 , Charles Srstka wrote: > On Jan 17, 2013, at 3:40 AM, Rick Mann wrote: > >> I've got a situation where I have a complicated process that periodically >> pulls some bytes out of an NSMutableData. Eventually, it gets to the end of >> the NSMutableData. At that point, I need the process to block while it waits >> for a separate process (thread) to give it more data. What I need is a >> semaphored queue for a producer-consumer type of relationship. >> >> I don't think there's any way to pull this off using GCD, is there? I can't >> change the complex process to work in discrete chunks. It needs to chug >> through the data until it reaches a stopping point, and that might require >> several waits on more data. > > Could NSInputStream and NSOutputStream possibly provide what you need? Hmm, good idea, but it looks like they don't provide blocking reads, which is basically what I need. They're callback-based. -- Rick ___ 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: Thread synchronization via queue
On Jan 17, 2013, at 3:40 AM, Rick Mann wrote: > I've got a situation where I have a complicated process that periodically > pulls some bytes out of an NSMutableData. Eventually, it gets to the end of > the NSMutableData. At that point, I need the process to block while it waits > for a separate process (thread) to give it more data. What I need is a > semaphored queue for a producer-consumer type of relationship. > > I don't think there's any way to pull this off using GCD, is there? I can't > change the complex process to work in discrete chunks. It needs to chug > through the data until it reaches a stopping point, and that might require > several waits on more data. Could NSInputStream and NSOutputStream possibly provide what you need? 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: Comparator blocks in NSSortDescriptor not supported in Core Data?
On Jan 17, 2013, at 01:06, Kyle Sluder wrote: > On Thu, Jan 17, 2013, at 12:31 AM, Laurent Daudelin wrote: >> Any reason why comparator blocks are not supported in NSSortDescriptor >> when used for an NSFetchRequest? I tried one unaware they were not >> supported and I got an exception: >> >> *** Terminating app due to uncaught exception >> 'NSInvalidArgumentException', reason: 'unsupported NSSortDescriptor >> (comparator blocks are not supported)' > > Guessing you're using a SQLite store? The SQLite store converts fetch > requests into SQL queries, and there's no way to express a block > comparator as a SQL query. > > See the section Fetch Predicates and Sort Descriptors of the Persistent > Store Features chapter of the Core Data Programming Guide: > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html > > --Kyle Sluder Thanks, Kyle. I thought it was something like that but my brain is in slow motion at this time after a long day... -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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
Thread synchronization via queue
I've got a situation where I have a complicated process that periodically pulls some bytes out of an NSMutableData. Eventually, it gets to the end of the NSMutableData. At that point, I need the process to block while it waits for a separate process (thread) to give it more data. What I need is a semaphored queue for a producer-consumer type of relationship. I don't think there's any way to pull this off using GCD, is there? I can't change the complex process to work in discrete chunks. It needs to chug through the data until it reaches a stopping point, and that might require several waits on more data. -- Rick ___ 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: Comparator blocks in NSSortDescriptor not supported in Core Data?
On Thu, Jan 17, 2013, at 12:31 AM, Laurent Daudelin wrote: > Any reason why comparator blocks are not supported in NSSortDescriptor > when used for an NSFetchRequest? I tried one unaware they were not > supported and I got an exception: > > *** Terminating app due to uncaught exception > 'NSInvalidArgumentException', reason: 'unsupported NSSortDescriptor > (comparator blocks are not supported)' Guessing you're using a SQLite store? The SQLite store converts fetch requests into SQL queries, and there's no way to express a block comparator as a SQL query. See the section Fetch Predicates and Sort Descriptors of the Persistent Store Features chapter of the Core Data Programming Guide: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html --Kyle Sluder ___ 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: Custom View drawRect method is not invoked when use with AutoLayout
I have rephrased my earlier question to get some experts attention :)
Is there any difference in creating a custom view in interface builder over
code.
If I create the custom view from interface builder, drawrect method is getting
invoked, if I do it from code,drawrect is not getting invoked?
Thanks
Sasikumar
Sent from my iPhone
On Jan 16, 2013, at 9:47 PM, Sasikumar JP wrote:
> Hi,
> I am working on a project, where i have to create horizontal tableview with
> custom tableview cell. i am using AutoLayout constraints to layout all cell's
> subview elements.
>
> Here is the my tableview cell init method, here i am using JPFilmBorderView
> to draw some custom drawing. but JPFilmBorderView drawRect method never gets
> invoked.
> - (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString
> *)reuseIdentifier
>
> {
>
> NSLog(@"initwithstyle invoked");
>
> self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];
>
> if (self) {
>
> JPFilmBorderView *topFilmBorderView = [[JPFilmBorderView alloc]
> initWithFrame:CGRectZero];
>
> topFilmBorderView.contentMode = UIViewContentModeRedraw;
>
> topFilmBorderView.backgroundColor = [UIColor whiteColor];
>
> topFilmBorderView.translatesAutoresizingMaskIntoConstraints = NO;
>
>
>
> JPFilmBorderView *bottomFilmBorderView = [[JPFilmBorderView alloc]
> initWithFrame:CGRectZero];
>
> bottomFilmBorderView.translatesAutoresizingMaskIntoConstraints = NO;
>
> bottomFilmBorderView.backgroundColor = [UIColor greenColor];
>
>
>
> self.thumbnailImage = [[UIImageView alloc] initWithFrame:CGRectZero];
>
> _thumbnailImage.translatesAutoresizingMaskIntoConstraints = NO;
>
>
>
> [self.contentView addSubview:topFilmBorderView];
>
> [self.contentView addSubview:_thumbnailImage];
>
> [self.contentView addSubview:bottomFilmBorderView];
>
>
>
> NSDictionary *viewDict =
> NSDictionaryOfVariableBindings(_thumbnailImage, topFilmBorderView,
> bottomFilmBorderView);
>
> [self.contentView addConstraints:[NSLayoutConstraint
> constraintsWithVisualFormat:@"V:|[topFilmBorderView(20)]-[_thumbnailImage]-[bottomFilmBorderView(20)]|"
> options:0 metrics:nil views:viewDict]];
>
> [self.contentView addConstraints:[NSLayoutConstraint
> constraintsWithVisualFormat:@"H:|[topFilmBorderView]" options:0 metrics:nil
> views:viewDict]];
>
> [self.contentView addConstraints:[NSLayoutConstraint
> constraintsWithVisualFormat:@"H:|[_thumbnailImage]" options:0 metrics:nil
> views:viewDict]];
>
> [self.contentView addConstraints:[NSLayoutConstraint
> constraintsWithVisualFormat:@"H:|[bottomFilmBorderView]" options:0
> metrics:nil views:viewDict]];
>
>
>
> }
>
> return self;
>
> }
>
> Here is the JPFilmBorderView implementation.i never see the NSLog output from
> drawRect method.
>
>
>
> @implementation JPFilmBorderView
>
> - (id)initWithFrame:(CGRect)frame
>
> {
>
> self = [super initWithFrame:frame];
>
> if (self) {
>
> // Initialization code
>
> }
>
> return self;
>
> }
>
> - (void)drawRect:(CGRect)rect
>
> {
>
> NSLog(@"Rect %@",[NSValue valueWithCGRect:rect]);
>
> }
>
> I am observing this problem only if i define the custom view from program,
> where as if i use storyboard/nib file, custom view drawRect method is getting
> invoked.
>
> i am not sure what i am missing here. any help is highly appreciated.
>
> Thank you
>
> Sasikumar JP
>
___
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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 3:30 AM, Andy Lee wrote: > One thing I didn't test was whether this was due to changeColor: being sent > or due to the color well responding to the notification, Actually this doesn't matter since notifications are sent synchronously. *But* I couldn't resist poking around some more, and found that NSColorWell (the thing that is FR at the time of my test) does not implement changeColor:. So I bet it is in fact responding to the color panel by handling NSColorPanelColorDidChangeNotification. Knowing this doesn't really help, I was just a bit surprised. Melvin, I know you're figuring on refactoring rather than kludging. If I figure out a hack that works, I'll announce it. --Andy ___ 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
Comparator blocks in NSSortDescriptor not supported in Core Data?
Any reason why comparator blocks are not supported in NSSortDescriptor when used for an NSFetchRequest? I tried one unaware they were not supported and I got an exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'unsupported NSSortDescriptor (comparator blocks are not supported)' -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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: Changing color in NSColorPanel without message
On Jan 17, 2013, at 2:23 AM, "jonat...@mugginsoft.com"
wrote:
> The refactor could be fairly simple.
> A category method on NSColorPanel could be used to insert a filter into the
> responder chain as and when required before displaying the panel.
> The filter could then divert the change request locally as required.
Would this work? I ruled it out because I figured that the "real" FR would have
to resignFirstResponder, which could cause problems if for example it was a
text field whose contents failed validation.
I tried a quick-and-dirty hack of the responder chain using a subclass of
NSApplication, plus a category method on NSColorPanel called mySetColor: which
you'd call instead of setColor:.
The idea was to have NSApp return nil for keyWindow and mainWindow if the
program was in the middle of executing mySetColor:. I assumed the color panel
was calling these methods to look for the first responder, so it would think
there *was* no first responder and the changeColor: message wouldn't get sent
(well, it might get sent to some non-visual object in the responder chain).
It didn't work. The "real" first responder (an NSColorWell) still changed
color. One thing I didn't test was whether this was due to changeColor: being
sent or due to the color well responding to the notification, which would be
surprising but I can't say I ruled it out.
Another possibility is that changeColor: isn't sent during setColor:, but
rather with maybe a delayed perform. Didn't bother to test.
Or maybe I guessed wrong about how it's determined what the FR is.
Here's a snippet that gives the idea of the kludge I was trying:
- (void)mySetColor:(NSColor *)color
{
NSLog(@"ENTER mySetColor:");
BOOL wasSettingColor = [(MyApplication *)NSApp colorPanelIsSettingColor];
[(MyApplication *)NSApp setColorPanelIsSettingColor:YES];
[self setColor:color];
[(MyApplication *)NSApp setColorPanelIsSettingColor:wasSettingColor];
NSLog(@"EXIT mySetColor:");
}
I was tempted to try to get this to work by getting a little messier. But I
didn't.
--Andy
___
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: Changing color in NSColorPanel without message
On 17 Jan 2013, at 00:58, Melvin Walker wrote: > On Jan 16, 2013, at 4:45 PM, Andy Lee wrote: >> On Jan 16, 2013, at 6:09 PM, Melvin Walker wrote: >> [...] When you select a color in the panel, NSColorPanel sends a changeColor: message to the first responder. It also sends its action message (set by setAction:) to its target object (set by setTarget:), provided that neither the action nor the target is nil. NSColorPanel also sends its action to its target whenever you select a color in the color panel. >>> >>> Yes, and this is the behavior I want to avoid. >>> >>> I can turn off the send-to-target behavior easily enough, but I can't turn >>> off the send-a-changeColor:-message behavior. >> >> It looks like Apple really, really doesn't want you to do this. Every sneaky >> kludge I've thought of is thwarted by limitations of the API. >> >> This makes sense to me. I like that the standard color panel is always >> synced with the color of the first responder for a consistent user >> experience at all times in all apps. >> >> So we come to the old question: what are you really trying to do? If it >> doesn't reveal too much about your project, what are the meanings of the >> colors in question, and what use case do you have that warrants deviating >> from the standard behavior? > > I agree — it looks like setting the color is a round trip. > > We are doing some custom word processing and we wanted to be able to reflect > the color of the text when the mouse is clicked in it. No NSTextView, so we > don't get the behavior for free. I was hoping to change the code only in a > small area, even if it meant something a bit kludgy, but it looks like a > refactor-rewrite is in my future. Thinking again. You could make NSColorPanel its own first responder when required. This might require subclassing to override NSColorPanel -changeColor:. Might be worth an experimental shot though. Regards Jonathan Mitchell Mugginsoft LLP ___ 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: Changing color in NSColorPanel without message
On 17 Jan 2013, at 00:58, Melvin Walker wrote: > On Jan 16, 2013, at 4:45 PM, Andy Lee wrote: >> On Jan 16, 2013, at 6:09 PM, Melvin Walker wrote: >> [...] When you select a color in the panel, NSColorPanel sends a changeColor: message to the first responder. It also sends its action message (set by setAction:) to its target object (set by setTarget:), provided that neither the action nor the target is nil. NSColorPanel also sends its action to its target whenever you select a color in the color panel. >>> >>> Yes, and this is the behavior I want to avoid. >>> >>> I can turn off the send-to-target behavior easily enough, but I can't turn >>> off the send-a-changeColor:-message behavior. >> >> It looks like Apple really, really doesn't want you to do this. Every sneaky >> kludge I've thought of is thwarted by limitations of the API. >> >> This makes sense to me. I like that the standard color panel is always >> synced with the color of the first responder for a consistent user >> experience at all times in all apps. >> >> So we come to the old question: what are you really trying to do? If it >> doesn't reveal too much about your project, what are the meanings of the >> colors in question, and what use case do you have that warrants deviating >> from the standard behavior? > > I agree — it looks like setting the color is a round trip. > > We are doing some custom word processing and we wanted to be able to reflect > the color of the text when the mouse is clicked in it. No NSTextView, so we > don't get the behavior for free. I was hoping to change the code only in a > small area, even if it meant something a bit kludgy, but it looks like a > refactor-rewrite is in my future. The refactor could be fairly simple. A category method on NSColorPanel could be used to insert a filter into the responder chain as and when required before displaying the panel. The filter could then divert the change request locally as required. Regards Jonathan Mitchell Mugginsoft LLP ___ 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
