Proposed IDE Change CTRL-K (Keycode)

[FellippeHeitor]

Your call.

[SMcNeill]

Let me know how the latest works.  It's a compromise solution -- no pop-ups, but it changes the status area (where OK would normally sit), to instead present the status to PRESS ANY KEY TO INSERT _KEYHIT/_KEYDOWN CODE.  We're not really reacting with anything, so I don't think a whole input box would be necessary just to capture a single keypress, but the change to the status below seems like a suitable visual cue to the IDE's status, in case your cat hits CTRL-K while you go grab a soda or something and you wonder where the heck the cursor went. 

If it needs further tweaking, I'll work on it tomorrow.  I'm going to head on off for the night, as I've got an early day of worthless testing to do at the doctor's tomorrow morning.  ;)

[luke]

In DOS EDIT (and thus QBasic) ^K is "set bookmark" (and ^Q is "goto bookmark"). These commands wait for you to enter the number of the bookmark you want to set/goto by putting a "^K" etc. in the bottom right just to the left of the line number indicator. Perhaps a small piece of text on the bottom line indicating the IDE is awaiting further input would be less intrusive but still helpful?

[Cobalt]

Why?  It’s not confusing without a visual confirmation that CTRL-C copied text.  There’s no pop-up “Text copied, hit ENTER”.  :P

You’d get the visual feedback the moment you hit a key, in the form of its code appearing in the IDE.  ;)

Thats why I usually hit Ctrl-C twice just in case. I'm guessing doing the same in this instance would cause undesirable results?

[SMcNeill]

In DOS EDIT (and thus QBasic) ^K is "set bookmark" (and ^Q is "goto bookmark"). These commands wait for you to enter the number of the bookmark you want to set/goto by putting a "^K" etc. in the bottom right just to the left of the line number indicator. Perhaps a small piece of text on the bottom line indicating the IDE is awaiting further input would be less intrusive but still helpful?

That's basically what it's doing now, though it's indicating where our normal status goes that it's waiting for an input.

  [ You are not allowed to view this attachment ]  

Or are you envisioning something else, and I'm just not visualizing it?

[SMcNeill]

Thats why I usually hit Ctrl-C twice just in case. I'm guessing doing the same in this instance would cause undesirable results?

Hit CTRL-K twice, and it'd probably return put "100305k" or "100306k" on the screen for you.  It'd return the key value of the next key hit (in this case CTRL, whichever one you hit), and then type the next character on the screen as normal (which would be "k", in this case).  I don't think you want to get in a habit of double-tapping CTRL-K quick keycode inserts very much.  :)

[SMcNeill]

A ton of little tweaks were done on this, this morning, to try and get it to work flawlessly for us.  There's more to inserting and proper positioning of text inside a line in the IDE than what you'd think!  The way QB64 is structured, it tends to strip off leading and trailing spaces when saving a line of text, so it makes proper inserting of stuff a PITA.  (Or at least, it seems that way at the moment, to me.)

I'm thinking things should work as we'd expect now, but if any of you brave folks want to download the last version from the repo or development build and test it out, it'd be appreciated.  Feel free to report any glitches (in as much detail as possible so I can reproduce and fix them), ideas for improvement, or just general thoughts on the process, and I'll do what I can to look into anything brought up once I get back from the doctor's later this evening.  ;)

[OldMoses]

So far this is amazingly helpful. Saves oodles of time and mouse wear. I calls it a keeper.

[FellippeHeitor]

Message in the status area doesn't follow the interface colors; menu item in Help doesn't contain a hot key marker; Choosing the menu item engages the key detection but doesn't update the status area.

I feel mouse clicks should pass through and interrupt the listening loop.

You added an untracked temp qbx file in the latest commit, please avoid it.

[SMcNeill]

Message in the status area doesn't follow the interface colors;   menu item in Help doesn't contain a hot key marker; Choosing the menu item engages the key detection but doesn't update the status area.

I feel mouse clicks should pass through and interrupt the listening loop.

You added an untracked temp qbx file in the latest commit, please avoid it.

The status area changes colors?  To what?  I thought it was always white for the “OK”?  Is it the same color as the main text on the screen?

The menu item in help doesn’t need a hot key modifer, does it?  Who’s going to “Alt-H, find a hotkey in a list, press it”, when they can just CTRL-K?  Not every menu item needs a hot key set for them.

I’ll dig into why clicking from the menu doesn’t update the display when I get back home again Monday.  It should, since we just GOTO the same singular routine, but since it’s not, then I’ll need to dig into why it’s not.

As for the mouse, it’s best to ignore it completely.  You don’t want people to hit CTRL-K, move the mouse and click elsewhere, then hit a key and expect it to go somewhere else.  Usage should be kept as simple as possible: Hit CTRL-K, hit a key, it inserts the code at your cursor position.  If users are expecting to hit CTRL-K, move mice, press buttons, print files, take screen copies of stuff, and then finally come back and hit a key, they’re using it wrong.  Ctrl-k, hit a key, do the other stuff later — if you screw up, BACKSPACE or CTRL-Z is your friend.

temp qbx files should be listed in the .gitignore, so they’re not passed back and forth, just like the internal\temp folders are.  Feel free to add them to the ignore list if you want, or else I’ll get to them as well, when I get home on Monday.

[FellippeHeitor]

For good practice, add the hotkey to the menu.

You are printing with black background in the status area.

A mouse click as "cancel" measure is important, since just showing a message in the status area and locking mouse looks very bad for the end user - the whole IDE doesn't need to be locked. If you can't do it, I'll fix it once you're done with your tweaks.

Do not manually add qbx files.

[SMcNeill]

For good practice, add the hotkey to the menu.

You are printing with black background in the status area.

A mouse click as "cancel" measure is important, since just showing a message in the status area and locking mouse looks very bad for the end user - the whole IDE doesn't need to be locked. If you can't do it, I'll fix it once you're done with your tweaks.

Do not manually add qbx files.

I won’t be at home for several days to make any changes, so fix it however you want, so it floats your boat.  As long as I can hit a kay and insert its code into the IDE, I’m happy.

[FellippeHeitor]

I'll wait for your tweaks to come to a halt so I can get back to pushing changes.

[SMcNeill]

I'll wait for your tweaks to come to a halt so I can get back to pushing changes.

I’m done, as far as I know, except for whatever it is that’s not updating the display when clicked from the menu.  I have no clue why it’s not working, at the moment, since it’s the menu code that we GOTO ehen we hit CTRL-K.

[SMcNeill]

For good practice, add the hotkey to the menu.

Any suggestion on which key to highlight?  “K” is already taken, and it seems odd to me to make something else a hotkey with CTRL-K as the fast combo.

You also might want to go back and add a hotkey to the remark options in the menu.  Somebody apparently wasn’t applying good practice when they added those; none of the options have one — Toggle, Add, or Remove.