Mcdermj Heterodyne

Comments and changes to this ticket

• 

  mcdermj (at xenotropic) March 15th, 2011 @ 10:19 PM

  • State changed from “new” to “open”

  This behavior is because the main window isn't selected. I've been trying to think about things and decide what the "right" behavior is. If the behavior is going to be to allow click through on the main window whenever you're in the application, the receiver windows should probably become a panel instead, so that they disappear whenever the application is not selected. If they're going to stay regular windows, click through to the main window probably isn't appropriate. Note that if you click a link in a Safari window when the application is not active, that it will not follow the link. This is a similar situation.

• You flagged this item as spam.
  

  JohnJames March 16th, 2011 @ 03:42 AM

  I disagree. the whole point of the click thru in this case is to set the frequency conveniently. Now you have to remember if you are focused on the waterfall or not in order to do a single click or a double click. I am forever double clicking and thus moving way off of the desired frequency.

  Not Clicking thru on Safari is appropriate as you go to an entirely different view on the click. But here we are just setting the frequency in a consistent way.

• 

  mcdermj (at xenotropic) March 16th, 2011 @ 03:48 AM

  I agree as far as when you have the receiver windows selected, and your point is well taken. But, my understanding of your change from looking at the documentation is that it will react to clicks whatever application is selected. If you have Mail.app selected, and you click on the waterfall, it will react. I don't think this is the desired behavior. This is partially why I'm thinking making the receiver windows into panels instead of windows makes sense. It should allow you to click once in the main window when the application is active, but it won't react to clicks until it is active.

• You flagged this item as spam.
  

  JohnJames March 16th, 2011 @ 04:31 AM

  You almost had me convinced. Consider the following situation. You are using CocoaModem to listen to a signal and you see a new signal in the waterfall. You would still like to click through to this signal in the same way you do when you had the receiver window previously selected. In fact I can make the same argument if you were looking at mail. If you do not want the frequency change you select the menu. (We could add frequency to an undo behavior. To go back to the last frequency. Then it would not matter that you changed the frequency.)

• 

  mcdermj (at xenotropic) March 16th, 2011 @ 04:40 AM

  • State changed from “open” to “hold”

  The counterargument could be made that if you do want to change the frequency, select the application. To me it's the "least surprise" because there are very few applications that do any kind of click through. The problem with making it click through from other applications is that if all you want to do is bring the window to the front, you now have to hit the title bar before you do so. This is unexpected behavior because every other program on the system would just bring your window to front. This is why the behavior is by default the way it is. The cocoaModem argument is mildly persuasive, but it's merely one application you'd be using. I'm hesitant to make large swaths of a window, that I, personally, keep very large as active when the application is not active.

  Anyhow, check out the latest SVN commit. It has my preferred behavior implemented. If it's still annoying, I'll revisit it, but I'm fairly secure that this is the correct semantics.