Re: Can Peer-to-Peer Model Be Launched in AppStore?
Dear Jens, I just know about the constrains on 3G. Thanks so much for your replies! I will implement my system on WiFi first. Because of LAN, the multicast is not so flexible as on a true P2P. The load on my server must be high. On 3G, the iPad must always establish the connection and send requests before getting data from other nodes, right? That is not my expectation. I will try app notifications instead. Thanks again! Best, Bing On Mon, Aug 22, 2011 at 1:49 PM, Jens Alfke wrote: > > On Aug 21, 2011, at 10:32 PM, Bing Li wrote: > > According to your email, P2P is not available on 3G? > > > A device can’t receive an incoming TCP connection over 3G. That’s part of > the way the carriers run IP over their cell networks, not anything mandated > by Apple. > > (All the incoming signaling handled by iOS, like phone calls, SMS, and app > notifications, runs directly over GSM without using IP. 3rd party apps > definitely don’t have access to that low-level functionality; the carriers > are pretty nervous about unauthorized use of it.) > > If so, P2P based applications cannot be launched in AppStore? > > > No, it doesn’t rule out P2P, it’s just that the device will have to be the > one making the connection. > > For example, it’s possible to run a BitTorrent node without accepting > incoming connections; in practice, the other nodes will think you’re > leeching and probably won’t send you much data, but that’s a matter of > configuration, not part of the protocol. It all depends on how your protocol > works. > > Without 3G's support, how can a P2P system run in a wireless environment? > > > WiFi? Bluetooth? > > > —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Can Peer-to-Peer Model Be Launched in AppStore?
On Aug 21, 2011, at 10:32 PM, Bing Li wrote: > According to your email, P2P is not available on 3G? A device can’t receive an incoming TCP connection over 3G. That’s part of the way the carriers run IP over their cell networks, not anything mandated by Apple. (All the incoming signaling handled by iOS, like phone calls, SMS, and app notifications, runs directly over GSM without using IP. 3rd party apps definitely don’t have access to that low-level functionality; the carriers are pretty nervous about unauthorized use of it.) > If so, P2P based applications cannot be launched in AppStore? No, it doesn’t rule out P2P, it’s just that the device will have to be the one making the connection. For example, it’s possible to run a BitTorrent node without accepting incoming connections; in practice, the other nodes will think you’re leeching and probably won’t send you much data, but that’s a matter of configuration, not part of the protocol. It all depends on how your protocol works. > Without 3G's support, how can a P2P system run in a wireless environment? WiFi? Bluetooth? —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Can Peer-to-Peer Model Be Launched in AppStore?
On 22/08/2011, at 3:32 PM, Bing Li wrote: > Without 3G's support, how can a > P2P system run in a wireless environment? Using Bluetooth. It's the only mode supported by the Game Centre at present. --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: Can Peer-to-Peer Model Be Launched in AppStore?
Dear Jens, Thanks again for your reply! According to your email, P2P is not available on 3G? If so, P2P based applications cannot be launched in AppStore? Without 3G's support, how can a P2P system run in a wireless environment? Best, Bing On Mon, Aug 22, 2011 at 1:18 PM, Jens Alfke wrote: > > On Aug 21, 2011, at 9:27 PM, Bing Li wrote: > > On the iPad, I program with BSD socket to communicate with a cluster which > is implemented with Java/Linux. The distributed model is based on the one of > P2P. > > > Um, that’s about as vague a description as possible, but OK. > > I hope it could run on WiFi or 3G environment. > > > Be aware that you can’t receive incoming TCP connections over 3G. You may > be able to open the listener socket, but the carrier’s network isn’t going > to route any connection requests to you even if some other host can figure > out your IP address. > > Even on WiFi, receiving incoming connections from outside the LAN is … > challenging. I’m not sure if the Bonjour library on iOS has the same > port-mapping support that it does on OS X; if it does, that helps somewhat > (if the base station/router is either an AirPort or supports UPNP). > > —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Can Peer-to-Peer Model Be Launched in AppStore?
On Aug 21, 2011, at 9:27 PM, Bing Li wrote: > On the iPad, I program with BSD socket to communicate with a cluster which is > implemented with Java/Linux. The distributed model is based on the one of P2P. Um, that’s about as vague a description as possible, but OK. > I hope it could run on WiFi or 3G environment. Be aware that you can’t receive incoming TCP connections over 3G. You may be able to open the listener socket, but the carrier’s network isn’t going to route any connection requests to you even if some other host can figure out your IP address. Even on WiFi, receiving incoming connections from outside the LAN is … challenging. I’m not sure if the Bonjour library on iOS has the same port-mapping support that it does on OS X; if it does, that helps somewhat (if the base station/router is either an AirPort or supports UPNP). —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crash Reporter for Lion
Nice to now about it Graham, But in my case its a beta-version of my software, so, It will be out of App Store (at least for now). The FeedbackReporter worked well here :) Thanks Sean. --- Wilker Lúcio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 On Sun, Aug 21, 2011 at 7:43 PM, Graham Cox wrote: > > On 20/08/2011, at 6:18 AM, Wilker wrote: > > You have any recommendations on what I could use for that? > > > > If your app is going to be on the App Store, the standard Apple crash > reporter is all you need - when Apple receive crash reports for your app, > they are passed along to your App Store account and can be browsed in the > iTunes Connect interface. > > So you might not need to do anything. > > --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: Can Peer-to-Peer Model Be Launched in AppStore?
Dear Jens and Evadne, I appreciate so much for your replies! On the iPad, I program with BSD socket to communicate with a cluster which is implemented with Java/Linux. The distributed model is based on the one of P2P. I hope it could run on WiFi or 3G environment. Best regards, Bing On Mon, Aug 22, 2011 at 4:13 AM, Jens Alfke wrote: > > On Aug 21, 2011, at 5:45 AM, Bing Li wrote: > > My system is being developed. It must be done in two months. My system is > based on P2P (peer-to-peer) model instead of Client/Server or Web based > ones. I am not sure if such applications can be launched in Apple AppStore? > > > I don’t see why not. There are other apps that make P2P connections, like > Things (it’s iOS-to-Mac, but same idea). My BLIP protocol’s being used by > several iOS apps. And I believe the Game Center networking functionality > runs over P2P Bluetooth connections. > > —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Transparency of textured controls
Am 19.08.2011 um 21:36 schrieb Leo: > Actually, I finally realized what the real issue is: Apple for some reason > didn't "refresh" NSSegmentedControl Rounded style to match the new appearance > of NSTabView controls on Lion. I guess that's intentional. The 'Capsule' style does look like the NSTabView controls. > And please bring back the colorful Finder sidebar Thats most definitely intentional. They said so in one of the sessions at WWDC, IIRC. It's meant to make the actual content stand out more. Andreas___ 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: Crash Reporter for Lion
On 20/08/2011, at 6:18 AM, Wilker wrote: > You have any recommendations on what I could use for that? If your app is going to be on the App Store, the standard Apple crash reporter is all you need - when Apple receive crash reports for your app, they are passed along to your App Store account and can be browsed in the iTunes Connect interface. So you might not need to do anything. --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: [SOLVED] Document-based app: UI item validation
>> My solution was to assign the menu item (the one with the submenu) a dummy >> action that does nothing. Then I used the normal >> 'validateUserInterfaceItem:' mechanism to enable or disable the menu item >> with that action, based on whether all of the submenu items were enabled or >> not. You could use a similar approach to change the menu title instead of >> its enable status. It's certainly possible that there's some obscure, >> unwanted UI behavioral side-effect of doing this, but I haven't seen any. > > I've been trying to do this during the last half hour, but without success so > far... I'll give it one more go tomorrow. > >> >> For completeness, I'll add that if there's some genuine reason why you >> couldn't use the 'validateUserInterfaceItem:' mechanism to solve your >> problem, then the correct solution may well be to use a menu delegate after >> all. But in that case, I wouldn't use the window controller as the delegate, >> I'd use a global (singleton) object such as the app delegate instead. That >> would move you're app's knowledge of the menu structure (which is app-global >> knowledge more than document-specific knowledge) into an app-global place, >> and it would properly separate the menu-structuring behavior from the >> menu-validating behavior. > > Using the app-delegate is what I've implemented at this moment, and this > works just fine. If the other solution (see above) doesn't work, this is what > I'll stick to. > >> >> But unless you're forced into this more invasive approach, I'd suggest you >> try the dummy action solution. >> > > OK, I've gotten your solution using a dummy action to work. 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 arch...@mail-archive.com
Re: Document-based app: UI item validation
On 21 Aug 2011, at 21:57, Quincey Morris wrote: > On Aug 21, 2011, at 12:22 , Luc Van Bogaert wrote: > >> What I was trying to explain: I want to change the title of a menuitem, >> which opens a submenu. Of course the menu items in that submenu all have >> actions, but the action of the menuitem I'm trying to change is '' >> submenuAction". > > OK, gotcha. > >> So, in order to validate my menuitem in the normal way, do I understand >> correctly that I would have to subclass NSMenu and assign this new class to >> the menu that is opened by my menuitem, and that I could implement >> 'validateUserInterfaceItems' in my new subclass ? > > My solution was to assign the menu item (the one with the submenu) a dummy > action that does nothing. Then I used the normal 'validateUserInterfaceItem:' > mechanism to enable or disable the menu item with that action, based on > whether all of the submenu items were enabled or not. You could use a similar > approach to change the menu title instead of its enable status. It's > certainly possible that there's some obscure, unwanted UI behavioral > side-effect of doing this, but I haven't seen any. I've been trying to do this during the last half hour, but without success so far... I'll give it one more go tomorrow. > > For completeness, I'll add that if there's some genuine reason why you > couldn't use the 'validateUserInterfaceItem:' mechanism to solve your > problem, then the correct solution may well be to use a menu delegate after > all. But in that case, I wouldn't use the window controller as the delegate, > I'd use a global (singleton) object such as the app delegate instead. That > would move you're app's knowledge of the menu structure (which is app-global > knowledge more than document-specific knowledge) into an app-global place, > and it would properly separate the menu-structuring behavior from the > menu-validating behavior. Using the app-delegate is what I've implemented at this moment, and this works just fine. If the other solution (see above) doesn't work, this is what I'll stick to. > > But unless you're forced into this more invasive approach, I'd suggest you > try the dummy action solution. > Thanks (again) for your help. ___ 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: Can Peer-to-Peer Model Be Launched in AppStore?
On Aug 21, 2011, at 5:45 AM, Bing Li wrote: > My system is being developed. It must be done in two months. My system is > based on P2P (peer-to-peer) model instead of Client/Server or Web based > ones. I am not sure if such applications can be launched in Apple AppStore? I don’t see why not. There are other apps that make P2P connections, like Things (it’s iOS-to-Mac, but same idea). My BLIP protocol’s being used by several iOS apps. And I believe the Game Center networking functionality runs over P2P Bluetooth connections. —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document-based app: UI item validation
On Aug 21, 2011, at 12:22 , Luc Van Bogaert wrote: > What I was trying to explain: I want to change the title of a menuitem, which > opens a submenu. Of course the menu items in that submenu all have actions, > but the action of the menuitem I'm trying to change is '' submenuAction". OK, gotcha. > So, in order to validate my menuitem in the normal way, do I understand > correctly that I would have to subclass NSMenu and assign this new class to > the menu that is opened by my menuitem, and that I could implement > 'validateUserInterfaceItems' in my new subclass ? I've had almost the same situation, except that I wanted to enable/disable the action-less menu item depending on whether any of the submenu items are enabled. (By default, a menu item with a submenu stays enabled, which makes sense from one point of view -- it still lets you look at the submenus. However, in this application (I decided), it adds an unwanted and ergonomically awkward step if the user has to open the submenu to find out if any item in the submenu can do anything right now.) My solution was to assign the menu item (the one with the submenu) a dummy action that does nothing. Then I used the normal 'validateUserInterfaceItem:' mechanism to enable or disable the menu item with that action, based on whether all of the submenu items were enabled or not. You could use a similar approach to change the menu title instead of its enable status. It's certainly possible that there's some obscure, unwanted UI behavioral side-effect of doing this, but I haven't seen any. For completeness, I'll add that if there's some genuine reason why you couldn't use the 'validateUserInterfaceItem:' mechanism to solve your problem, then the correct solution may well be to use a menu delegate after all. But in that case, I wouldn't use the window controller as the delegate, I'd use a global (singleton) object such as the app delegate instead. That would move you're app's knowledge of the menu structure (which is app-global knowledge more than document-specific knowledge) into an app-global place, and it would properly separate the menu-structuring behavior from the menu-validating behavior. But unless you're forced into this more invasive approach, I'd suggest you try the dummy action solution. ___ 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: Document-based app: UI item validation
On 21 Aug 2011, at 20:40, Quincey Morris wrote: > On Aug 21, 2011, at 11:13 , Luc Van Bogaert wrote: > >> I have found a way to get what I want using the sharedDocumentController >> object and the current document's list of windows. >> >> But actually, I'd prefer using 'validateUserInterfaceItems' as you suggest, >> except that some of the menu items that I want to change, are actually >> submenu's that don't send a message to my target object. So how would those >> get validated if they aren't using the target-action mechanism? > > So what is the purpose of the submenu items if they don't have an action? What I was trying to explain: I want to change the title of a menuitem, which opens a submenu. Of course the menu items in that submenu all have actions, but the action of the menuitem I'm trying to change is '' submenuAction". So, in order to validate my menuitem in the normal way, do I understand correctly that I would have to subclass NSMenu and assign this new class to the menu that is opened by my menuitem, and that I could implement 'validateUserInterfaceItems' in my new subclass ? > > Not that it matters much. The only way to display the submenu is to display > the menu item (well, the menu item's menu), so the menu item validation is > going to be called first. You can use validation of the menu item to trigger > updating of or contextualizing the submenu. That's the ordinary way, too. I think I understand, but I'm not yet clear on how I would trigger the validation of my menuitem, since its action is not implemented in any of my classes, instead it's implement by NSMenu. > > I forgot to say in my earlier response: > > You probably don't (in general) want to make a window controller the delegate > of a *menu*, because this means the window controller is going to need > knowledge of the structure of the menus themselves, and that's not desirable > -- if you moved an item to a different menu, you'd likely have to change the > window controller too. The 'validateUserInterfaceItem:' mechanism divorces > the menu item behavior from the menu structure. It also (potentially) > integrates validation across menu-bar menus, context menus, popup button > menus and toolbar items. It's "really" the action being validated, not the UI > representation of the action, if you want to think of it that way. > Thank you for this explanation. ___ 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: Document-based app: UI item validation
On Aug 21, 2011, at 11:13 , Luc Van Bogaert wrote: > I have found a way to get what I want using the sharedDocumentController > object and the current document's list of windows. > > But actually, I'd prefer using 'validateUserInterfaceItems' as you suggest, > except that some of the menu items that I want to change, are actually > submenu's that don't send a message to my target object. So how would those > get validated if they aren't using the target-action mechanism? So what is the purpose of the submenu items if they don't have an action? Not that it matters much. The only way to display the submenu is to display the menu item (well, the menu item's menu), so the menu item validation is going to be called first. You can use validation of the menu item to trigger updating of or contextualizing the submenu. That's the ordinary way, too. I forgot to say in my earlier response: You probably don't (in general) want to make a window controller the delegate of a *menu*, because this means the window controller is going to need knowledge of the structure of the menus themselves, and that's not desirable -- if you moved an item to a different menu, you'd likely have to change the window controller too. The 'validateUserInterfaceItem:' mechanism divorces the menu item behavior from the menu structure. It also (potentially) integrates validation across menu-bar menus, context menus, popup button menus and toolbar items. It's "really" the action being validated, not the UI representation of the action, if you want to think of it that way. The example you raised, though, where a submenu changes in response to (say) the document state *is* an example of the window controller needing knowledge of the menu structure (part of it, anyway). ___ 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: Document-based app: UI item validation
On 21 Aug 2011, at 19:34, Quincey Morris wrote: > On Aug 21, 2011, at 09:59 , Luc Van Bogaert wrote: > >> But this still leaves me with the question of how to reference my >> windowcontroller objects from the mainmenu nib? I need this because I want >> to modify the title of some menu items, depending on the state of the >> document windows. So I would like to make my windowcontroller objects menu >> delegates. > > This isn't the ordinary way of getting this result. > > The ordinary way is to implement 'validateUserInterfaceItem:' in each object > in the action responder chain that is responsible for some of the menu items. > In that method, the object checks to see if the item being "validated" is one > of the ones it it responsible for (which may be different at different times, > depending on the state of the document and/or the application). If so, it is > free to do anything it wants to the item, including changing the title. > > This decentralizes control over menu items (and other UI items handled > through the same mechanism), which can make it hard to get a grasp on what > items are handled where, but also makes decentralization of the interface via > multiple nib files possible, which is the purpose you're trying to achieve. > >> I thought about using an application delegate as file's owner in the >> mainmenu nib, and then target the menu items from this delegate. From the >> app delegate I can reference the window using keyWindow, but I haven't found >> a way to reference the windowcontroller objects... > > Changing the main menu nib's Files Owner sounds like a terrible idea. > > You're ignoring a fairly rich set of object interrelationships that eliminate > the need to invent odd ways of referencing things. There is a singleton > NSDocumentController that lists all the documents. Each document has a list > of its window controller. Each window controller has a reference to its > window. Windows have a "windowController" property. Window controllers have a > "document" property. What is it that you think is missing? > > That's beside the point, though, because if you handle the menu item > validation the "ordinary way", you won't need to solve this unnecessary > problem. > Thanks Quincey, I have found a way to get what I want using the sharedDocumentController object and the current document's list of windows. But actually, I'd prefer using 'validateUserInterfaceItems' as you suggest, except that some of the menu items that I want to change, are actually submenu's that don't send a message to my target object. So how would those get validated if they aren't using the target-action mechanism? ___ 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: Document-based app: UI item validation
On Aug 21, 2011, at 09:59 , Luc Van Bogaert wrote: > But this still leaves me with the question of how to reference my > windowcontroller objects from the mainmenu nib? I need this because I want to > modify the title of some menu items, depending on the state of the document > windows. So I would like to make my windowcontroller objects menu delegates. This isn't the ordinary way of getting this result. The ordinary way is to implement 'validateUserInterfaceItem:' in each object in the action responder chain that is responsible for some of the menu items. In that method, the object checks to see if the item being "validated" is one of the ones it it responsible for (which may be different at different times, depending on the state of the document and/or the application). If so, it is free to do anything it wants to the item, including changing the title. This decentralizes control over menu items (and other UI items handled through the same mechanism), which can make it hard to get a grasp on what items are handled where, but also makes decentralization of the interface via multiple nib files possible, which is the purpose you're trying to achieve. > I thought about using an application delegate as file's owner in the mainmenu > nib, and then target the menu items from this delegate. From the app delegate > I can reference the window using keyWindow, but I haven't found a way to > reference the windowcontroller objects... Changing the main menu nib's Files Owner sounds like a terrible idea. You're ignoring a fairly rich set of object interrelationships that eliminate the need to invent odd ways of referencing things. There is a singleton NSDocumentController that lists all the documents. Each document has a list of its window controller. Each window controller has a reference to its window. Windows have a "windowController" property. Window controllers have a "document" property. What is it that you think is missing? That's beside the point, though, because if you handle the menu item validation the "ordinary way", you won't need to solve this unnecessary 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document-based app: UI item validation
On 21 Aug 2011, at 18:59, Luc Van Bogaert wrote: On 21 Aug 2011, at 15:43, Jerry Krinock wrote: On 2011 Aug 21, at 05:02, Luc Van Bogaert wrote: Adding a windowcontroller to the mainmenu nib also doesn't work, as the windowcontrollers should be instantiated from my document objects. right? That is correct. So, that leaves me the option to use the First Responder object. This does work, but I'm still wondering if maybe there is a better approach. There is no better approach. "First Responder Magic" is a good thing to use. OK, thanks. But this still leaves me with the question of how to reference my windowcontroller objects from the mainmenu nib? I need this because I want to modify the title of some menu items, depending on the state of the document windows. So I would like to make my windowcontroller objects menu delegates. I thought about using an application delegate as file's owner in the mainmenu nib, and then target the menu items from this delegate. From the app delegate I can reference the window using keyWindow, but I haven't found a way to reference the windowcontroller objects... When creating the window controller in the document's method makeWindowControllers, you might set a property (you declared) to this window controller. This way you will have access to it from all methods of the document, including action methods. You should also be able to bind the button's title to something like "document.myWindowController.myButtonTitle". Regards Klaus ___ 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: Document-based app: UI item validation
On 21 Aug 2011, at 15:43, Jerry Krinock wrote: > > On 2011 Aug 21, at 05:02, Luc Van Bogaert wrote: > >> Adding a windowcontroller to the mainmenu nib also doesn't work, as the >> windowcontrollers should be instantiated from my document objects. right? > > That is correct. > >> So, that leaves me the option to use the First Responder object. This does >> work, but I'm still wondering if maybe there is a better approach. > > There is no better approach. "First Responder Magic" is a good thing to use. > OK, thanks. But this still leaves me with the question of how to reference my windowcontroller objects from the mainmenu nib? I need this because I want to modify the title of some menu items, depending on the state of the document windows. So I would like to make my windowcontroller objects menu delegates. I thought about using an application delegate as file's owner in the mainmenu nib, and then target the menu items from this delegate. From the app delegate I can reference the window using keyWindow, but I haven't found a way to reference the windowcontroller objects... ___ 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: Document-based app: UI item validation
On 2011 Aug 21, at 05:02, Luc Van Bogaert wrote: > Adding a windowcontroller to the mainmenu nib also doesn't work, as the > windowcontrollers should be instantiated from my document objects. right? That is correct. > So, that leaves me the option to use the First Responder object. This does > work, but I'm still wondering if maybe there is a better approach. There is no better approach. "First Responder Magic" is a good thing to use. ___ 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
Can Peer-to-Peer Model Be Launched in AppStore?
Dear all, My system is being developed. It must be done in two months. My system is based on P2P (peer-to-peer) model instead of Client/Server or Web based ones. I am not sure if such applications can be launched in Apple AppStore? Thanks so much! Bing ___ 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
Document-based app: UI item validation
Hi, I have a question regarding UI item validation in a document-based app. This is my current design: A separate nib for the main menu, and a separate nib for the windowcontrollers to be instantiated from my document objects using makeWindowControllers. For some of the menu items, I would like to use the target-action mechanism, and I would like to implement the action methods in my windowcontroller class. My question is, in the MainMenu.xib file, what would be the preferred way to link the menu items to their target object? I have tried setting my windowcontroller class as File's Owner in the mainmenu nib; but that didn't work, as the (first) windowcontroller object is only initialized *after* the menu is instantiated, resulting in "could not link target.." error message on startup. Adding a windowcontroller to the mainmenu nib also doesn't work, as the windowcontrollers should be instantiated from my document objects. right? So, that leaves me the option to use the First Responder object. This does work, but I'm still wondering if maybe there is a better approach. Thanks, -- Luc Van Bogaert ___ 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: Very different Document Saving in Lion, even without enabling asynchronous
I was talking about the -saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo: method that -saveDocument: has always been documented to call. In practice that method operated synchronously unless there was an error, but it's clearly an asynchronous API Sent from my iPad On 21 Aug 2011, at 06:46 AM, Jerry Krinock wrote: > > On 2011 Aug 17, at 16:30, Mike Abdullah wrote: > >> Seeing as you knew it called an asynchronous method internally, you must >> have known that it might potentially return before saving is finished. > > Thank you, Mike. I'm not surprised to see the new behavior after enabling > asynchronous saving. The surprise is the new behavior *without* enabling > synchronous saving (it should still be "synchronous"), and the fact that it > is now it behaves completely different from what is shown in the > documentation, and there is no mention of this change in the Release Notes. > > ___ > > 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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net ___ 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
