Does "activate behaviour" as the first item of an inactive Behaviour make sense ? (that has just been selected from the list of Audio & Video - e.g. EyeTV)?

To my mind, if I select a Behaviour (Application) that is inactive then I want it activated.

Also, the short menu press shows/hides the RB menu very well - it seems unecessary to have "hide menu" as a menu item within each behaviour (perhaps at the bottom) .. top item is important real estate ..

Also, I like how "quit" doesn't move left afterwards in the current approach (as one might be planning on reactivating). "Activate" if kept could then be placed below "quit" and "hide menu" at the bottom. Alternatively why not have remote buddy activate a behaviuor (when inactive and it is selected), have quit perform the quit and then move left, and remove hide menu. Simple is beautiful.

I do really like the stickyness .. how RB remembers the location.

An idea .. make the order based on usage (and still sticky) ?? Not sure haven't had time to digest if this would be cool or annoying .. I guess this sort of learning/adapting to usage is pat of what made LaunchBar so innovative/great ..

cheers, 
chris

"Hide menu" is, according to my experience, 99% 
useless. Would love to have an option in the prefs to 
hide it, or move it to the bottom (as Chris 
suggested).

I also would love to have an option to... how can I 
say... activate a behavior which automatically hides 
the RB menu. Like, for example, when I call up 
Dashboard... it's weird to have the widgets come right 
under the menu, and then I have to press "'Menu" on my 
Apple Remote to hide RB, and then "Menu" again to 
navigate to the Dashboard item to re-hide it.

I know, I shoul "Activate Exposé Behavior" and then 
have a button call up Dashboard, but my point is, I'd 
like to have the "automatically hide RB menu" option 
for certain items...

Like for Front Row, I don't like navigating to the 
Front Row item and then press Play, and then Play 
again to launch it.

Maybe I'm not totally used to RB after all ;-)

Thanks for "listening" :-)

Simon

--- chrisP 
a écrit :

thanks for your thoughts.

Yet, with which item should the "legend" for the current remote 
mapping be associated with, else?

Autohiding the RB menu when Dashboard comes up is super-easy to 
implement. I'll add that.

Regarding Front Row: I understand and I keep thinking about tweaks to 
the concept that both improve the experience and are still logical 
without exceptions.

Best regards, 
Felix 

it does make sense in that you can i.e. control application X in the 
foreground, but quickly go to the iTunes menu, its Music Library and 
select a different song for playback without having to activate / 
deactivate the Behaviour for that other application X.

I'm not sure, whether that is a much needed functionality, though.

The "Hide menu" item in fact is the same item as "Activate Behaviour" 
and "Deactivate Behaviour". It's the item that has the remote control 
mapping associated with it and gives you feedback about the status of 
the currently active Behaviour:

1) is it active, regardless of which app is in front (=> it will 
allow / require you to explicitly "Deactivate Behaviour") 
2) was it automatically selected / made active by Remote Buddy and 
will it be overriden by the next frontmost app (=> "Hide menu") 
3) is it currently inactive, but can be activated (=> "Activate 
Behaviour")

So, in fact, it's absolutely necessary for various reasons :-)

The reason why Quit / Activate & Co are at the bottom are this:

1) You can easily reach for those by pressing "up" when you are 
already on top of the menu (on that infamous entry ;-). 
2) Often there's functionality available for an application that 
you'll use more frequent (think "Music Library" or "Recent 
documents") and it would become pretty annoying to have to scroll 
over Quit / Activate & Co. before every time to access or even see 
that functionality.

Best regards, 
Felix 

thanks for your patience.

I had not really understood RB .. (not sure I do now fully .. ) I NOW understand that the Frontmost App is not necessarily Active (responsive to an RB remote).

Isn't this against the standard interface model - a keyboard and mouse are used to first bring an App to the front then the act on it and then if desired to send an App to the background (bring another one to the front)?

If you made remote buddy act on the front App (only) then my idea makes sense .. it would be a lot simpler.. and as above to act on another app just bring it to the front (when selecting it in the menu or activates it if not open) and all is the same ..

If I still don't understand how it works .. then I'll leave my follow-up on this for a month or two when I do .. :)

cheers, 
chris 

you're welcome! :-)

There are a few practical problems with your suggestions:

1) I don't know of a (fast and official) API to get a list of 
windows, their position and their parent application. 
2) Application windows don't necessary have to fill the screen or 
overlap other windows. Image a screen with a TextEdit window open on 
the left half of the screen and a SubEthaEdit window open on the 
right half of the screen. Now, which one of those applications should 
be considered active?

It's impossible for both reasons (and especially #2, because it can't 
be worked around) to implement automatic Behaviour selection based on 
the frontmost rather than the active application.

Remote Buddy tries hard to get an idea of what you are currently 
focusing on. If, i.e. you work in an unsupported app to do some 
writing and you have iTunes running in the background (i.e. it's not 
active), it'll nonetheless use the Behaviour to control iTunes. Same 
goes if you have started iTunes and DVD Player (both in the 
background): in that case, Remote Buddy will usually choose the 
iTunes Behaviour - until the moment you have a DVD in your drive. It 
will then assume you also want to watch it and selecte the DVD Player 
Behaviour.

Hope that explains why Remote Buddy is implemented the way it is.

Cheers, 
Felix 

Sorry I meant (to say) active or foreground application (as it would be if clicked on with a mouse).

So I'm saying:

1) RB menu could be used to select/change the active/foreground application (and start an app that is not running if selected).

I guess one would argue that Remote Buddy needs to detect if the active or foreground application is changed though another interface.

First question is why ? The user could just select through RM menu which app they want to be active again (RB would then foreground it).

If my lack of understanding of the tech details or oversimplification makes this debate miss the mark then apols.

Best, 
chris

I understand things better now, I guess. From a programmer's point of 
view the active application and the application in the foreground can 
be two different things. The first actually has focus for mouse and 
keyboard events (=> and usually also shows its name in the screen's 
titlebar) and the latter is just the one that appears to be in front 
of all other windows, but doesn't necessarily also have the focus for 
mouse and keyboard events ;-)

However, you can do what you're looking for (or: almost .. not yet .. 
as in: soon ;-).

The solution is, as often, a customized menu, in which you just drag 
and drop the applications you want to start there or make them 
active, if they are already running.

Only problem with RC1 is that it will rather browse the application's 
bundle instead of launching the app. This is fixed in RC2.

Until then, although not equally simple, is to drag and drop the 
Behaviours of the applications into the top level of a customized menu.

Best regards, 
Felix 

I've been using a custom menu for a while as below (as this is my TV):

EyeTV 
Front Row 
DVD Player 
--- 
VOL 
--- 
Applictions 
Audio & Video 
Audio & CD/DVD 
Files 
System 
Input Devices 
All windows 
Quit Remote Buddy

One minor question: is there a way to strip out menu items for custom behaviours (my household keeps hitting the white screen of death issue and thus I want to remove all menu items until this is fixed and force use through EyeTV menus) ?

cheers, 
chris

thanks for asking. The context menus of Behaviours can't be freely 
configured as of yet. I hope to have that in place for RC2, though.

Best regards, 
Felix