debugger: local variables

flocsy🤠 said:

the best would be to have a checkbox at the top of the list: "Remember"

Something very close to this already happens, if I'm understanding you correctly and you mean the list of devices that appears when you run a Monkey C project under certain circumstances (first run when launch.json doesn't exist, or all runs when launch.json does exist.)

Whenever you're prompted to select a device, whether it's for run, Build Current Project, or Build for Device, the last selected device is placed at the top of the list and preselected.

So I guess you could make the argument that it's easy for ppl like me to run the previous device even when launch.json exists - it just takes an extra keystroke (press ENTER to select previous device).

So I think having a "remember" checkbox at the top of the list wouldn't add any extra functionality here.

In light of this, maybe you're right that it's a bug (or oversight) that we're not always prompted for a device to run when launch.json does not exist.

My argument was that whenever there is more than device in the manifest, the drop-down to choose device should be displayed even if there's no launch.json and he UI should work similarly with or without launch.json

I understand that part of what you said, did you understand what I said?

I specifically referred to this:

flocsy said:

the best would be to have a checkbox at the top of the list: "Remember"

And I said that if you meant there should be a checkbox labelled Remember at the top of the device list (aka "drop-down to choose device"), this would be redundant and unnecessary because the extension already remembers the last selected device.

Again, the last selected device is placed at the top of the list and pre-selected, so all you have to do is press ENTER to select the last device.

My point is that in light of this fact:

- There's no need for a "Remember" checkbox

- Maybe I was wrong about thinking that the behaviour that I like - where the extension doesn't prompt you for the device after the first time - is useful, since the behaviour that you like (always prompt for device) is almost the same except for an extra keystroke (press ENTER to select the last device)

Then again, even one extra keystroke could be seen as an annoyance. But my new point remains that even if Garmin did what you wanted (always prompt for device), all that would change for me is I'd have to press one extra key to confirm the selection of the previous device.

Maybe you took this too literally:

> So I guess you could make the argument that it's easy for ppl like me to run the previous device even when launch.json exists - it just takes an extra keystroke (press ENTER to select previous device).

I wasn't trying to rewrite your argument, I was trying to soften my original position.

Ofc even now you did not bother to clarify what you meant by "the best would be to have a checkbox at the top of the list: "Remember""- i.e. you didn't say exactly what you think "Remember" should do, especially in light of the fact that the last device is already remembered and pre-selected.

Maybe instead of "Remember" I should've written something like: "[don't] prompt for device". Though I agree that it's not a big deal to click one more time (I even do it with the Enter key). What I meant is that if having the extra enter/click bothers people then Garmin could prevent it this way.

flocsy🤠 said:

Maybe instead of "Remember" I should've written something like: "[don't] prompt for device".

If that checkbox is at the top of the device list, then how do you change it once you set it to not prompt for device?

Clearly the checkbox would have to be somewhere else, in a setting, as originally suggested/implied.

Even if it was in 2 places (device list and setting), just the presence of that checkbox would be annoying to users who don't want it (like you). I think it would be annoying to me in the case that I want to see the device list.

And it could also interfere with the existing functionality of placing the last used device at the top and pre-selecting it. I see at least two possibilities here:

- the checkbox is placed at the top, and the last used device is underneath. Maybe the last used device is still preselected, but this is awkward

- the checkbox is placed somewhere else other than the top (under the last used device?) and it's awkward

I think even if the last used device was never at the top, putting a checkbox in the list of devices would be awkward.

Right so all of this tells us that no matter Garmin does, ppl won't be happy.

We see this all the time in the device forums, when it comes to some functionality that Garmin changed to please half of the users, but only to piss off the other half who liked it the way it used to be.

I do have sympathy for Garmin when it comes to this, because these are no-win situations. No matter behaviour Garmin chooses, some people will be annoyed, and it's often not a realistic course of action to turn that behaviour into an option, because it only increases the complexity of the product. (Increased complexity = more testing, more dev time, more bugs)

For your case, you could try to auto-generate a launch.json which has run commands for ALL the devices.

e.g. instead of:

{
  "type": "monkeyc",
  "request": "launch",
  "name": "Run App",
  "stopAtLaunch": false,
   "device": "${command:GetTargetDevice}"
},

generate something like:

{
  "type": "monkeyc",
  "request": "launch",
  "name": "Run App (fr955)",
  "stopAtLaunch": false,
  "device": "fr955"
},
{
  "type": "monkeyc",
  "request": "launch",
  "name": "Run App (fr965)",
  "stopAtLaunch": false,
  "device": "fr965"
},

...

flocsy🤠 said:

I thought the checkbox could be at the top.

Right so I'll reiterate my objections:

- it's awkward

- it could interfere with that other behaviour you don't like (last device at the top)

- it's even more awkward if it's not at the top

- it's not good design to create a checkbox where checking it (or unchecking it) causes the checkbox itself to be inaccessible, unless you *also* put that checkbox somewhere else. I guess a good exemplar of this kind of thing is the "don't prompt me again" checkbox. Once you check that box, it won't be available in the same place (since the prompt will be hidden), but users may still want a way to restore the prompt that was hidden (which means there would have to be a separate setting)