search

dustinrue / ControlPlane

ControlPlane - context-sensitive computing for OS X
http://www.controlplaneapp.com
BSD 3-Clause "New" or "Revised" License
1.76k stars 181 forks source link

Feature Request: AND Rules #63

Open satch opened 13 years ago

satch commented 13 years ago

It would be very nice to have the ability to AND sources to establish a context. Example, at home I have wlan and wired, and I don't want timemachine to kick off when I'm on wlan. I have it working today, but it takes a bit of fiddling with the contexts and rules to get the preferences just right. If I could have a rule that says "if context=Home AND Wired=1 -> subcontext=HomeWired, confidence = 100%"

Or if using contexts as a source (for subcontext rules) isn't easy, then having the set of things that I currently use to say Home ANDed with wired vs wlan.

Less worring about the math and more precise context definitions.

djbe commented 13 years ago

Context groups are already being worked on, and active CP context(s) as an evidence source is something I've wanted to add for a while, if only for the weird stuff you could do with it :-P

Dunno if AND rules would still be needed then. They are already implemented IMO: make 2 rules of both +-50% and a context min. confidence of 80% should do it.

satch commented 13 years ago

re: AND, agreed that it's possible to make it work today, but when you get more complex scenarios, such as multiple contexts using the same source but in combination with other sources, it gets complex to adjust the math/sliders right so that it chooses the correct one. I'm suggesting this as more of a user-experience improvement since technically you should be able to work out the percentages to get what you want. Being able to AND two sources would simplify the logic side for the end user.

Context Groups sounds interesting. I've only been really using CP for a short time, and it's already been immensely useful. Figuring out how to make to do what I wanted was what brought me to the idea of the AND since I had to dig into the math to understand how to make it work. The added value of the AND is that you can limit the confidence to a single context where both apply, and still have them individually apply to other contexts that might also use them. Boolean sources come to mind here (power, network active, etc).

I guess another way could be to do source groups with a single confidence value for the group. That might be more intuitive than logic operators.

dustinrue commented 13 years ago

I think I understand what you're saying and I've also struggled with it. If I have sub contexts it's difficult to get them selected reliably. If I setup a work context that requires a certain wifi network and monitor be attached and then create a sub context within the work context that is time of day, the time of day rule will cause CP to move to the sub context during that time of day regardless of whether or not the work context is active. This is an issue within CP's core algorithm because it only takes into account whether or not rules match, it doesn't full get the concept of a hierarchy of contexts and subcontexts.

I'll see how hard it would be to get CP to understand the flow of contexts and sub contexts but I expect this will be more robust in the rewrite.

icopp commented 13 years ago

Not that I can speak for anybody else, but I'd personally prefer something with the confidence processing gone completely (or at least with an option to disable it) in favor of AND/OR/NOT rules being available. I end up just setting everything to 100% confidence, because I like to set up very thorough rules in the first place.

dustinrue commented 13 years ago

I'm actually not a fan of the percentage based system either but I understand the original intent. Where before originally it might have been somewhat difficult to reliably determine location, the ubiquity of wireless, OS X's location services and such have made it much easier to know for sure where you.

It won't happen in the 1.x releases of ControlPlane, but a 2.x may get rid of percentage based guessing, at least for each individual rule.

djbe commented 13 years ago

Allright, as I'm developing 2.x, we might as well discuss this :-P

Right now the rewrite uses kind of the same algorithm as the current version. But if we want to ditch the percent system, we'll need something similar to logical expressions (and, or, not). That's easy to implement, but does anyone have a good idea for the UI?

icopp commented 13 years ago

My general thoughts: A two-pane layout.

djbe commented 12 years ago

What I had in mind is a more iTunes smart playlist or Finder smart folder approach, especially concerning the rules. Take this for example:

Finder smart folder

Imagine on the left the contexts, divided in groups, similar to how the user's folders are in a group on this image. Rules are added/removed similarly to how they're added here. Combined rules are added by alt-clicking on the '+' button (see here).

So far I don't see any need for the 'files' pane as shown in the image. Instead, a second preferences tab again shows the contexts (and groups) on the left side/pane, and a list of actions (type, name, when, enabled) on the right. Kind of similar to how it is right now, but only actions belonging to a selected context are shown, much easier to use.

On another note: I've removed rule confidence in the 2.x branch, it now uses booleans. And I've added combined rules (all, any, none).

djbe commented 12 years ago

Allright, unless someone really objects, I'm going to use this type of interface. What makes it easy is that Apple already provides NSPredicateEditor and we can subclass NSPredicateEditorRowTemplate (explained here for custom rule types (which need multiple parameters or something similar).

The downside is that I might have to rethink and rewrite a bit how rules work, maybe making them work with CoreData. Or maybe a parser that translates a predicate into a bunch of rules (of the kind that we already have).

dustinrue commented 12 years ago

I'd like to see us use CoreData for this. Contexts and rules are becoming much more relational and it'll simplify everything in the long run. I also like the interface idea, it's perfect for this.

satch commented 12 years ago

Looks good to me, and meets my original request quite nicely. Let me know when you get to a point where you want an alpha test drive or UI review.

macnewbold commented 12 years ago

+1 - I really really need some AND rules and some NOT rules. I use three contexts: One at work when I'm plugged in to wired ethernet (and the wifi network is visible), one for at work when I'm not plugged in (defined primarily by the absence of the wired network and stuff attached to it), and one for everything else (defined completely by the absence of the other two conditions). Lately in particular, I'm getting a lot of context flapping, which happens to be since the time I upgraded to Lion if that makes any difference. It will flip back and forth between the wired and wireless settings at work, often going back and forth 5 or 6 times taking several minutes to settle down.

Please increase the priority of NOT and AND rules (and while you're at it, OR rules would be great too), to improve this already great tool.

dustinrue commented 12 years ago

When I would run into this, I'd try to use other evidence sources, sources that are more reliable given each state. How are you deciding if you are connected via the wired network vs not? To be complete, what evidence sources are you using?

macnewbold commented 12 years ago

The sources I'm using are all reliable, the biggest problem is simply that there is very little difference between the two situations. I often am literally sitting at the same desk with all the same stuff attached, with the only difference being whether I'm connected to the wired ethernet, or left it unplugged and am using just the wireless. Everything else centers around that, like the visibility of certain other machines in the network, etc. The work-wifi context is identical to the work context, except that it should be used when there is no wired ethernet present. My default context (used everywhere that is non-work) is defined by the absence of the work wifi network. But right now I can't set a rule that says "if NOT (Wifi SSID WORKWIFI) then context Other, confidence 100%". Similarly, I can't write a rule that says "if (Wifi SSID WORKWIFI) AND NOT (IP=10.3.x.x) then context WorkWifi confidence 100%", nor even one that says "if (wifiSSID=WORKWIFI) AND (IP=10.3.x.x) then context WorkWired confidence 100%". I have strong confidence of certain things based on the absence of certain conditions, but right now I can't test for that.

Am I making any sense?

BTW, thanks a ton for building ControlPlane. It's been very helpful - when I'm on the work wired network, I need to set my network location and run a script to set up some special routing. When I'm on the work wifi, I need to change the network location back, and undo the special routing, and start up the VPN client instead. When I'm not at work, I just need it to go back to normal settings. Control plane overall has worked really well for making that automatic for me.

One other minor thing: It would be super nice if when running a shell script that needed sudo, to run as root, if it could do the little popup to ask me to approve it. Maybe I'm doing it wrong, but I put the sudo command in the script, and on the command line it asks me fine, but it fails when control plane tries to run it, unless I add NOPASSWD to my sudoers file for what that script needs.

Thanks again, Mac

On Thu, Feb 16, 2012 at 8:08 PM, Dustin Rue reply@reply.github.com wrote:

When I would run into this, I'd try to use other evidence sources, sources that are more reliable given each state.  How are you deciding if you are connected via the wired network vs not?  To be complete, what evidence sources are you using?

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4014439

Mac Newbold mac@macnewbold.com 801-694-6334

djbe commented 12 years ago

Concerning your sudo question, the closest thing that I've found is this:

do shell script yourshellscript with administrator privileges

which will ask for your admin password. More than that can't be done in CP without having security risks.

On 17 Feb 2012, at 17:51, Mac Newbold wrote:

The sources I'm using are all reliable, the biggest problem is simply that there is very little difference between the two situations. I often am literally sitting at the same desk with all the same stuff attached, with the only difference being whether I'm connected to the wired ethernet, or left it unplugged and am using just the wireless. Everything else centers around that, like the visibility of certain other machines in the network, etc. The work-wifi context is identical to the work context, except that it should be used when there is no wired ethernet present. My default context (used everywhere that is non-work) is defined by the absence of the work wifi network. But right now I can't set a rule that says "if NOT (Wifi SSID WORKWIFI) then context Other, confidence 100%". Similarly, I can't write a rule that says "if (Wifi SSID WORKWIFI) AND NOT (IP=10.3.x.x) then context WorkWifi confidence 100%", nor even one that says "if (wifiSSID=WORKWIFI) AND (IP=10.3.x.x) then context WorkWired confidence 100%". I have strong confidence of certain things based on the absence of certain conditions, but right now I can't test for that.

Am I making any sense?

BTW, thanks a ton for building ControlPlane. It's been very helpful - when I'm on the work wired network, I need to set my network location and run a script to set up some special routing. When I'm on the work wifi, I need to change the network location back, and undo the special routing, and start up the VPN client instead. When I'm not at work, I just need it to go back to normal settings. Control plane overall has worked really well for making that automatic for me.

One other minor thing: It would be super nice if when running a shell script that needed sudo, to run as root, if it could do the little popup to ask me to approve it. Maybe I'm doing it wrong, but I put the sudo command in the script, and on the command line it asks me fine, but it fails when control plane tries to run it, unless I add NOPASSWD to my sudoers file for what that script needs.

Thanks again, Mac

On Thu, Feb 16, 2012 at 8:08 PM, Dustin Rue reply@reply.github.com wrote:

When I would run into this, I'd try to use other evidence sources, sources that are more reliable given each state. How are you deciding if you are connected via the wired network vs not? To be complete, what evidence sources are you using?

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4014439

Mac Newbold mac@macnewbold.com 801-694-6334

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4023407

macnewbold commented 12 years ago

Where would I enter that? The ShellScript action seems to only take a filepath as a parameter.

Thanks, Mac

On Fri, Feb 17, 2012 at 10:04 AM, David Jennes reply@reply.github.com wrote:

Concerning your sudo question, the closest thing that I've found is this:

  do shell script yourshellscript with administrator privileges

which will ask for your admin password. More than that can't be done in CP without having security risks.

On 17 Feb 2012, at 17:51, Mac Newbold wrote:

The sources I'm using are all reliable, the biggest problem is simply that there is very little difference between the two situations. I often am literally sitting at the same desk with all the same stuff attached, with the only difference being whether I'm connected to the wired ethernet, or left it unplugged and am using just the wireless. Everything else centers around that, like the visibility of certain other machines in the network, etc. The work-wifi context is identical to the work context, except that it should be used when there is no wired ethernet present. My default context (used everywhere that is non-work) is defined by the absence of the work wifi network. But right now I can't set a rule that says "if NOT (Wifi SSID WORKWIFI) then context Other, confidence 100%". Similarly, I can't write a rule that says "if (Wifi SSID WORKWIFI) AND NOT (IP=10.3.x.x) then context WorkWifi confidence 100%", nor even one that says "if (wifiSSID=WORKWIFI) AND (IP=10.3.x.x) then context WorkWired confidence 100%". I have strong confidence of certain things based on the absence of certain conditions, but right now I can't test for that.

Am I making any sense?

BTW, thanks a ton for building ControlPlane. It's been very helpful - when I'm on the work wired network, I need to set my network location and run a script to set up some special routing. When I'm on the work wifi, I need to change the network location back, and undo the special routing, and start up the VPN client instead. When I'm not at work, I just need it to go back to normal settings. Control plane overall has worked really well for making that automatic for me.

One other minor thing: It would be super nice if when running a shell script that needed sudo, to run as root, if it could do the little popup to ask me to approve it. Maybe I'm doing it wrong, but I put the sudo command in the script, and on the command line it asks me fine, but it fails when control plane tries to run it, unless I add NOPASSWD to my sudoers file for what that script needs.

Thanks again, Mac

On Thu, Feb 16, 2012 at 8:08 PM, Dustin Rue reply@reply.github.com wrote:

When I would run into this, I'd try to use other evidence sources, sources that are more reliable given each state.  How are you deciding if you are connected via the wired network vs not?  To be complete, what evidence sources are you using?

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4014439

Mac Newbold mac@macnewbold.com 801-694-6334

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4023407

Reply to this email directly or view it on GitHub: https://github.com/dustinrue/ControlPlane/issues/63#issuecomment-4023632

Mac Newbold mac@macnewbold.com 801-694-6334

djbe commented 12 years ago

Oh if it wasn't clear, that's a line of applescript code. You can create an applescript file that calls your shell script with admin rights, or embed the shell script in the applescript if it isn't too long.

On 17 Feb 2012, at 19:32, Mac Newbold wrote:

Where would I enter that? The ShellScript action seems to only take a filepath as a parameter.

Thanks, Mac

sanzoghenzo commented 11 years ago

sorry if it's too old, and the development took the multiple contexts road, but I would like to add my 2 cents. From what I see on the support group and the feature requests here, it seems it's not so useful to keep the context paradigm. Moving to a "set of rules"->"list of action" would be more straightforward for the user.
I think an Hazel-style interface would be great (and similar to what djbe proposed): basically the interface would become a list of rules in which you can set the conditions (with "all"-"any"-"none" conditional, and the possibility to alt+click the + button to have nested all/any/none conditions) and all the action to be executed. Rules could be duplicated to add/modify some conditions and setting up all the automation faster. That way you can ditch also the "entering" or "exiting" context since it would be a matter of duplicate and reverse the conditions (at least is what I can think in my head, i.e. if SSID is home then disable screensaver password and unmute audio, if SSID is not home then enable screensaver password and mute audio).

sorry for my english, keep up the good work!

brandondrew commented 10 years ago

:+1: I love the idea of a Hazel-style UI. Instead of simply saying "when I'm in the X context, do Y", we could make much richer, more complex sets of conditions, and deal with subtleties of our needs that the evidence → rule → context → action chain can't handle. "If I'm in X or Z context and A is true, then do Y, but otherwise do B and C."

For some more concrete (though less complex) examples, where boolean logic (and a Hazel-style UI) would be handy: