Minor GUI tweak/settings Suggestions #1

[stoneskipper]

Hi - long-time user - ready post some suggestions, from the minor to the major.
Starting small ...
1. Instead of highlighting the background block of each parenthesis (which distracts me) I would prefer to color the character itself - a simple toggle "Highlight ( ) or block"

2. And actually this IS important, I feel. STOP jumping the cursor away from UNDO changes. That is, PLEEEAAASE leave the cursor near the last undo·ne edit - eg., at the end of the restored line. I can't tell you how annoying it is to have the page jump away from the thing I want to undo, which happens if the next undo will be elsewhere in the code. I prefer to see exactly what was changed - "in situ - and if the next undo takes the view away, well, "LET GRRR!" haha I often have to scroll around to find what was changed last, then redo and undo a few times more to see the before & after etc & blah blah blah. Just STOP that! or make it an option - eg. "Remain at last Undo or jump to next."

{#3 was fully covered - there is/was no issue with line-scrolling, only my understanding - thx}

____________________________________________________________________

Finally - I have to mention ... (some of you may have noticed) ... that for the first time in 15 years, I stumbled into the LET description in the Manual ... and laughed my ass off! Now whenever something goes afoul & stupid I growl, "LET GRRR!!"

4. So my 4th and final suggestion for this post is to note these alternative valid LET examples:
"LET GO!" plus "LET CORD!" Hopefully no one will ever see them!

Major Suggestions in the future, eg. regarding TYPE modification..

[FellippeHeitor]

Hello, stoneskipper, and welcome to the forum.

Thanks for all suggestions. They all seem very easy to implement as optional behaviors (I must admit I'm used to all of the things you described as nuisances so they don't even annoy me at this point).

About nº 3, maybe you'll be glad to know you can use CTRL+Arrow keys to scroll up/down instead of moving the cursor. Is that what you mean?

About nº 4, you sure know you can use the scroll wheel on your mouse (except on macOS), right?

-------

I believe the joke in the LET page of the wiki is to be credited to Clippy (like most of the writing done there), so there you have it. It's grumpy for a reason! (an internal joke you probably aren't aware of, being a newbie here - or are you? 15 years using QB64 you said?).

Keep the suggestions coming, they're all much appreciated. You can also create issue posts at https://github.com/Galleondragon/qb64/issues (the most appropriate place to register ideas/complaints/reports).

[Bert22306]

3a. Which reminds me of one other thing ... would it be TOO difficult to have the code scroll a line up or down immediately upon an arrow up/down, instead of having to push the screen up or down with the cursor? Again: PLEEAASE! Or make it an option ... I prefer the one-arrow-equals-one-line-shift method - am I the only one?

3b. This is related to the above ... I would be 1000 times more willing to scroll the screen with the mouse+scroll bar, if the scroll bar was USEFUL lol! It's about 1/3 the width it ought to be. I'm trying to program ... I don't need a thread-the-needle skill test when I'm trying to work :-)

On 3a, to elaborate slightly on Fellippe's response, it works now about as well as it can, IMO. The arrow key moves the highlighted line (moves the cursor), one line of code per key press, just like any other editor. And <ctrl>arrow key moves the entire code up or down, one line per key press, while leaving the cursor in the same position where it was, in the actual code.

Is this not as one would expect? I would not expect the arrow key alone to move the entire window of code, unless the cursor is at the top or bottom of the window. Same as other text editors, no?

(On 3b, I never use the scroll bar either.)

[stoneskipper]

100% Thanks!
 First ahhh I had somehow not discovered ctrl+arrow ... that IS exactly what I was looking for -- so, sorry there. And the mouse is ok, I just don't like more hands-away-from-kbd than necc....
2nd, re LET oh yeah I got it lol I have had the same thoughts since the 80's lol -- that's why I said "hope nobody sees it" it would suggest somebody actually wanted to KNOW what it meant/does ... which is NOTHING haha

3rd Of all my minor points, the one that is most difficult to adapt to for me is the code/page jumping during undo ... any thoughts there? are you just acclimated to that, too?

[SMcNeill]

2nd, re LET oh yeah I got it lol I have had the same thoughts since the 80's lol -- that's why I said "hope nobody sees it" it would suggest somebody actually wanted to KNOW what it meant/does ... which is NOTHING haha

Just remember though:  LET is worthless and does nothing, whereas $LET is how we define a variable for the precompiler to work with.  Don't let righteous disdain for the first cause you to overlook the power the second can offer us.  ;)

[stoneskipper]

well said ;-)

[FellippeHeitor]

3rd Of all my minor points, the one that is most difficult to adapt to for me is the code/page jumping during undo ... any thoughts there? are you just acclimated to that, too?

I find it quite useful that ctrl+z/ctrl+y reposition my cursor to the exact same spot where the change was undone/redone. It works the same in word processors and I assume in other IDEs too. How would you know when to stop undoing?

[Pete]

The difference with LET is simple.

me = u ' This is a statement.

LET me = u ' This is a permission statement.

Pete :D

[cr0sh]

Way, way back when (this was back before OpenGL was fully available in QB64 - I've been away from it for a long while) - I did a bunch of hacking on the IDE - and today when I installed 1.2, I noticed to my chagrin that likely none of my changes were ever incorporated into the main codebase (assuming it is the same stuff from back then).

For instance, one thing I modified was the directory/file listings - it may be a Linux only thing (the only OS I've used QB64 on) - but when you open up the file loader in the IDE, the names of the files and the names of the directories aren't in any real order; not alphabetical, not anything - they are all munged together, with folders randomly interspersed with files, and neither the files nor the folders follow any order.

To say the least, this makes locating a file or directory a big chore.

So back then, I took the code in the IDE and fixed it, so that the directories were at the top of the listing, and the files were below, and both were in alphabetical 0-9A-Z order.

I recall that there were other changes and whatnot I made as well, but I don't recall what they all were. This was all back on the .net site and forum, which is probably all lost (though I probably have a copy of the old IDE code somewhere).

I intend to dig it up - and perhaps revisit those changes, see what I did back then, and what (if anything) I can bring over to the current IDE to fix some of those glaring issues. Then maybe issue a proper pull request or something to the project to include the changes.

[FellippeHeitor]

For instance, one thing I modified was the directory/file listings - it may be a Linux only thing (the only OS I've used QB64 on) - but when you open up the file loader in the IDE, the names of the files and the names of the directories aren't in any real order; not alphabetical, not anything - they are all munged together, with folders randomly interspersed with files, and neither the files nor the folders follow any order.

To say the least, this makes locating a file or directory a big chore.

So back then, I took the code in the IDE and fixed it, so that the directories were at the top of the listing, and the files were below, and both were in alphabetical 0-9A-Z order.

I believe we did fix that recently. Did you get the stable or the development build?

[cr0sh]

I believe we did fix that recently. Did you get the stable or the development build?

Stable. Is it in the development build?

[FellippeHeitor]

It is. Please try it and see if that's what you mean.

[stoneskipper]

>  Moved to a more relevant location <

[stoneskipper]

{relocated from deeper in the thread}

Re "I find it quite useful that ctrl+z/ctrl+y reposition my cursor to the exact same spot where the change was undone/redone..."

Hmm. Well that's what I want too! But my cursor is less well-behaved methinks! To be clear >>

1. Suppose I have 3 pages (screen-fulls) of code.
2. I edit on screen #1, and this edit is good & final and never has to be tweaked again
3. I jump down to screen #3 & do several more edits, experimenting with variations on a line
4. I bail out & wish to go back to the original state of screen #3, likely to resume a different strategy at that place
5. I begin to ^Z my way backwards, often watching the code revert "in situ" -- { ie, it's helpful to flip an edit back & forth to look for a subtle line change you can't recall making exactly (in a flurry of false confidence lol), but which is visible in flipping (maybe a +/- change or 'C3" >> 'C8" etc... }

NOW ...
6. Since the cursor is always being PRE-positioned at (ie jumps to) the place where the NEXT Undo WOULD occur IF enacted, and since the jump is immediate, a problem arises -- namely, when you get to the end of a chain of physically near-to-each-other &/or related edits, you WILL NOT SEE the last Undo AND you will be forced away from the code location where usually you want to stay and work. To see what was actually changed, you will have to manually scroll back up/down to the line of interest.

I am frequently having to do this.... I am going to pause a moment to MAKE SURE I am right about all this ...... hold on  ...... OK YES the Undo cursor is clearly "getting ready" for the next edit and abandoning the current edit line. I repeat: I propose that it would be better during UNDO to place the cursor AT/AFTER/ON the just-completed Undo, and to stay there. The simplest way to say all this is: Undo should always (my opinion) place the cursor on the first or last character of just-reverted text. Preferably, the Undo/Redo zone would also be ~centered in the editor window.

Maybe the issue is a matter of Undo/Redo direction ....... let me test something ...... hmmm. I now see that ^Y acts differently. Ironically, it does what I would like to see ^Z do! In fact, my vote would be to swap the ^Z and ^Y cursor positioning behavior: Pre-position Redo, and Stay at Undo ....

Anyway, I've said my piece on the topic lol thanks for your patience. I actually signed in to upload some more/other minor-moderate suggestions :-)

I note cr0sh's discussion re file/directory ordering ... I have a similar observation, which I will include with my next thread, "Minor UI Tweaks #2..."