Re: Mixed-state checkboxes
On Jul 8, 2016, at 7:36 AM, Jonathan Taylor wrote: > > I'm trying to work out the correct way to handle a mixed-state checkbox > (NSButton checkbox with allowsMixedState=YES), bound to a property on my > controller. I am intending it to serve as an "applies to all" type control at > the head of a column of checkboxes - so if other checkboxes in the column are > toggled, it will display a state of on (if all in column are on), off (if all > are off), or mixed if there is a mixture of states in the column. > It seems that allowsMixedState makes it possible to *present* the mixed > state, but also means that the user can click through the three states in > order. What I believe the normal interface would be in my situation is for a > user click on a box in on (or off) state to switch it to off (or on), and a > click on mixed state puts it to either on or off (not sure which). What I > would not expect is for a click when in off state to put it into MIXED state. > In this interface (if I have described it clearly!) it makes no sense for the > user to actively put the checkbox into mixed state. You could try using a custom subclass of NSButtonCell that overrides -nextState. Your override would examine the current state and return either NSOnState or NSOffState (never NSMixedState), depending on what the current state is. So: NSOnState -> NSOffState, NSOffState -> NSOnState, NSMixedState -> one of NSOnState or NSOffState as you prefer (or as super behaves), and, for good measure, handle the case where the current state isn't any of the above, too. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Mixed-state checkboxes
On Jul 8, 2016, at 11:44 , Jonathan Taylor wrote: > > I get an error: "this class is not key value coding-compliant for the key > globalChannelEnableState" It may well be that for the checkbox to be editable/actionable for the user, the underlying property must be settable. I think you could solve that by just providing a setter method that literally does nothing. However, this still leaves the issue of letting the binding (the UI end of the binding) know that the correct value is not the one it tried to set. Either one of two things is true: a. The binding, after setting a value, assumes that is the value. b. The binding, after setting a value, gets the value again, and uses that instead of what it set, to update the UI. If the answer is b, then you have nothing else to do. If the answer is a, as suggested by the fact that you’ve already gone to some trouble, then it’s harder. In this case, rather than trying to trigger a later update as you have, I think an alternative would be to use the validate mechanism. That is, you write a method named “validateGlobalChannelEnableState:” (with some more parameters, you can look it up in the KVC documentation, or I think Xcode will autocomplete it for you if you start typing the method name at the top level of your .m file). Such methods are intended to detect errors in user input, but they have the useful ability to return alternative (corrected) values that replace the user-entered value in the UI, without actually generating an error. Since bindings use KVC, they support validate automatically, and this may be the simplest way to restrict your user “input” to on and off. A warning: validate is a bit awkward to use, because it doesn’t have any automatic translation between scalar and object values like other KVC accessors do. So, for a checkbox, remember that the incoming/outgoing values will be NSNumber objects with a BOOL value. ___ 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: Mixed-state checkboxes
Thanks Quincey, that makes sense what you're saying about it being more an action method, and your suggested approach sounds nice. However, I have not managed to quite get things working based on what I think you were describing. I have set up an action on the checkbox, and based on your comment about "With no setter, the binding won’t try to update the property, it’ll basically be read-only" I changed the bound property to read-only. Maybe that was not what you had intended, but with Xcode 5 at least there did not seem to be a way I could explicitly say that the binding should only be used for reading only. Anyway, if I do that, I get an error: "this class is not key value coding-compliant for the key globalChannelEnableState". I wonder if I have misunderstood what you were meaning? Also, when you write: > You don’t need to dispatch anything to a later iteration of the main event > loop. (Even in your current code — the setter will automatically generate the > KVO notification, so doing it again later is redundant.) which of the three choices of code (switched by #if statements...) are you referring to, from the code I originally posted? For me, in the first and third options the will/didChangeValue calls are essential to avoid the checkbox being left displaying '-' state. Is that not the behaviour you would expect here? One option would be to take up your suggestion of the action method, but abandon the binding altogether and just set the actual state of the UI element directly from my code. I'd definitely be interested in understanding what it sounded like you were suggesting with a "basically read-only" binding though... Cheers Jonny On 8 Jul 2016, at 18:35, Quincey Morris wrote: > On Jul 8, 2016, at 05:36 , Jonathan Taylor > wrote: >> >> My setter code currently looks like this: >> >> -(void)setGlobalChannelEnableState:(NSInteger)state > > In the circumstances you describe, a setter method is effectively an action > method, not a setter — that is, it becomes a method that’s called when your > code needs to do something, rather than a way to set some state. As you’ve > found, the real setter method tends to work against you here, because you > have to figure out what the binding expects with the changed value it thinks > it’s setting. > > So, I think a cleaner approach is to leave out the setter method entirely, > and use a real action method instead. With no setter, the binding won’t try > to update the property, it’ll basically be read-only. When the checkbox is > clicked, the action method is still invoked — it’s a NSButton, after all. All > the action method has to do is retrieve the current global state via the > getter, then set the individual states needed to flip it, sandwiched between > one pair of will/didChange calls for the key “globalChannelEnableState”. > > You don’t need to dispatch anything to a later iteration of the main event > loop. (Even in your current code — the setter will automatically generate the > KVO notification, so doing it again later is redundant.) > ___ 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: Mixed-state checkboxes
On Jul 8, 2016, at 05:36 , Jonathan Taylor wrote: > > My setter code currently looks like this: > > -(void)setGlobalChannelEnableState:(NSInteger)state In the circumstances you describe, a setter method is effectively an action method, not a setter — that is, it becomes a method that’s called when your code needs to do something, rather than a way to set some state. As you’ve found, the real setter method tends to work against you here, because you have to figure out what the binding expects with the changed value it thinks it’s setting. So, I think a cleaner approach is to leave out the setter method entirely, and use a real action method instead. With no setter, the binding won’t try to update the property, it’ll basically be read-only. When the checkbox is clicked, the action method is still invoked — it’s a NSButton, after all. All the action method has to do is retrieve the current global state via the getter, then set the individual states needed to flip it, sandwiched between one pair of will/didChange calls for the key “globalChannelEnableState”. You don’t need to dispatch anything to a later iteration of the main event loop. (Even in your current code — the setter will automatically generate the KVO notification, so doing it again later is redundant.) ___ 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: Emailing from a daemon process
> On Jul 8, 2016, at 8:44 AM, Alastair Houghton > wrote: > > It has a very high probability of being marked as spam, whatever headers you > use, because it’ll be delivered direct to the recipient’s mail server Oh — I hadn’t thought of that. I sent my test email to myself, so of course it connected to my domain host’s SMTP. I just assumed that had come from my email settings. Yeah, this is pretty unlikely to work these days, for the reasons Alastair gave. Any SMTP server but your own ISP’s / domain host’s is going to assume you’re a spam-bot. The answer to “Why is it so hard to send email programmatically?” is basically “Because spammers.” (Also “because SMTP was designed in the 1970s/80s with no security considerations whatsoever, and we’ve never been able to graft proper useable security onto it, for reasons like backward compatibility and bike-shedding lack of consensus. Also, securing decentralized systems is hard.”) —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: Emailing from a daemon process
On 8 Jul 2016, at 16:13, Sal Conigliaro wrote: > > You can send mail using sendmail without having to configure Postfix or > Sendmail. > > Out of the box OS X can use sendmail to send messages. You can test it by > doing: > > echo “Subject: Email from OX“ | /usr/sbin/sendmail recipi...@domain.com > > (You’ll have to actually include more email headers so it has less chance > of being marked as spam) It has a very high probability of being marked as spam, whatever headers you use, because it’ll be delivered direct to the recipient’s mail server, most likely from a consumer ISP-owned IP range. Further, if you aren’t careful about the From: address, it’ll fall foul of SPF, DKIM and other similar rules intended to prevent spam. It’s best either to (a) send via the customer’s own e-mail account, which is tricky to configure and means you will need support for TLS (some mail servers only accept outbound e-mail over authenticated TLS connections), or (b) use a web server under your control to actually send the e-mail, and have the software make an HTTP POST to trigger it Kind regards, Alastair. -- http://alastairs-place.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Emailing from a daemon process
> On Jul 8, 2016, at 8:13 AM, Sal Conigliaro wrote: > > You can send mail using sendmail without having to configure Postfix or > Sendmail. > Out of the box OS X can use sendmail to send messages. I didn’t think this would actually work, but I tried it and it does. It relayed to the SMTP server of my personal email account, judging by the headers in the message as received: Received: from jens.local (xx-xx-xx-xx.dsl.static.fusionbroadband.com [xx.xx.xx.xx]) by connor.dreamhost.com (Postfix) with ESMTP id CBE6D2C98217 for ; Fri, 8 Jul 2016 08:37:59 -0700 (PDT) Received: by jens.local (Postfix, from userid 501) id 90842F8AC69; Fri, 8 Jul 2016 08:37:27 -0700 (PDT) (Dreamhost is my domain host / email provider.) I have two email accounts, so I don’t know how it decided which one to use. It’s not the first one in the list in either Mail’s prefs or the Internet Accounts system pref. I’m pretty sure this would not work from a daemon process, since there is no associated user account to look up mail configurations from, and the credentials to users’ SMTP accounts are unavailable since they’re in the users’ keychains. —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: Emailing from a daemon process
You can send mail using sendmail without having to configure Postfix or Sendmail. Out of the box OS X can use sendmail to send messages. You can test it by doing: echo “Subject: Email from OX“ | /usr/sbin/sendmail recipi...@domain.com (You’ll have to actually include more email headers so it has less chance of being marked as spam) Sal Depending on your customers and product, sending these to your server and > saving them there could be a support feature allowing you or the user to > log in and review them when needed. Even if you don't, almost every web > server is set up with sendmail such that you could utilize it instead. > -- > Gary L. Wade (Sent from my iPhone) > http://www.garywade.com/ > On Jul 7, 2016, at 11:01 AM, Carl Hoefs > wrote: > >> The manufacturers are probably running their own SMTP servers, and the > devices either talk to those directly, or (more likely) send HTTP requests > to the manufacturer’s web server, which then formats the email and sends it > to the SMTP server. > > > > Yes, this seems to be correct. I just checked such emails and I see the > manufacturers usually exploit gmail for this purpose (and I have no gmail > account). -- Sal Conigliaro, e design http://www.erinedesign.com @sconig ___ 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
Mixed-state checkboxes
Hi all,
I'm trying to work out the correct way to handle a mixed-state checkbox
(NSButton checkbox with allowsMixedState=YES), bound to a property on my
controller. I am intending it to serve as an "applies to all" type control at
the head of a column of checkboxes - so if other checkboxes in the column are
toggled, it will display a state of on (if all in column are on), off (if all
are off), or mixed if there is a mixture of states in the column.
My property has no backing variable, but a manually-implemented getter and
setter. I am happy with how the getter is working - it scans the column and
returns the appropriate state. What I am not sure about is how to handle the
setter.
It seems that allowsMixedState makes it possible to *present* the mixed state,
but also means that the user can click through the three states in order. What
I believe the normal interface would be in my situation is for a user click on
a box in on (or off) state to switch it to off (or on), and a click on mixed
state puts it to either on or off (not sure which). What I would not expect is
for a click when in off state to put it into MIXED state. In this interface (if
I have described it clearly!) it makes no sense for the user to actively put
the checkbox into mixed state.
So... my question is how to implement the correct behaviour?
1. It would be great if there was a flag I could set that says "behave like I
want", but I can't see one!
2. Failing that, I believe what I need to do is to spot the setter being called
with a value of -1 (mixed), and overrule that. However, I haven't found a way
of doing that that "feels right" - all successful approaches feel like a hack
rather than the right way of doing it. My setter code currently looks like this:
-(void)setGlobalChannelEnableState:(NSInteger)state
{
if (state == -1)
{
#if 0
// Checkbox remains in '-' state if I use this code
[self willChangeValueForKey:@"globalChannelEnableState"];
state = 1;
[self didChangeValueForKey:@"globalChannelEnableState"];
#elif 1
// Works. Schedule another call in a moment, to update the
value to 'on'
dispatch_async(dispatch_get_main_queue(), ^{
self.globalChannelEnableState = 1; });
return;
#else
// Also works. Change the input state and fall through to the
code that does the actual updating (below)
state = 1;
dispatch_async(dispatch_get_main_queue(),
^{
[self
willChangeValueForKey:@"globalChannelEnableState"];
[self
didChangeValueForKey:@"globalChannelEnableState"];
});
#endif
}
// Update state for all individual channels [code not shown here]
}
Can anybody comment, and maybe suggest a more elegant way of handling this? For
brevity, I have not shown the getter code, but remember that there is no
backing variable and the getter just examines the current program state to
determine what the correct value is.
Thanks for any comments
Jonny.
___
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
WKWebView and Mobile Safari and cookie sharing
I am finding conflicting information on this on the interwebs - and nothing in the docs. Is the WKWebView sharing cookies with Safari or not? My tests resulted in a "not sharing" but people e.g. on StackOverflow claim the opposite. What is it? cheers, Torsten ___ 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
