Re: Stupid block syntax!
Le 5 juil. 2012 à 20:23, Greg Parker gpar...@apple.com a écrit : Note that C++ allows overloading of almost everything, including binary ^, but it doesn't allow creation of new operators like unary ^. Thanks Greg for that precision. Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement an object whose properties are really dictionary entries.
Thanks again Keary. On 12 ביול 2012, at 02:54, Keary Suska wrote: On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote: Of what I read from everyone, and after examining the suggested code from Jens Alfke, I think I'm inclined to something simpler, hinted by Keary Suska. Could you spare a few more words on the undefinedKey override? I would create a base class that implements -valueForUndefinedKey: and -setValue:forUndefinedKey: (per the doc links that another poster provided). These methods would simply get/set from the dictionary. The only thing that requires a little consideration is how you may choose to validate the key (if at all)--i.e. determine whether you want to throw an exception for unknown keys. You can throw by simply calling super's implementation. To validate you could keep an array of valid key names (somewhat fragile, as you need to keep it updated), or use runtime inspection functions (see: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). More cryptic but not fragile. Thanks, I think this is exactly what I was looking for. In my case it is almost trivial. These classes maintain dictionaries to convert from the class' Keys (properties) to the base-model (CoreData) attribute names in the schema. I can simply look up the internal key, and throw (via super implementation of valueForUndefinedKey/setValue:forUndefinedKey) if I can't find it. If I'm going this route, do I still need to use the @dynamic for my properties? after all --- promised implementations wont be available in runtime. I rely on a KVO pre-exception mechanism. Obviously, I would use CoreData if I could. In fact, we use CoreData for the base model of our application. However, there is another layer higher than the CoreData model, that consists of intermediate data objects that serve as mediators between server messages and our real model objects in CoreData. The Keys or property-names are dictated by server definitions, and do not fully match those we have in our CoreData model. We don't want these objects to be stored, and we don't want them to be dependent on some managedObjectContext (for threading reasons). Just simple, old-style, model objects. I actually have a large project that uses pars of Core Data without an NSManagedObjectContext, as I have to use a specific RDBMS back-end. In fact, the context isn't needed unless you want storage and/or synchronization (relationship management, etc). I use a Managed Object Model to represent the data schema so I can have introspection, and subclass NSManagedObject. I also use the undefined-key technique for them, using the associated NSEntityDescription for key validation. I also have a system that allows properties to be added dynamically from SQL query results. Works like a charm. Can I come work with you? :) I like it. Sounds like a healthy little system... Do you use the graphic tool for defining the Managed Object Model, or do you do this programmatically? If I choose this way, I'd like still to be able to auto-generate the classes from the schema. Our cross-platform guys would not rest until they see a concrete source file declaring a C++ style class with their own eyes. Also, when you have a partial-use of CoreData (a NSManagedObject subclass that lives without a context) How do you instantiate it? via alloc init? CoreData API demands a context... + (id)insertNewObjectForEntityForName:(NSString *)entityName inManagedObjectContext:(NSManagedObjectContext *)context; I'd like to avoid dynamic auto-generation of methods at runtime. I can't see why this is needed --- ALL my getters and setters will look exactly the same. As was mentioned, you at least have to specify @dynamic, which really only promises the compiler that valid getter/setters will be available at runtime. This is alright with me. @dynamic we'll write :) The reason we insist on dot-notation for accessing these objects, is that the code which does this, is written in C++ or C style, using structs and dot notation. That code could compile with no change against C++ data objects (in Windows) or against my Propery-based data objects for Mac. This is all fine--just means that you have to create the classes and declare the properties to make the compiler happy. We do it anyway today There will be no change to the header files. I only wish to delete current implementation, in favor of compact, generic code in a super class. HTH, This HELPS indeed. Thanks. Motti Shneor - Ceterum censeo Microsoftinem delendam esse ___ 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
Re: How to implement an object whose properties are really dictionary entries.
On Jul 12, 2012, at 00:14 , Motti Shneor wrote: On 12 ביול 2012, at 02:54, Keary Suska wrote: On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote: Of what I read from everyone, and after examining the suggested code from Jens Alfke, I think I'm inclined to something simpler, hinted by Keary Suska. Could you spare a few more words on the undefinedKey override? I would create a base class that implements -valueForUndefinedKey: and -setValue:forUndefinedKey: (per the doc links that another poster provided). These methods would simply get/set from the dictionary. The only thing that requires a little consideration is how you may choose to validate the key (if at all)--i.e. determine whether you want to throw an exception for unknown keys. You can throw by simply calling super's implementation. To validate you could keep an array of valid key names (somewhat fragile, as you need to keep it updated), or use runtime inspection functions (see:https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). More cryptic but not fragile. Thanks, I think this is exactly what I was looking for. In my case it is almost trivial. These classes maintain dictionaries to convert from the class' Keys (properties) to the base-model (CoreData) attribute names in the schema. I can simply look up the internal key, and throw (via super implementation of valueForUndefinedKey/setValue:forUndefinedKey) if I can't find it. If I'm going this route, do I still need to use the @dynamic for my properties? after all --- promised implementations wont be available in runtime. I rely on a KVO pre-exception mechanism. Maybe I haven't been following this closely enough, but you and Keary seem to be talking at cross purposes. -- If you *do* want to call property accessors in clients of your class, then the KVC method such as 'valueForUndefinedKey:' are of no use to you, because the accessors don't go through KVC. (It's the other way round -- KVC will call the accessors if they exist.) In this case, I think you should take a look at 'forwardInvocation:', documented here: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html#//apple_ref/doc/uid/TP40008048-CH105-SW1 Note that you can't actually forward the invocation as is, since there's no implementation of the relevant methods anywhere, but notice the comment that A forwardInvocation: method can act as a distribution center for unrecognized messages, … . It can translate one message into another, …. In other words, you'll have to detect/validate the selector/parameter pattern in the invocation, then modify or recreate the invocation to refer to a pair of methods that do the actual work. None of this should be very hard, since there are only 2 selector patterns to detect. This technique would avoid mucking about with the runtime class information directly (which you seem reluctant to do). The only issues I see are: a. I think you'll need to override 'respondsToSelector:' as well as 'forwardInvocation:', so that KVC will think that your dynamic accessors exist. b. This all depends on knowing whether property names are valid, but you say that you know that without having to add any data structures to your class implementation. You'll just have to define the properties as '@dynamic' to keep the compiler from complaining. If you're not willing (or able, for some reason I haven't foreseen) to use an approach like this, I think Dave's suggestion of macros is your best solution, although it's a little bit ugly at the source code level. -- If you *don't* want to call property accessors in clients of your class, but use the class only for (e.g.) bindings or other things that use KVC, then 'valueForUndefinedKey:' etc. is the right way to go. ___ 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: iChat plugin sample code ?
I finally found a link to an old Lion DocSet which contains it. Le 12 juil. 2012 à 02:30, Jean-Daniel Dupas devli...@shadowlab.org a écrit : Hello, Does someone has a copy of the Apple IRCServicePlugIn sample code. It look like it has been removed from the ADC web site, and I need it. Thanks. -- Jean-Daniel ___ 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/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ 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: View-based NSTableView question
Hey guys, Thank you all for your useful answers, Chuck, Laurent and Quincey, you guys rock! Fixed the issue. Best – Toby On Jul 12, 2012, at 2:24 AM, Quincey Morris wrote: On Jul 11, 2012, at 15:06 , TJ wrote: The problem here is that I don't have any idea where and how to get and set the frame of the cell. As you can see during the creation of NSTableCellView I'm basically using an NSZeroRect because [cellView frame] is nil. I subclassed NSTableCellView and added a red color for the background in order to see if the NSZeroRect gets automatically updated to the current cell rect - it does work. But it just doesn't make sense to create a subview of NSTableCellView with a zero-frame... is there a method inside NSTableCellView I should subclass and position the NSTextField? Or is it common to get the frame inside -viewForTableColumn and adjusting the text field there? What's the way Apple had in mind concerning programmatically creating a view-based NSTableView? I couldn't find a lot of information on this, the demo video on developer.apple.com directly uses an NSTextField as the return cell-view but my view needs to be more complex than that. I am pretty sure I just missed something very important here. ;-) The cell view creation occurs earlier than the point where the cell view's geometry (including its frame) is configured for the row where it's going to be used. (Note that you're only creating the view if there isn't one to reuse, and the re-used one will have the wrong frame from wherever it was last used.) You never set the frame yourself. The table view does that. In a circumstance like this, you can create the view with any frame you want, because it will be re-sized and re-positioned later. The only real consideration is that, depending on the intended subviews, you may choose *not* to make the view very small, because autoresizing of subviews of a view that's too small to contain them may produce undesirable results. So, use an empty frame rect, or a 100 x 100 frame rect or a 1000 x 1000 frame rect or whatever is convenient for the purpose of initially creating the view. And my second question is - is it possible to create a cell view which is bigger than one row, thus it's overlaying other rows (I'm not customizing my table view to death, I have a good reason for cell views being positioned over several rows). I dunno, but I doubt that it works. The table view re-uses cell views that are scrolled out of the content view, and I suspect it bases this on the row height, not the row's cell view's frame rect. In addition, I'd imagine that overlapping rows might mess up row animations. Lastly, your view is going to be resized by the table view itself, so your attempt to re-size is might be frustrated anyway. P.S. Here's a documentation reference: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingView-TablesProgrammatically/PopulatingView-TablesProgrammatically.html#//apple_ref/doc/uid/1026i-CH14-SW5 which has sample code similar to yours. Note the comment that says, the height of the frame is not really relevant, the row-height will modify the height. ___ 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: View-based NSTableView question
On Jul 12, 2012, at 2:24 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jul 11, 2012, at 15:06 , TJ wrote: The problem here is that I don't have any idea where and how to get and set the frame of the cell. As you can see during the creation of NSTableCellView I'm basically using an NSZeroRect because [cellView frame] is nil. I subclassed NSTableCellView and added a red color for the background in order to see if the NSZeroRect gets automatically updated to the current cell rect - it does work. But it just doesn't make sense to create a subview of NSTableCellView with a zero-frame... is there a method inside NSTableCellView I should subclass and position the NSTextField? Or is it common to get the frame inside -viewForTableColumn and adjusting the text field there? What's the way Apple had in mind concerning programmatically creating a view-based NSTableView? I couldn't find a lot of information on this, the demo video on developer.apple.com directly uses an NSTextField as the return cell-view but my view needs to be more complex than that. I am pretty sure I just missed something very important here. ;-) The cell view creation occurs earlier than the point where the cell view's geometry (including its frame) is configured for the row where it's going to be used. (Note that you're only creating the view if there isn't one to reuse, and the re-used one will have the wrong frame from wherever it was last used.) You never set the frame yourself. The table view does that. In a circumstance like this, you can create the view with any frame you want, because it will be re-sized and re-positioned later. The only real consideration is that, depending on the intended subviews, you may choose *not* to make the view very small, because autoresizing of subviews of a view that's too small to contain them may produce undesirable results. So, use an empty frame rect, or a 100 x 100 frame rect or a 1000 x 1000 frame rect or whatever is convenient for the purpose of initially creating the view. Or, if you really need it, you can use the value from frameOfCellAtColumn:row: -- that is the value that the table is going to set on the returned cell view. The method is pretty fast, so it should be okay to call. However, it will be faster to just use a hardcoded value for initial layout (like 100x100, or column.width x rowHeight -- and if you want to get even more fancy, subtract half the intercellSpacing from each.) corbin And my second question is - is it possible to create a cell view which is bigger than one row, thus it's overlaying other rows (I'm not customizing my table view to death, I have a good reason for cell views being positioned over several rows). I dunno, but I doubt that it works. The table view re-uses cell views that are scrolled out of the content view, and I suspect it bases this on the row height, not the row's cell view's frame rect. In addition, I'd imagine that overlapping rows might mess up row animations. Lastly, your view is going to be resized by the table view itself, so your attempt to re-size is might be frustrated anyway. P.S. Here's a documentation reference: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingView-TablesProgrammatically/PopulatingView-TablesProgrammatically.html#//apple_ref/doc/uid/1026i-CH14-SW5 which has sample code similar to yours. Note the comment that says, the height of the frame is not really relevant, the row-height will modify the height. ___ 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/corbind%40apple.com This email sent to corb...@apple.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: Does codesigning or Dev ID ever avoid the quarantine dialog?
No. Only 2 ways: delivered through the app store. installer using authorization. Otherwise, simply codesigning with a known dev ID only allows you past one level of Gatekeeper.. Any executable download will always get the quarantine flag set. Notice the common thread, some form of authorization from an Admin account occurs at some point in each of the 3 broader scenarios. This is required to clear the quarantine flag if set. App store apps can be considered vetted already. HTH John On Jul 11, 2012, at 4:35 PM, Rick Mann wrote: I thought that code signing OS X apps (even before Dev ID and GateKeeper) allowed you to avoid the do you really want to launch this quarantined app dialog, at least after the first launch (i.e., when you ship an update). I had a conversation with an Apple person about this a long time ago, but I don't remember what he ended up telling me. Is this not the case? TIA, 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: How to implement an object whose properties are really dictionary entries.
Thanks Quincey. I seem to have missed that one. I already have dealt with forwardInvocation, in another class (some kind of NSNotificationCenter replacement which dispatches messages to registered objects, in prioritized and synchronized way). I think I can do it without much hassle. This covers things like [myObject firstName] in addition to myObject.firstName, and [myObject setFirstName] in addition to myObject.firstName = @xxx; I do not intend to forward the invocation at all, rather to parse it, and call my internal general-purpose setter/getter method. I completely forgot about respondsToSelecor: but here, again, it can be done --- only I hate to implement cocoa's naming convention myself (knowing I have a key like firstName, to respond to a @selector(setFirstName:). Isn't the machinery for that part of the runtime? Who implements those naming conventions? On 12 ביול 2012, at 10:59, Quincey Morris wrote: On Jul 12, 2012, at 00:14 , Motti Shneor wrote: On 12 ביול 2012, at 02:54, Keary Suska wrote: On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote: Of what I read from everyone, and after examining the suggested code from Jens Alfke, I think I'm inclined to something simpler, hinted by Keary Suska. Could you spare a few more words on the undefinedKey override? I would create a base class that implements -valueForUndefinedKey: and -setValue:forUndefinedKey: (per the doc links that another poster provided). These methods would simply get/set from the dictionary. The only thing that requires a little consideration is how you may choose to validate the key (if at all)--i.e. determine whether you want to throw an exception for unknown keys. You can throw by simply calling super's implementation. To validate you could keep an array of valid key names (somewhat fragile, as you need to keep it updated), or use runtime inspection functions (see:https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). More cryptic but not fragile. Thanks, I think this is exactly what I was looking for. In my case it is almost trivial. These classes maintain dictionaries to convert from the class' Keys (properties) to the base-model (CoreData) attribute names in the schema. I can simply look up the internal key, and throw (via super implementation of valueForUndefinedKey/setValue:forUndefinedKey) if I can't find it. If I'm going this route, do I still need to use the @dynamic for my properties? after all --- promised implementations wont be available in runtime. I rely on a KVO pre-exception mechanism. Maybe I haven't been following this closely enough, but you and Keary seem to be talking at cross purposes. -- If you *do* want to call property accessors in clients of your class, then the KVC method such as 'valueForUndefinedKey:' are of no use to you, because the accessors don't go through KVC. (It's the other way round -- KVC will call the accessors if they exist.) In this case, I think you should take a look at 'forwardInvocation:', documented here: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html#//apple_ref/doc/uid/TP40008048-CH105-SW1 Note that you can't actually forward the invocation as is, since there's no implementation of the relevant methods anywhere, but notice the comment that A forwardInvocation: method can act as a distribution center for unrecognized messages, … . It can translate one message into another, …. In other words, you'll have to detect/validate the selector/parameter pattern in the invocation, then modify or recreate the invocation to refer to a pair of methods that do the actual work. None of this should be very hard, since there are only 2 selector patterns to detect. This technique would avoid mucking about with the runtime class information directly (which you seem reluctant to do). The only issues I see are: a. I think you'll need to override 'respondsToSelector:' as well as 'forwardInvocation:', so that KVC will think that your dynamic accessors exist. b. This all depends on knowing whether property names are valid, but you say that you know that without having to add any data structures to your class implementation. You'll just have to define the properties as '@dynamic' to keep the compiler from complaining. If you're not willing (or able, for some reason I haven't foreseen) to use an approach like this, I think Dave's suggestion of macros is your best solution, although it's a little bit ugly at the source code level. -- If you *don't* want to call property accessors in clients of your class, but use the class only for (e.g.) bindings or other things that use KVC, then 'valueForUndefinedKey:' etc. is the right way to go. Motti Shneor e-mail:
Re: Calculating lineFragment for NSTextContainer
Hi,
sorry for the delay and thanks for the response, I moved house. Anyway, this
all worked fine and now the text while being edited is taking crossing paths
into consideration and writes around them the way I wanted to. But it discards
the layout whenever I end editing. I first thought this was due to a call of
removeLayoutManager, but also after I removed this line it keeps on ignoring
all layout efforts and just writes across all paths.
- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
sweepDirection:(NSLineSweepDirection)sweepDirection
movementDirection:(NSLineMovementDirection)movementDirection
remainingRect:(NSRect *)remainingRect
…is stopped being called after editing ended. Why? How can I freeze the layout
in the view for after editing ended?
Alex
Am 20.06.2012 um 01:41 schrieb Graham Cox:
On 19/06/2012, at 7:02 PM, Alexander Reichstadt wrote:
Hi,
for the
- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
sweepDirection:(NSLineSweepDirection)sweepDirection
movementDirection:(NSLineMovementDirection)movementDirection
remainingRect:(NSRect *)remainingRect {
call I'd like to calculate the proposedRect in case there are bezierPaths
limitations of custom shapes.
So I thought there'd be a way to not only clipRect to shade out a piece of a
path, but also a way to get that spare-piece from the NSBezierPath instance.
Is there?
No, not built-in anyway.
I wanted to split up the bounds rect of the path to circumvent with the text
into stripes of the height of proposedRect passed into the call, then
considering the offset from top, if any, then pick the stripe I need and see
what the minimum bounds would be if the bezierpath stripe was an own bezier
path on its own. Or is there another way?
I'm guessing you're trying to run text into an arbitrary path defined by a
bezier.
If that's the case, I think your understanding of what the text system wants
from you here is a bit off. Basically, it tells you where it proposes to lay
the text down, and you can modify that to constrain it to lay it down
differently. So, for the proposedRect, you need to work out where that
intersects the edges of your path and pull the sides of that rect in until
they lie within the path. THERE IS NO BUILT-IN WAY TO DO THIS! But it's not
that hard. For the points representing the corners of the rect, you can find
out whether they are inside or outside the path with [NSBezierPath
containsPoint:], then use a binary approximation to shrink the rect until it
is just inside the path. In remainingRect, you return the bit of the rect
you are NOT using, in the direction of the text sweep. The text system uses
that to understand what part of the text it can't use this time round and so
will take that into account for the next fragment. You'll be called again
with the remainder rect as the proposedRect, so if your path shape is such
that more text could fit on the same line but horizontally displaced, you
have an opportunity to calculate that as well. This system allows any path
shape to work, even paths that are disjoint, or that have holes.
If the object is to run text around the outside of a path, it's the same
idea, you just return the rects outside instead.
This method is called repeatedly until all the text is laid out - so you
don't usually precalculate a series of strips and figure out which one to
return - you just have to focus on the single strip being considered right
now. There is no method to intersect a rect with a bezier and return another
bezier (arbitrary bezier path set operations would be wonderful, but they
ain't happening, even after years of asking for it).
--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: iChat plugin sample code ?
And where might that be in case anyone else would find it useful? On Jul 12, 2012, at 4:33 AM, Jean-Daniel Dupas wrote: I finally found a link to an old Lion DocSet which contains it. Le 12 juil. 2012 à 02:30, Jean-Daniel Dupas devli...@shadowlab.org a écrit : Hello, Does someone has a copy of the Apple IRCServicePlugIn sample code. It look like it has been removed from the ADC web site, and I need it. Thanks. -- Jean-Daniel ___ 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: Calculating lineFragment for NSTextContainer
Oh, it dawns me that this is due to adding an NSTextView instance that is being
removed when editing ends. This was in a sample project. Never mind.
Am 12.07.2012 um 12:09 schrieb Alexander Reichstadt:
Hi,
sorry for the delay and thanks for the response, I moved house. Anyway, this
all worked fine and now the text while being edited is taking crossing paths
into consideration and writes around them the way I wanted to. But it
discards the layout whenever I end editing. I first thought this was due to a
call of removeLayoutManager, but also after I removed this line it keeps on
ignoring all layout efforts and just writes across all paths.
- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
sweepDirection:(NSLineSweepDirection)sweepDirection
movementDirection:(NSLineMovementDirection)movementDirection
remainingRect:(NSRect *)remainingRect
…is stopped being called after editing ended. Why? How can I freeze the
layout in the view for after editing ended?
Alex
Am 20.06.2012 um 01:41 schrieb Graham Cox:
On 19/06/2012, at 7:02 PM, Alexander Reichstadt wrote:
Hi,
for the
- (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
sweepDirection:(NSLineSweepDirection)sweepDirection
movementDirection:(NSLineMovementDirection)movementDirection
remainingRect:(NSRect *)remainingRect {
call I'd like to calculate the proposedRect in case there are bezierPaths
limitations of custom shapes.
So I thought there'd be a way to not only clipRect to shade out a piece of
a path, but also a way to get that spare-piece from the NSBezierPath
instance. Is there?
No, not built-in anyway.
I wanted to split up the bounds rect of the path to circumvent with the
text into stripes of the height of proposedRect passed into the call, then
considering the offset from top, if any, then pick the stripe I need and
see what the minimum bounds would be if the bezierpath stripe was an own
bezier path on its own. Or is there another way?
I'm guessing you're trying to run text into an arbitrary path defined by a
bezier.
If that's the case, I think your understanding of what the text system wants
from you here is a bit off. Basically, it tells you where it proposes to lay
the text down, and you can modify that to constrain it to lay it down
differently. So, for the proposedRect, you need to work out where that
intersects the edges of your path and pull the sides of that rect in until
they lie within the path. THERE IS NO BUILT-IN WAY TO DO THIS! But it's not
that hard. For the points representing the corners of the rect, you can find
out whether they are inside or outside the path with [NSBezierPath
containsPoint:], then use a binary approximation to shrink the rect until it
is just inside the path. In remainingRect, you return the bit of the
rect you are NOT using, in the direction of the text sweep. The text system
uses that to understand what part of the text it can't use this time round
and so will take that into account for the next fragment. You'll be called
again with the remainder rect as the proposedRect, so if your path shape is
such that more text could fit on the same line but horizontally displaced,
you have an opportunity to calculate that as well. This system allows any
path shape to work, even paths that are disjoint, or that have holes.
If the object is to run text around the outside of a path, it's the same
idea, you just return the rects outside instead.
This method is called repeatedly until all the text is laid out - so you
don't usually precalculate a series of strips and figure out which one to
return - you just have to focus on the single strip being considered right
now. There is no method to intersect a rect with a bezier and return another
bezier (arbitrary bezier path set operations would be wonderful, but they
ain't happening, even after years of asking for it).
--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/lxr%40mac.com
This email sent to l...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to implement an object whose properties are really dictionary entries.
On Jul 12, 2012, at 3:32 AM, Motti Shneor wrote: Thanks Quincey. I seem to have missed that one. Yes, Quincy is right. I was forgetting about the dot syntax issue as I haven't been using it much for my implementation. Note, however, that if you plan to use bindings with these objects you will have to also implement the kind of approach we discussed. I already have dealt with forwardInvocation, in another class (some kind of NSNotificationCenter replacement which dispatches messages to registered objects, in prioritized and synchronized way). I think I can do it without much hassle. This covers things like [myObject firstName] in addition to myObject.firstName, and [myObject setFirstName] in addition to myObject.firstName = @xxx; The bit I forgot is that dot syntax is really syntactic sugar--all the compiler does with it is compile the statement as if it was actually written using a method call. I.e., [myObject firstName] is exactly the same operation as myObject.firstName. I do not intend to forward the invocation at all, rather to parse it, and call my internal general-purpose setter/getter method. I completely forgot about respondsToSelecor: but here, again, it can be done --- only I hate to implement cocoa's naming convention myself (knowing I have a key like firstName, to respond to a @selector(setFirstName:). Isn't the machinery for that part of the runtime? Who implements those naming conventions? You can handle the invocation any way you want, including ignoring it entirely. You shouldn't need to override respondsToSelector: as Quincy pondered, if you also implement the undefined key approach. If you don't, then you might have to. The forwardInvocation implementation would be easy. In theory, all you need to distinguish is the setX vs X pattern, determine the actual key name (really just extracting and formatting when you get a setX method), change the selector of the invocation to the appropriate undefined key method, and invoke it. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business On 12 ביול 2012, at 10:59, Quincey Morris wrote: On Jul 12, 2012, at 00:14 , Motti Shneor wrote: On 12 ביול 2012, at 02:54, Keary Suska wrote: On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote: Of what I read from everyone, and after examining the suggested code from Jens Alfke, I think I'm inclined to something simpler, hinted by Keary Suska. Could you spare a few more words on the undefinedKey override? I would create a base class that implements -valueForUndefinedKey: and -setValue:forUndefinedKey: (per the doc links that another poster provided). These methods would simply get/set from the dictionary. The only thing that requires a little consideration is how you may choose to validate the key (if at all)--i.e. determine whether you want to throw an exception for unknown keys. You can throw by simply calling super's implementation. To validate you could keep an array of valid key names (somewhat fragile, as you need to keep it updated), or use runtime inspection functions (see:https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). More cryptic but not fragile. Thanks, I think this is exactly what I was looking for. In my case it is almost trivial. These classes maintain dictionaries to convert from the class' Keys (properties) to the base-model (CoreData) attribute names in the schema. I can simply look up the internal key, and throw (via super implementation of valueForUndefinedKey/setValue:forUndefinedKey) if I can't find it. If I'm going this route, do I still need to use the @dynamic for my properties? after all --- promised implementations wont be available in runtime. I rely on a KVO pre-exception mechanism. Maybe I haven't been following this closely enough, but you and Keary seem to be talking at cross purposes. -- If you *do* want to call property accessors in clients of your class, then the KVC method such as 'valueForUndefinedKey:' are of no use to you, because the accessors don't go through KVC. (It's the other way round -- KVC will call the accessors if they exist.) In this case, I think you should take a look at 'forwardInvocation:', documented here: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html#//apple_ref/doc/uid/TP40008048-CH105-SW1 Note that you can't actually forward the invocation as is, since there's no implementation of the relevant methods anywhere, but notice the comment that A forwardInvocation: method can act as a distribution center for unrecognized messages, … . It can translate one message into another, …. In other words, you'll have to detect/validate the selector/parameter pattern in the invocation, then modify or
Re: How to implement an object whose properties are really dictionary entries.
Sent from Jane On 2012-07-12, at 7:05 AM, Keary Suska cocoa-...@esoteritech.com wrote: The forwardInvocation implementation would be easy. It would also be slow. In theory, all you need to distinguish is the setX vs X pattern, determine the actual key name (really just extracting and formatting when you get a setX method), change the selector of the invocation to the appropriate undefined key method, and invoke it. If you're going to go to all that trouble to compute the key name, then you should go with dynamic method resolution instead. It'd only be a little bit more work at that point, would be much more flexible, and a lot faster. Dave ___ 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
Quit helper app when main app terminates
What is the best way to make a helper app quit when the associated main app quits (or crashes)? No harm will be done if it keeps running for a minute or so. Thanks, Jerry Krinock ___ 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: Quit helper app when main app terminates
The best way? I have no idea… This is what I do, and it works.
I store the path to my helper app in 'path', and do the following when my app
is about to quit:
//-
- (void)applicationWillTerminate:(NSNotification *)aNotification
//-
{
[super applicationWillTerminate:aNotification];
AppleEvent tAppleEvent, tReply;
AEBuildError tAEBuildError;
ProcessSerialNumber currentProcessPSN;
NSNumber *psnHi = nil;
NSNumber *psnLo = nil;
NSArray * runningApps = [[NSWorkspace sharedWorkspace]
launchedApplications];
for(NSDictionary * appInfo in runningApps){
if( [path isEqualToString:[appInfo
objectForKey:@NSApplicationPath]] ){
psnHi = [appInfo
objectForKey:@NSApplicationProcessSerialNumberHigh];
psnLo = [appInfo
objectForKey:@NSApplicationProcessSerialNumberLow];
break;
}
}
if(psnHi == nil) return;
currentProcessPSN.highLongOfPSN = [psnHi unsignedIntegerValue];
currentProcessPSN.lowLongOfPSN = [psnLo unsignedIntegerValue];
OSStatus result = AEBuildAppleEvent( kCoreEventClass,
kAEQuitApplication, typeProcessSerialNumber, currentProcessPSN,
sizeof(ProcessSerialNumber), kAutoGenerateReturnID, kAnyTransactionID,
tAppleEvent, tAEBuildError,);
result = AESend( tAppleEvent, tReply, kAEAlwaysInteract+kAENoReply,
kAENormalPriority, kNoTimeOut, nil, nil );
}
--Rob
On Jul 12, 2012, at 12:33 PM, Jerry Krinock je...@ieee.org wrote:
What is the best way to make a helper app quit when the associated main app
quits (or crashes)? No harm will be done if it keeps running for a minute or
so.
Thanks,
Jerry Krinock
___
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: Quit helper app when main app terminates
One thing I've done in the past is get the PID of the main app before launching
the helper, and pass it as a command line argument to the helper (or something
similar) when it's launched. The helper app then periodically polls for the
existence of that PID, and when it discovers it's no longer there, quits.
This is nice because it's resilient against crashes as well as normal
termination. Of course (assuming you have some communication pipe between your
helper and your main app), when your main app quits normally you should attempt
to inform your helper that it should quit. This is a good strategy to implement
in addition to that so that it can clean itself up after a crash.
-Matt
Sent from my iPhone
On Jul 12, 2012, at 10:27 AM, Robert Martin robmar...@frontiernet.net wrote:
The best way? I have no idea… This is what I do, and it works.
I store the path to my helper app in 'path', and do the following when my app
is about to quit:
//-
- (void)applicationWillTerminate:(NSNotification *)aNotification
//-
{
[super applicationWillTerminate:aNotification];
AppleEvent tAppleEvent, tReply;
AEBuildError tAEBuildError;
ProcessSerialNumber currentProcessPSN;
NSNumber *psnHi = nil;
NSNumber *psnLo = nil;
NSArray * runningApps = [[NSWorkspace sharedWorkspace]
launchedApplications];
for(NSDictionary * appInfo in runningApps){
if( [path isEqualToString:[appInfo objectForKey:@NSApplicationPath]]
){
psnHi = [appInfo
objectForKey:@NSApplicationProcessSerialNumberHigh];
psnLo = [appInfo
objectForKey:@NSApplicationProcessSerialNumberLow];
break;
}
}
if(psnHi == nil) return;
currentProcessPSN.highLongOfPSN = [psnHi unsignedIntegerValue];
currentProcessPSN.lowLongOfPSN = [psnLo unsignedIntegerValue];
OSStatus result = AEBuildAppleEvent( kCoreEventClass, kAEQuitApplication,
typeProcessSerialNumber, currentProcessPSN,
sizeof(ProcessSerialNumber),
kAutoGenerateReturnID, kAnyTransactionID, tAppleEvent, tAEBuildError,);
result = AESend( tAppleEvent, tReply, kAEAlwaysInteract+kAENoReply,
kAENormalPriority, kNoTimeOut, nil, nil );
}
--Rob
On Jul 12, 2012, at 12:33 PM, Jerry Krinock je...@ieee.org wrote:
What is the best way to make a helper app quit when the associated main app
quits (or crashes)? No harm will be done if it keeps running for a minute
or so.
Thanks,
Jerry Krinock
___
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/matt%40mattpatenaude.com
This email sent to m...@mattpatenaude.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: Quit helper app when main app terminates
If you're on 10.6 or later:
- (void)applicationWillTerminate:(NSNotification *)aNotification
{
NSRunningApplication* helperApp = [NSRunningApplication
runningApplicationsWithBundleIdentifier:@bundle.id];
[helperApp terminate];
}
Sadly, you can't send a terminate command if you're helper app is
sandboxed, so if you have to sandbox -- you'd likely need to reverse
the process.
Your helper app gets the NSRunningApplication object of your main app,
then observes the terminated property of it.
When you are notified of it terminating, you terminate yourself.
Another alternative, use the SMLoginItemsSetEnabled to launch and
terminate your helper app.
Don't think that was what the API was intended actually for, but when
you're stuck in a sandbox, you gotta make due with cheap plastic
shovel that you find in it.
On Thu, Jul 12, 2012 at 10:27 AM, Robert Martin
robmar...@frontiernet.net wrote:
The best way? I have no idea… This is what I do, and it works.
I store the path to my helper app in 'path', and do the following when my app
is about to quit:
//-
- (void)applicationWillTerminate:(NSNotification *)aNotification
//-
{
[super applicationWillTerminate:aNotification];
AppleEvent tAppleEvent, tReply;
AEBuildError tAEBuildError;
ProcessSerialNumber currentProcessPSN;
NSNumber *psnHi = nil;
NSNumber *psnLo = nil;
NSArray * runningApps = [[NSWorkspace sharedWorkspace]
launchedApplications];
for(NSDictionary * appInfo in runningApps){
if( [path isEqualToString:[appInfo
objectForKey:@NSApplicationPath]] ){
psnHi = [appInfo
objectForKey:@NSApplicationProcessSerialNumberHigh];
psnLo = [appInfo
objectForKey:@NSApplicationProcessSerialNumberLow];
break;
}
}
if(psnHi == nil) return;
currentProcessPSN.highLongOfPSN = [psnHi unsignedIntegerValue];
currentProcessPSN.lowLongOfPSN = [psnLo unsignedIntegerValue];
OSStatus result = AEBuildAppleEvent( kCoreEventClass,
kAEQuitApplication, typeProcessSerialNumber, currentProcessPSN,
sizeof(ProcessSerialNumber), kAutoGenerateReturnID, kAnyTransactionID,
tAppleEvent, tAEBuildError,);
result = AESend( tAppleEvent, tReply, kAEAlwaysInteract+kAENoReply,
kAENormalPriority, kNoTimeOut, nil, nil );
}
--Rob
On Jul 12, 2012, at 12:33 PM, Jerry Krinock je...@ieee.org wrote:
What is the best way to make a helper app quit when the associated main app
quits (or crashes)? No harm will be done if it keeps running for a minute
or so.
Thanks,
Jerry Krinock
___
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/unmarked%40gmail.com
This email sent to unmar...@gmail.com
--
Mark Munz
unmarked software
http://www.unmarked.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: Quit helper app when main app terminates
On Jul 12, 2012, at 12:33 PM, Jerry Krinock wrote:
What is the best way to make a helper app quit when the associated main app
quits (or crashes)? No harm will be done if it keeps running for a minute or
so.
I create a pthread with this code
pid_t ppid = getppid ();// get parent pid
if (ppid 1) {
int kq = kqueue ();
if (kq != -1) {
struct kevent procEvent;// wait for parent to
exit
EV_SET (procEvent, // kevent
ppid, // ident
EVFILT_PROC,// filter
EV_ADD, // flags
NOTE_EXIT, // fflags
0, // data
0); // udata
kevent (kq, procEvent, 1, procEvent, 1, 0);
}
}
exit (0);
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Quit helper app when main app terminates
On Thu, 12 Jul 2012 10:54:13 -0700, Mark Munz said:
If you're on 10.6 or later:
- (void)applicationWillTerminate:(NSNotification *)aNotification
{
NSRunningApplication* helperApp = [NSRunningApplication
runningApplicationsWithBundleIdentifier:@bundle.id];
[helperApp terminate];
}
Although rare, it is possible to have more than one app with the same bundle id
running at the same time.
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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: Quit helper app when main app terminates
On Thu, Jul 12, 2012 at 9:33 AM, Jerry Krinock je...@ieee.org wrote:
What is the best way to make a helper app quit when the associated main app
quits (or crashes)? No harm will be done if it keeps running for a minute or
so.
A solution that does not involve killing the helper application from
the main application:
Observe the end of the main application from the helper application.
[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver:self
selector:@selector(apocalypseNow:)
name:NSWorkspaceDidTerminateApplicationNotification];
[...]
- (void) apocalypseNow:(NSNotification *) inNotification
{
NSRunningApplication * tRunningApplication=[[inNotification
userInfo] objectForKey:NSWorkspaceApplicationKey];
if ([[tRunningApplication bundleIdentifier]
isEqualToString:@the.bundle.identifier.of.the.main.application]==YES)
[NSApp terminate:self];
}
___
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: Quit helper app when main app terminates
Although rare, it is possible to have more than one app with the same bundle
id running at the same time.
Sorry - I wrote that code in email and mixed up the ProcessIdentifier
return type with the BundleIdentifier return type in my head.
Correct code for bundle ID should look like this:
NSArray* helperAppList = [NSRunningApplication
runningApplicationsWithBundleIdentifier:@bundle.id];
for (NSRunningApplication* app in helperAppList)
{
[app terminate];
}
This will terminate all the helpers that share the same bundle ID.
You can also use process id variation to get a specific helper.
+ (NSRunningApplication *)runningApplicationWithProcessIdentifier:(pid_t)pid
The real sticking issue -- is the sandbox. If you stuck in the
sandbox, you can't terminate helper apps.
On Thu, Jul 12, 2012 at 12:50 PM, Sean McBride s...@rogue-research.com wrote:
On Thu, 12 Jul 2012 10:54:13 -0700, Mark Munz said:
If you're on 10.6 or later:
- (void)applicationWillTerminate:(NSNotification *)aNotification
{
NSRunningApplication* helperApp = [NSRunningApplication
runningApplicationsWithBundleIdentifier:@bundle.id];
[helperApp terminate];
}
Although rare, it is possible to have more than one app with the same bundle
id running at the same time.
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
--
Mark Munz
unmarked software
http://www.unmarked.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: Quit helper app when main app terminates
Thanks for all the ideas.
I thought maybe someone would suggest opening up some snazzy inter application
communication channel and making the helper exit when it broke (indicating that
the main app had terminated). But since that was not offered, I used a
combination of the suggestions and some code I had lying around. It's all done
in the helper…
(1) Register for NSWorkspaceDidTerminateApplicationNotification
(2) In case the main app terminates before that notification gets going, during
launch, check that the main app is still running.
This might even work in a sandboxed helper, although, Yay! I'm not sandboxed in
this particular case.
On 2012 Jul 12, at 12:50, Sean McBride wrote:
Although rare, it is possible to have more than one app with the same bundle
id running at the same time.
Yes, in case someone launches two instances of my app and quits one, I'd have
two helpers running. But I think that's OK because all the helper does is
listen for and forward myapp:// url events, and the system will only send such
url event to one of them.
Jerry
The following code assumes that the MyApp-Helper.app is actually a .app with a
run loop, etc., and it is packaged in the main app in Contents/Something/
@implementation MyHelperAppDelegate
/* Other methods go here */
- (NSString*)mainAppBundleIdentifier {
NSString* bundlePath = [[NSBundle mainBundle] bundlePath] ;
// bundlePath = /Applications/MyApp.app/Contents/Helpers/MyApp-Helper.app
bundlePath = [bundlePath stringByDeletingLastPathComponent] ;
// bundlePath = /Applications/MyApp.app/Contents/Helpers/
bundlePath = [bundlePath stringByDeletingLastPathComponent] ;
// bundlePath = /Applications/MyApp.app/Contents/
bundlePath = [bundlePath stringByDeletingLastPathComponent] ;
// bundlePath = /Applications/MyApp.app/
NSBundle* bundle = [NSBundle bundleWithPath:bundlePath] ;
return [bundle bundleIdentifier] ;
}
- (void)handleAppQuit:(NSNotification*)appTerminateNotification {
NSString* osx_10_5_quitAppBundleIdentifier = [[appTerminateNotification
userInfo] objectForKey:@NSApplicationBundleIdentifier] ;
NSString* osx_10_6_quitAppBundleIdentifier = [[[appTerminateNotification
userInfo] objectForKey:NSWorkspaceApplicationKey] bundleIdentifier] ;
NSString *mainAppBundleIdentifier = [self mainAppBundleIdentifier] ;
if (
[osx_10_6_quitAppBundleIdentifier
isEqualToString:mainAppBundleIdentifier]
||
[osx_10_5_quitAppBundleIdentifier
isEqualToString:mainAppBundleIdentifier]
) {
[NSApp terminate:self] ;
}
}
- (pid_t)pidOfThisUsersAppWithBundleIdentifier:(NSString*)bundleIdentifier {
pid_t pid = 0 ; // not found
if (bundleIdentifier) {
#if MAC_OS_X_VERSION_MAX_ALLOWED = 1060
// Running the main run loop is necessary for -runningApplications to
// update. The next line is actually necessary in tools which may be
lacking
// a running run loop, and it actually works.
[[NSRunLoop mainRunLoop] runUntilDate:[NSDate
dateWithTimeIntervalSinceNow:0.01]] ;
NSArray* runningApps = [[NSWorkspace sharedWorkspace]
runningApplications] ;
for (NSRunningApplication* runningApp in runningApps) {
if ([[runningApp bundleIdentifier]
isEqualToString:bundleIdentifier]) {
pid = [runningApp processIdentifier] ;
break ;
}
}
#else
NSArray* appDicts = [[NSWorkspace sharedWorkspace]
launchedApplications] ;
// Note that the above method returns only applications launched by the
// current user, not other users. (Not documented, determined by
experiment
// in Mac OS 10.5.5). Also it returns only applications, defined as
// things which can appear in the Dock that are not documents and are
launched
// by the Finder or Dock
// (See documentation of ProcessSerialNumber).
for (NSDictionary* appDict in [appDicts objectEnumerator]) {
if ([[appDict objectForKey:@NSApplicationBundleIdentifier]
isEqualToString:bundleIdentifier]) {
pid = [[appDict objectForKey:@NSApplicationProcessIdentifier]
unsignedLongValue] ;
break ;
}
}
#endif
}
return pid ;
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Begin watching for main app to quit
NSNotificationCenter* notificationCenter = [[NSWorkspace sharedWorkspace]
notificationCenter] ;
[notificationCenter addObserver:self
selector:@selector(handleAppQuit:)
name:NSWorkspaceDidTerminateApplicationNotification
object:nil] ;
// Tested in Mac OS X 10.7: That notification is received whether the
application
// quits normally, crashes, or is terminated by a unix signal.
// Make sure main app did not
Re: How to implement an object whose properties are really dictionary entries.
On Jul 12, 2012, at 2:32 AM, Motti Shneor su...@bezeqint.net wrote: I already have dealt with forwardInvocation, in another class (some kind of NSNotificationCenter replacement which dispatches messages to registered objects, in prioritized and synchronized way). I think I can do it without much hassle. -forwardInvocation: is REALLY slow. It has to try every other way to find the method, then look up the method signature, extract the parameters from the stack frame, create an NSInvocation object, copy all the parameters into it, then call -forwardInvocation:. By comparison, creating the methods at runtime is comparably slow on the first call, then much faster after that. It's still going to be slower than a regular method call because the implementation has to figure out which method you were calling and map that to a property name, but it's not as bad. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement an object whose properties are really dictionary entries.
On Thu, Jul 12, 2012, at 02:40 PM, Jens Alfke wrote: By comparison, creating the methods at runtime is comparably slow on the first call, then much faster after that. It's still going to be slower than a regular method call because the implementation has to figure out which method you were calling and map that to a property name, but it's not as bad. Not necessarily. Now that we have blocks-as-IMPs, you could choose to create a separate IMP for each property you're dynamically adding, rather than disassembling the selector from within the IMP. Classic time/memory tradeoff. --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: Quit helper app when main app terminates
On Jul 12, 2012, at 9:33 AM, Jerry Krinock je...@ieee.org wrote: What is the best way to make a helper app quit when the associated main app quits (or crashes)? No harm will be done if it keeps running for a minute or so. Take a look at http://stackoverflow.com/questions/284325/how-to-make-child-process-die-after-parent-exits —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement an object whose properties are really dictionary entries.
On Jul 12, 2012, at 2:44 PM, Kyle Sluder k...@ksluder.com wrote: Not necessarily. Now that we have blocks-as-IMPs *scratching-record sound* We do?! How do I get in on that goodness? —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement an object whose properties are really dictionary entries.
On Thu, Jul 12, 2012, at 02:49 PM, Jens Alfke wrote: On Jul 12, 2012, at 2:44 PM, Kyle Sluder k...@ksluder.com wrote: Not necessarily. Now that we have blocks-as-IMPs *scratching-record sound* We do?! How do I get in on that goodness? Use imp_implementationWithBlock (available as of OS X 10.7 and iOS 4.3): http://opensource.apple.com/source/objc4/objc4-493.11/runtime/runtime.h More info here: http://www.friday.com/bbum/2011/03/17/ios-4-3-imp_implementationwithblock/ --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: Write Finder plugin
Hi Eric, Thanks. I am trying to do it using Services but I couldn't find any sample code. Can I do it in python? Regards, Rakesh Singhal On Tue, Jul 3, 2012 at 12:09 AM, Eric Schlegel eri...@apple.com wrote: On Jul 2, 2012, at 9:53 AM, Rakesh Singhal rakesh.sing...@gmail.com wrote: There are applications (eg. dropbox) which are able to create items in finder's contextual menu, not service. There should be some way to do it. There is no supported way to do this. Dropbox uses various hacks to make its way into the Finder process. Frequently, the current version of Dropbox is incompatible with a new release of Mac OS X and has to be disabled. Don't use them as a model. -eric ___ 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
