Things I've tried: 
* I did uncheck the duplicate behavior under the "Behaviors" section. So only one is checked.

* My behavior has its own identifier "com.Plex.scriptedbehaviours.migueld"

* I do have "Manually activated Behaviors stay active until they are explicitly deactivated"

Request: 
Can the duplicate behavior be completely deactivated when unchecked from the "Behaviors" list so that it doesn't interfere with the active behavior?

1) Behaviours that are unchecked are completely deactivated and do no 
longer take part in the matching process (I just re-checked the 
sourcecode).

2) RB uses only the identifiers, not the names of Behaviours to 
identify them.

3) You really shouldn't modify RB's bundle. It breaks the code signing 
applied to RB and can (and most likely will) give you problems with 
Leopard's firewall and keychain, both of which Apple has designed to 
keep apps with broken code signing out and/or repeatedly get on your 
nerves by asking the same questions over and over again on each start. 
(On the plus side - and the reason RB uses code signing - with code 
signing intact Leopard automatically handles firewall settings and 
won't prompt you for keychain access after software updates)

4) "Manually activated" means that you have to manually activate the 
Behaviour in order for the Behaviour selection to stay "sticky" until 
you manually deactivate it. This can be achieved by either

a) mapping an action found under "Behaviours > Behaviour" in the 
Mapping table 
b) using an action found under "Actions > Behaviour" in the Menu table 
c) using the menu and select a "Activate XY" entry

All other ways to start an app - including outside of RB, via 
AppleScript or by dragging and dropping an application from the Finder 
into RB's menu - are not handled as "manual activation".

BTW: you really shouldn't invest any time in a duplication of a 
Behaviour that RB already ships with. It's better to add custom 
actions to the existing Behaviour if you need anything in addition to 
what's already provided. That way you automatically benefit of feature 
upgrades and bugfixes and don't have to manually keep your own 
Behaviour in sync with the latest Plex updates.

Best regards, 
Felix Schwarz 

My main issue with the default Plex behavior is that I need the actions to "Send event directly to this application" but there is no way to change them AFAIK. The reason is that I have dual screens, and so I want to manipulate Plex on the second monitor without stealing focus from my other programs in the primary screen. So basically I can't use any of the default actions; I need to manually create every single custom action.

My other issue with the default behavior is that it's very incomplete, it's missing many actions such as rewind, fast forward, contextual menu (C), skip step back, big step forward, switch screens (command shift →), subtitles, audio toggle, volume mute, etc. While I know the user can add these actions as custom actions, it takes too much work to add them; it's not as user friendly as if the actions were included by default.

Another issue is that the default Plex actions are not available in the Global mapping.

After some thought, I concluded that it'd be easier for me to maintain my own behavior than to use the default, since I would have had to make every single custom action from scratch anyway and the UI interface to do so is far easier in the behavior construction kit (after the slightly steep learning curve).

So that's my current usage, perhaps there is something that I'm overlooking and you may have a simple fix, or perhaps you could find another solution.

With regards to the conflict of having two behaviors with the same name, I do know that for some reason, the behavior kept getting deactivated, and I'm not sure why... I'll keep an eye to see what else could be triggering the deactivation..

Last edited: 18.01.2009 01:58:37

Last edited: 18.01.2009 01:59:57

Last edited: 18.01.2009 02:00:52