Re: Application Architecture or approach
On Wed, Feb 11, 2009 at 8:07 PM, Louis Demers louisdem...@mac.com wrote: Now, I need to rewrite the app so that it can talk to multiple devices. I want to use bindings and write as little code as possible 8-) I'm considering an NSDocument based Applications and using panels/palettes to display status and controls (100's) Each device will be represented by a different document. If the concept is to control lots of devices at a time, then I would hesitate to use the NSDocument architecture. Instead, I'd use a plugin architecture, where each device's code and interface is stored in a separate bundle inside your bundle's PlugIns folder. You can then enumerate these for choosing to display certain interfaces. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 11-Feb-09, at 20:20 , Kyle Sluder wrote: On Wed, Feb 11, 2009 at 8:07 PM, Louis Demers louisdem...@mac.com wrote: Now, I need to rewrite the app so that it can talk to multiple devices. I want to use bindings and write as little code as possible 8-) I'm considering an NSDocument based Applications and using panels/ palettes to display status and controls (100's) Each device will be represented by a different document. If the concept is to control lots of devices at a time, then I would hesitate to use the NSDocument architecture. Instead, I'd use a plugin architecture, where each device's code and interface is stored in a separate bundle inside your bundle's PlugIns folder. You can then enumerate these for choosing to display certain interfaces. I Had not thought about plugins because all the devices are identical in capabilities. The devices are complex cameras. I wanted to have each cameras have it document window to display the specific video feed, but a single palette to control the brightness/zoom of the frontmost window/camera. This is an over simplification because in reality, each camera has lots of controls and status. If each camera/ device has its own exclusive gui element, the screen will be cluttered beyond acceptable. I was modeling my solution around something like Photoshop or Illustrator where multiple documents use the same set of palettes. Louis Demers eng. www.obzerv.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
Nothing about this requires you to use the NSDocument architecture. You would implement the palettes the same way as you would for a document-based app. I'm just wondering if it is appropriate for what you're trying to do. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 12 Feb 2009, at 12:27 pm, Louis Demers wrote: I Had not thought about plugins because all the devices are identical in capabilities. The devices are complex cameras. I wanted to have each cameras have it document window to display the specific video feed, but a single palette to control the brightness/zoom of the frontmost window/camera. This is an over simplification because in reality, each camera has lots of controls and status. If each camera/device has its own exclusive gui element, the screen will be cluttered beyond acceptable. I was modeling my solution around something like Photoshop or Illustrator where multiple documents use the same set of palettes. What you're saying is that you have many cameras, but want to control one at a time. You are using the active window (or document) as a selection mechanism to choose which camera to control. Seems to me that if you want one camera per window, you'd want the controls for that camera in that window, though I see what you're saying about having too many controls. Maybe it's the selection mechanism that needs more thought? You could have a single window with a list of cameras and you select one to control. Then it becomes more like a master-detail interface which would be probably more manageable. If you do want to stick to one window per camera and have the controls apply to the from window, you can use notifications to listen for window activate/deactivate notifications and track down the related camera via the window's controller, which would be a class you developed. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 11-Feb-09, at 21:16 , Kyle Sluder wrote: Nothing about this requires you to use the NSDocument architecture. You would implement the palettes the same way as you would for a document-based app. and fundamentally, that is the part I do not know how and asked in a clumsy way 8-( I'm just wondering if it is appropriate for what you're trying to do. indeed, I'm not bent on using a document based app, I just tought it mit offer the mechanism or support to help rederriect my palettes' bindings to the proper object. Louis Demers eng. www.obzerv.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 11-Feb-09, at 21:30 , Graham Cox wrote: On 12 Feb 2009, at 12:27 pm, Louis Demers wrote: I Had not thought about plugins because all the devices are identical in capabilities. The devices are complex cameras. I wanted to have each cameras have it document window to display the specific video feed, but a single palette to control the brightness/ zoom of the frontmost window/camera. This is an over simplification because in reality, each camera has lots of controls and status. If each camera/device has its own exclusive gui element, the screen will be cluttered beyond acceptable. I was modeling my solution around something like Photoshop or Illustrator where multiple documents use the same set of palettes. What you're saying is that you have many cameras, but want to control one at a time. You are using the active window (or document) as a selection mechanism to choose which camera to control. Seems to me that if you want one camera per window, you'd want the controls for that camera in that window, though I see what you're saying about having too many controls. Maybe it's the selection mechanism that needs more thought? You could have a single window with a list of cameras and you select one to control. I considered that and I'm still interested in that solution. Then it becomes more like a master-detail interface which would be probably more manageable. If you do want to stick to one window per camera and have the controls apply to the from window, you can use notifications to listen for window activate/deactivate notifications and track down the related camera via the window's controller, which would be a class you developed. I do not care about sticking with that paradigm of one window per camera, but I'm conformable with that approach. But how to I get all the sliders and gui elements of my palettes to now bind to the object/ camera that is selected. In my current app, in the bindings inspector of the gui element, I select my instantiated object in the bind to popup and enters the model key path to the key of my object I want to control/display. That works because the instantiated object in unique and in my MainMenu.xib. But in the above scenarios, how do I configure my binding ? the key is the same all over, but the bound object will be swapped by whatever selection process I end up using. Or do I have hit a limit of the binding mechanism. I doubt it, more likely a limit of my own understanding of bindings 8-) --Graham Louis Demers eng. www.obzerv.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 12 Feb 2009, at 3:04 pm, Louis Demers wrote: I do not care about sticking with that paradigm of one window per camera, but I'm conformable with that approach. But how to I get all the sliders and gui elements of my palettes to now bind to the object/camera that is selected. In my current app, in the bindings inspector of the gui element, I select my instantiated object in the bind to popup and enters the model key path to the key of my object I want to control/display. That works because the instantiated object in unique and in my MainMenu.xib. But in the above scenarios, how do I configure my binding ? the key is the same all over, but the bound object will be swapped by whatever selection process I end up using. Or do I have hit a limit of the binding mechanism. I doubt it, more likely a limit of my own understanding of bindings 8-) OK, I understand your question. I'm not in a good position to answer it definitively as I haven't used bindings myself - I still tend to do things using KVO directly since my current project predates bindings. However, in general, I think what you need to is to have a single controller object that you bind your controls to, and swap the connection to the data model object that represents the selected camera. Then when the camera is switched you are changing just that one object reference, not all the individual bindings. I believe that generic controllers such as NSArrayController will handle that pretty much for you - you just bind to 'selection.whatever' (bondage experts please correct any misinformation here). That could also permit you to have a multiple selection of cameras and control several simultaneously if that makes sense for you. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On 11-Feb-09, at 23:11 , Graham Cox wrote: On 12 Feb 2009, at 3:04 pm, Louis Demers wrote: I do not care about sticking with that paradigm of one window per camera, but I'm conformable with that approach. But how to I get all the sliders and gui elements of my palettes to now bind to the object/camera that is selected. In my current app, in the bindings inspector of the gui element, I select my instantiated object in the bind to popup and enters the model key path to the key of my object I want to control/display. That works because the instantiated object in unique and in my MainMenu.xib. But in the above scenarios, how do I configure my binding ? the key is the same all over, but the bound object will be swapped by whatever selection process I end up using. Or do I have hit a limit of the binding mechanism. I doubt it, more likely a limit of my own understanding of bindings 8-) OK, I understand your question. I'm not in a good position to answer it definitively as I haven't used bindings myself - I still tend to do things using KVO directly since my current project predates bindings. However, in general, I think what you need to is to have a single controller object that you bind your controls to, and swap the connection to the data model object that represents the selected camera. Then when the camera is switched you are changing just that one object reference, not all the individual bindings. I believe that generic controllers such as NSArrayController will handle that pretty much for you - you just bind to 'selection.whatever' (bondage experts please correct any misinformation here). So the controller manages to reconnect the bindings to the selected objects. ! That would make sense. All that's left if to figure out the implementation details and coerce IB to do what I want. I'll try building a small test app. That could also permit you to have a multiple selection of cameras and control several simultaneously if that makes sense for you. that would definitively be a plus. The app is designed for calibrating and measuring performance of our cameras. Sending the same settings to multiple cameras would be an interesting capability during quality control. Thanks for the cue, I'll keep investigating. Louis Demers eng. www.obzerv.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Application Architecture or approach
On Wed, Feb 11, 2009 at 11:29 PM, Louis Demers louisdem...@mac.com wrote: So the controller manages to reconnect the bindings to the selected objects. ! That would make sense. All that's left if to figure out the implementation details and coerce IB to do what I want. I'll try building a small test app. Remember that you can bind to a key *path*, not just to a key. And that a change to any element along the path will update the binding. With that in mind, I would do this by putting an NSObjectController in the nib for each palette. Your window controller for the palette should then observe NSWindowDidBecomeMainNotification and update the NSObjectController's content pointer to point to the document corresponding to whatever window is currently the main window. Change that one pointer, all your bindings re-point, everything is rosy. Mike ___ 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 arch...@mail-archive.com
Re: Application Architecture or approach
On 11-Feb-09, at 23:39 , Michael Ash wrote: Your window controller for the palette should then observe NSWindowDidBecomeMainNotification and update the NSObjectController's content pointer to point to the document corresponding to whatever window is currently the main window. Change that one pointer, all your bindings re-point, everything is rosy. Ok, that sounds promising, but, when one of the element on the path changes like the document, will all the gui element of the palette be triggered to refresh the displayed value to newly selected document value ? Louis Demers eng. www.obzerv.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
