Command Line Argument - Choosing a Style
Hi, I'm developing an application to support third-party extensions that filter text. Each filter consists mainly of a property list and an executable. The idea is that the text of the current document goes into the executable along with settings specified in the property list (as arguments); text to replace the document text comes out as the standard output. Right now I am stuck trying to decide how I should pass both the document text and the settings to the executable. I see three options: 1. Have the first argument be the document text, and the second an XML string containing the settings as key-value pairs. 2. Have the first argument be the docucument text, the second a setting key, the third a setting value, the fourth a setting key, etc... 3. Have the first argument be the docucument text, have each successive argument be a setting value, in an order specified in the property list so as to determine the key for each. I can easily set up the application to support any of these methods. My problem is that each one seems to have some inconveniences for the developer of the filter, and I would like to make this as convenient as possible for anyone who makes a filter. Could someone tell me which method would be the most appropriate? Thanks. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Command Line Argument - Choosing a Style
On Wed, Aug 6, 2008 at 9:00 PM, Jonathan deWerd <[EMAIL PROTECTED]>wrote: > I would make plugins of a different type: standard cocoa bundles (there are > a handful of tutorials on google). This way, people could install and > uninstall using the finder (a little known but helpful feature of the info > box), you could use standard cocoa APIs, you wouldn't have to deal with the > overhead of spawning a new process, and you could provide a template to get > devs started. Then I'd just pass configuration info in a dictionary. Okay. That looks like a much better solution (If only I had used it from the beginning). It definitely looks worthwhile to look into, as I'm a newbie at making plug-ins. Thank you. > If that isn't an option, I would pass a bunch of --key value pairs to > retain some semblance of standard-ness :) > > On Aug 6, 2008, at 4:33 PM, hac wrote: > > Hi, >> I'm developing an application to support third-party extensions that >> filter >> text. Each filter consists mainly of a property list and an executable. >> The >> idea is that the text of the current document goes into the executable >> along >> with settings specified in the property list (as arguments); text to >> replace >> the document text comes out as the standard output. >> >> Right now I am stuck trying to decide how I should pass both the document >> text and the settings to the executable. I see three options: >> >> 1. Have the first argument be the document text, and the second an XML >> string containing the settings as key-value pairs. >> 2. Have the first argument be the docucument text, the second a setting >> key, the third a setting value, the fourth a setting key, etc... >> 3. Have the first argument be the docucument text, have each successive >> argument be a setting value, in an order specified in the property list >> so >> as to determine the key for each. >> >> I can easily set up the application to support any of these methods. My >> problem is that each one seems to have some inconveniences for the >> developer >> of the filter, and I would like to make this as convenient as possible for >> anyone who makes a filter. Could someone tell me which method would be the >> most appropriate? >> >> Thanks. >> > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Table Column NSSegmentedCell - Segment not Selecting
I have a table column that contains multiple types of cells. One is an NSSegmentedCell. To do this, I have tried variations of the following code. I use it in the table's data source as well as to override the column's dataCellForRow method: NSSegmentedCell *theCell = [[[NSSegmentedCell alloc] init] autorelease]; [theCell setSegmentCount:count]; [theCell setSelectedSegment:foo]; return theCell; What happens is that [theCell selectedSegment] now returns foo, but it does not appear selected at all. This seems like a simple thing to do, but I can't seem to do it. Am I doing something totally wrong? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Table Column NSSegmentedCell - Segment not Selecting
I've solved my own problem, finally. I have set the data source to return an NSNumber containing the selected index rather than an actual cell. I still don't really understand why I do this for only some types of cells, but this solution works fine. On Sun, Aug 10, 2008 at 11:32 PM, hac <[EMAIL PROTECTED]> wrote: > I have a table column that contains multiple types of cells. One is an > NSSegmentedCell. To do this, I have tried variations of the following > code. I use it in the table's data source as well as to override the > column's dataCellForRow method: > > NSSegmentedCell *theCell = [[[NSSegmentedCell alloc] init] autorelease]; > [theCell setSegmentCount:count]; > [theCell setSelectedSegment:foo]; > return theCell; ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
